Hacker News Reader

Comment by sigzero | Hacker News Reader

I don't think Go was trying to capture that space really.

Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown.

Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig or Rust to appeal to systems programmers. So it only makes sense to target the web services section dominated by Django and RoR.

[^1]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Go is best at interfacing with kubernetes, which I think will carry it pretty far, for better or worse.

Yeah, Go’s niche is networking. But it could be so much more. The language is nice and fast, and there’s no reason it can’t be a solid choice outside the microservice and tooling universe.

The Kubernetes API is one of my least favourite Go packages - largely generated, boilerplate all over the show and hasn’t even adapted to use things like log/slog without some wrapper.

A much nicer library for dealing with Kubernetes is the kube crate [1] for Rust. The worst aspect of it is the dependency discipline, though that is no worse than the official Go client.

[1]: https://github.com/kube-rs/kube

Go’s k8s package is the OG. Everything else spawned off of it, so it’s packed with legacy artifacts. But yeah, I wouldn’t use it as an example of a good Go package.

Sure, it's the canonical example of a Kubernetes client, but it's still not very good - even for modern Go.

Not too familiar with Go but this makes sense to me. The standard libraries are really great for microservice type stuff. Things that, as a python guy, I would have reached to Flask for. Problem is, I never reached to Flask for much of anything.

I’m really having fun with Go these days, though

Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother.

That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.

WSGI was a learning curve for me

ASGI too. But it’s not too bad and tools like Starlette / FastAPI make it a breeze. Go servers are fast but generating docs from code is a lot more work which you get free in FastAPI.

https://huma.rocks/

https://github.com/go-fuego/fuego

> Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed

Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.

No need to imagine - here’s the documentation for it: https://pkg.go.dev/std

I’ve found the Go standard library to not only be very complete, but also to contain far fewer sharp edges and dead batteries than that of Python for every use case I’ve tried.

Go’s HTTP library is production-ready. Python’s isn’t. Python has a ton of dead batteries in the standard library—stuff like urllib is plain dangerous to use these days. But Go doesn’t have collections.abc, itertools, heapq, deque, and many other data structure niceties. I still reach for Python for numerical and algorithmic tasks.

Kudos: I find this to be an exceptionally helpful and concise description of the Go meta.

I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age.

It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby.

I'm still Rails all day, but I've never stopped thinking Elixir is cool.

Well, i think Elixir/Phoenix is better Rails than real Rails - great developer experience (and developed by rails contributors)

100%. I’m never going back.

Every time I step out of elixir I feel like I’m coding with some cumbersome construction gloves and everything is kinda coerced to work together. But for some reason it’s not picking up a lot of steam and the job situation is rough

Typed languages are in big time, and any dynamic language is facing an uphill battle for adoption, no matter how good it is. Elixir seems to recognize this and is getting there, but it hasn't fully arrived yet.

Types and editor tooling IMO. Both places they're making investments, but both areas where I feel like I'm giving up a lot of power, even though it's admittedly to GET a lot of power.

Agreed on the tooling, I won't be adopting Elixir until the IntelliJ tooling is there. It's just too crippling switching to another IDE.

what exactly is present in intellij that isn't available in vscode / neovim with lsp / newer emacs? I ask because, I use(d) intellij for java and maybe i'm not using most of its capabilities or they're hidden away in plain sight, but i haven't noticed anything special aside from the slow ui.

For me there are two axes that are lacking (based on Scala and Elixir usage):

1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?

2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.

Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.

It’s sorta inevitable. I started with Python and used to hate the constraints types put on my design. But as I started working on larger projects, I got tired of Node-Python-Ruby and wanted something faster with stricter types but without too much ceremony. Found Go to be in that Goldilocks zone. The benefit of typed languages becomes easier to appreciate once you have accumulated a certain amount of elbow grease.

Reply on news.ycombinator.com