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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
On what basis are you making that claim? Multiple sources link No Lives Matter back to an intentionally formed subgroup of 764, started by a specific Swedish 14-year-old.
This would be possible via attestation, but both Apple and Google removed that feature when they replaced their respective device-bound authenticator implementations with cloud-synchronizing ones. (Google technically still allows creating device-bound ones and supports attestation in that case, but that's arguably a niche use case and not what people are talking about when they say "passkeys".)
Close representatives beg to differ, despite Congressional inquiries (which are by definition politically driven) not finding sufficient evidence. Several credible people either involved or in positions of know stand by the allegation.
> Nevertheless, several individuals—most notably, former Iranian President Abulhassan Banisadr, former Lieutenant Governor of Texas Ben Barnes, former naval intelligence officer and U.S. National Security Council member Gary Sick, and Barbara Honegger, a former campaign staffer and White House analyst for Reagan and his successor, George H. W. Bush—have stood by the allegation.
What is the downside? I was thinking it could compromise software security, although my layman understanding is we’re better off if the open source community finds and makes problems visible?
Or there are other software secrets that we wouldn’t want state adversaries to see, like things that block your access under export control laws?
reply