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.