Comment by spacechild1
2 days ago
> I remember watching HN and seeing every time there was something Rust related trending, there was ALWAYS a post made shortly after trying to hype Zig and this went on for like 4 years.
You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission here on HN for years.
> You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission
Which is what C++ enthusiasts have done to C enthusiasts and C enthusiasts have done to assembly enthusiasts.
If people would just take the time to actually learn and appreciate the Analytical Engine they could bypass _all_ that noise...
I’m rather partial to Plankalkül actually
Now that LLMs are writing 300% of the code, it makes sense to do it in the safest language, not the most human friendly one.
I suspect that Rust will start taking over as a dominant LLM output language.
I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate. Perhaps even safer than Rust.
The models are shockingly good at writing Rust. You don't even need to have familiarity with Rust to start using it now. You'll learn the language as you interact with the LLMs.
Rust is one of the safer languages, but saying that it is "the safest language" is just a baseless exaggeration.
Decades before Rust and long before the simplified language that was C, there were safe programming languages, where all invalid operations, numeric overflows or out-of-bounds accesses generated exceptions and where use-after-free was impossible, because either garbage collectors or reference counts were used.
Rust is much safer than C compiled with its bad default compilation options, but it did not bring much in comparison with other languages.
Even in C++, with appropriate rules, restrictions and discipline you can write programs that are guaranteed to be at least as safe as any Rust program, but unfortunately very few use C++ in this way, i.e. by strictly avoiding the features that are obsolete or unsafe.
13 replies →
> I suspect that Rust will start taking over as a dominant LLM output language.
I doubt it. I think most people will become more entrenched in their favored ecosystem.
> I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate.
This is already happening. A couple months ago I came across this language that is engineered for AI and human consumption https://www.moonbitlang.com/
I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly
6 replies →
Rust will never be the dominant output by a country mile. It will be python and typescript.
2 replies →
You mean ADA? I'd agree, at least gcc can compile it so it's not limited to the very few architectures that rust supports.
3 replies →
Why are Rust people so insufferable?
We get it. You like Rust. It's not a panacea.
The entire concept of publicity as a competition is baffling to me. Who gives a shit?
More Rust users = more Rust libraries = more Rust jobs = more places to do what you enjoy and get paid for it.
That seems like a train of thought so thin as to be anorexic. I think that many erm coding enthusiasts simply have issues with emotional regulation.
By that definition, Javascript is by far the bestest language in the world ;)
1 reply →
Not trying to derail the discussion, but the reason for me to leave the Rust ecosystem in favor of Go was also the implied culture.
Experienced Go devs that stay inside the ecosystem try to write their libraries as "pure go" libraries with zero dependencies other than the upstream core libraries (or golang.org/x if needbe), which results in a very low maintenance ecosystem. This combined with the strong toolchain makes it joyful to work with.
I still don't agree with a lot of design choices of the language, but I realize that I can be more efficient if I am setting aside my opinion.
And that's exactly the thing that somehow never happened in the Rust ecosystem. I always joke that the Rust ecosystem has more OpenGL bindings than developers, because there's just so many low quality bindings or wrappers out there that the ecosystem in result got too noisy to maintain.
I don't want to write more (verbose) code. I want to write less.
I kind of already know that my comment goes to shit in terms of downvotes, but that's what I expect while writing this. How dare I criticized Rust as a language? How dare I, a fulltime noob, do this? Rust is better, always!
...the Rust ecosystem is just so effing toxic. I am glad that I left it. I just got tired of being angry at random online things all the time. Go is my happy place where my annoyances are reduced to Cgo, maps, and the unsafe package <3
There is also many compile to Go languages today, that add many befefits from the MLs with still 100% Go interrop. I would say lisette is probably the one that has most momentum right now.
> And that's exactly the thing that somehow never happened in the Rust ecosystem. I always joke that the Rust ecosystem has more OpenGL bindings than developers, because there's just so many low quality bindings or wrappers out there that the ecosystem in result got too noisy to maintain.
Rust seems to attract a lot of horizontal programming. I have done mainly that so far and I LOVE Rust for it.
AIUI, horizontal programming is fully building out each abstraction before you start building on top of it, as opposed to vertical programming, which generally seeks to accomplish the task as directly and straightforwardly as possible, and only abstract if needed.
This leads to things like the proliferation of bindings, abstraction layers, frameworks etc. with little downstream users to show for it. And often little influence from experience using them. Sometimes very technically impressive but otherwise not always fleshed out to the point of being practically usable.
I am sure there's tons of toxicity all over the place too but I chalk it up to differing mindsets / patterns of development.
As much as I'm put away by the dependency horror I've seen in many Rust projects, this is an interesting observation.
1 reply →
Seriously. Yesterday there was a thread about a use-after-free bug in OpenBSD and despite BSD predating Rust by decades there were still people chiding the project for not using Rust (as though Rust would even protect you from all memory errors in a kernel project where you'd inevitably need to write unsafe Rust anyways!). Rust might be a fine language but it has the most toxic evangelist culture, bar none.
> there were still people chiding the project for not using Rust
Please provide a link to this comment.
Someone asked an honest question and got reasonable responses that were informative. At no point did anyone chide the project for not using Rust.
> Rust might be a fine language but it has the most toxic evangelist culture, bar none.
Nah, people complaining about the supposed toxic community are noisier than the supposed toxic community.
[flagged]
You have an awful low bar for what is considered chiding, damn
Then again, your very username implies an indulgence in viewing technology through the lens of fandoms which is... weird
I read the comment that they were referring to and it wasn't even constructive conversation in the thread.
It was basically a complete derail to backdoor in a conversation about why they think everything should be in Rust.
OpenBSD still uses CVS, C and Make because that's what works for them. They will continue to keep using C, Make and CVS but that enables them to be productive with the contributors that they have. Moving things to other languages will not increase their productivity. That's the biggest thing that the largely-fanatical Rust evangelists completely fail to understand.
3 replies →
[flagged]
2 replies →
You need to write some unsafe code in a kernel, but most of the code does not have to be, which allows you to eliminate memory unsafety from almost all code and give more scrutiny to the parts the compiler cannot guarantee for you. I don’t know though if the affected code in openbsd would have needed to be unsafe. Moving towards rust is a possible way for kernels as Linux has shown, but I guess for OpenBSD the pros and cons are different, as it’s striving for a more minimal system and has been affected far less by memory unsafety issues.