Hacker News Reader

Comment by amelius | Hacker News Reader

I think most people here understand that a language that is great for kernel development isn't necessarily great for everything else.

View on HN

I work fulltime in Rust (embedded stuff) but actually think the "everything else" influence into Rust is stronger than the systems stuff, and it's harming the ecosystem.

Just try finding e.g. an MQTT or WebSocket or etc library that doesn't drag the whole mammoth tokio ecosystem (which is really geared for Web Scale! projects) in with it.

Rust is becoming the language that tokio ate, and Cargo/Crates.io the new NPM.

That is, Rust is the systems language that a wave of non-systems developers insist on using, leaving behind a trail of non-systems-appropriate crates and projects.

Parent commenter's comment was crap by HN's commenting standards... but the underlying point about trendiness I think is in fact accurate.

I used Rust professionally up until this year (since before async landed) and IMO you've hit the nail on the head. The shoehorning of async into the language and ecosystem seemed to be driven by the belief that if Rust can't attract Go or Python developers then it will fail. In fact Rust was doing fine in its niche attracting C++ developers and trying to make it everything to everyone has diluted what was great about it.

(That said, your example might be a bit exaggerated as I found mqtt libraries that don't require tokio).

Just like C++, teams will end up having to carve out a sane subset comfortable for their domain.

For myself that's looking more and more like:

Ditch crates.io (and maybe even Cargo), carefully curate and vendor all dependencies.

Probably avoid async, but definitely avoid tokio.

Don't get excessively clever. (Here I think Rust does a better job of C++ of having good "community standards" already)

I might be inclined to buy this complaint if tokio was part of the standard library. But it isn't, and I just can't see how its mere existence and tree of dependents has a negative effect on the "ecosystem", it's not preventing anybody interested in "embedded stuff" from producing high quality libraries that are not dependent on tokio, and I don't buy that there is some fungible mindshare being taken away. This to me seems more a gripe that Rust is not being adopted quickly enough in certain domains, which I believe has far more to do with both reasonable and unreasonable inertia.

(How is tokio fundamentally different than boost.asio and beast in this regard?)

> That is, Rust is the systems language that a wave of non-systems developers insist on using, leaving behind a trail of non-systems-appropriate crates and projects.

I have hard time understanding how this "trail" of stuff (evoking imagery of pollution) that no one is forced to depend on nor is promoted in any special way in the core library or language is any meaningful impediment to developing and distributing libraries more appropriate to the embedded domain, but perhaps one can explain how.

It can be though. You should be able to express low-level details but also implement high-level constructs effortlessly should you so choose.

Look at C++, which can both dick with move semantics but also offer multiple inheritance. Even better, look at C#, which has pointer fiddling but also offers the best reflection of any language today.

You're right that Rust is only really good for kernel development but it didn't have to be that way.

Oh the language is good, it's the people. Cult-like.

Would that make rust a cargo cult ?

> Oh the language is good, it's the people. Cult-like.

I used to read something similar all the time around 20 years ago: I don't have anything against Jesus. It's his fan club that's a pain in the ass.

Reply on news.ycombinator.com