dsff3f3f3f

Their hiring process seems absolutely absurd.

There needs to be a massive push from the larger important packages to eliminate these idiotic transitive dependencies. Core infrastructure shouldn't rely on trivial packages maintained by a single random person from who knows where that can push updates without review. It's absolutely insane.

> These kinds of dependencies are everywhere and nobody would even think that they could be harmful.

Tons of people think these kind of micro dependencies are harmful and many of them have been saying it for years.

You're right. I only looked at the source for debug and ansi-styles. After looking at chalk it's insanity to add that as a dependency as well.

I wouldn't use debug or ansi-styles. They're not even remotely close to being worth adding a dependency. Obviously none of them are trustworthy now though.

You're correct and the HTTP framework looks like Axum.

> Why mention Rust at all?

I like knowing what language a tool is written in. If it's written in Python or JavaScript and it isn't something that's absolutely essential I can just immediately move on. It also lets me know if it's something I'd be willing to contribute to. It's odd that the authors mentioning the language is so triggering for you.

> They'd have just invented another issue.

I largely agree but I doubt other issues would be such massive free wins for Republicans. The Republican base has become rabid over DEI and trans issues and it has been really obvious for a while now that it was going to be a massive problem for Democrats. Sadly these issues have become more divisive than even gun control.

I did the same and don't regret it. My Helix config is 4 lines and it does 95% of what I want. The performance of a ton of neovim plugins is also atrocious and I always hated that everything was a hodgepodge mix of C, vimscript and Lua.

Not the other poster but I moved from Go to Rust and the main packages I use for web services are axum, askama, serde and sqlx. Tokio and the futures crate are fleshed out enough now that I rarely run into async issues.

Seems like the project quickly shut the annoying troublemakers down. The few people on Mastodon that are upset about this don't matter and they'll quickly move on to being upset about some other trivial matter.

> None of those tools you quoted are production ready based on my investigation

This is very true and almost all of them are taking far longer to develop than they initially thought. swc/turbopack is being pushed by Vercel and it has been a huge ongoing disaster.

The reality is that it's not nearly as good as the loud proponents would have you believe. Performance isn't great unless you're comparing it to really naive applications written in extremely slow dynamically typed languages like Ruby or Python and OTP and real supervisor trees are not trivial to use correctly. Almost all of the Elixir systems I've seen have serious problems in their supervisor trees.

I've also repeatedly seen this idea from relative newbies that you can replace things like Redis with a simple Erlang key/value store, possibly using ETS, and the result is always much, much worse in terms of both performance and reliability. A lot of the older Erlang/Elixir proponents will tell you to just use Redis.

Most of the popular statically typed languages also have decent abstractions for concurrency and parallelism now while having far better runtimes, far better performance in almost all cases, far more libraries and much larger communities. Erlang/Elixir will never be more than a small niche.

Go is perfectly capable of all of the additional optimizations that are in the fastest Java implementation that is linked in the article.

The fast Java version is using all the same optimizations as this Go version and then some. It's significantly more complicated.

Not that I know of. I just looked at the code and the commit history but a more in depth article would certainly be interesting.

The Java version does additional optimizations that his Go version doesn't do and he mentions that at the end of the post. The Java version is really optimized and is an interesting read.

Generic iterators are included in go 1.22 behind an experimental feature flag and will most likely be in 1.23 by default. Once that's done you will probably see some support functions like map and filter in the standard library. Russ Cox already has a proposal for an experimental package xiter that includes Map/Filter/Reduce/Zip etc.

I've seen fairly naive Go servers that do 10,000+ RPS that issue database requests on every request that consistently use less than 50MB of RAM without issue. Several of them barely ever break 30MB of RAM.

Most crimes committed by adults should carry much harsher penalties across the board. There's far too much sympathy for the criminals and not nearly enough for the victims and communities that have to tolerate their nonsense.

Most of the Reddit/HN/Twitter crowd that are parroting the "Go ignores decades of language theory" line are just parroting something that originated in an incredibly toxic part of the Scala community. The vast majority of them don't actually understand the tradeoffs and implementation complexity that are associated with the specific subset of language features they desire. The debate about a particular feature is often not even concluded in languages that include said feature. For example the Swift team still has serious disagreements about generics and their respective implementation.

I've seen Pike have conversations about language design with SPJ, Hejlsberg, Lattner, Stroustrup, Odersky and other highly respective PL designers and they would never make such a shallow and trite comment.