The Rust zealots I've noticed tend to have just very recently encountered the language. The developers who use it in production systems and in non-trivial applications tend to have a more mellow opinion lacking hype or whatever.
I use it during the work week and it solves a lot of problems and the ecosystem is maturing very quickly. Serde is by far the biggest boon of the language. It is truly state of the art as far as serialisation goes. I also agree with the writer about it not being hard. It's hard in the same way Erlang is hard, it just doesn't operate the way C-like languages conventionally do, though there are some similarities. The borrow checker is pretty easy to wrap your head around once you program more with it.
Overall its a good language. Not perfect, and I'm sure in the future we'll see some better languages, but for what it presents, it's as good of a tool as you'll get in some domains.
Personally, it's less "Rust is great" more "We are seeking to address performance bottlenecks in security sensitive, uncontrolled inputs, please don't make me go back to C".
Since you’re kind enough to express a moderate opinion: do you have a comparison against C++?
The C++ “niche” seems to be no-performance-compromise, low-level-when-needed, high-level-sort-of, native compilation, seamless interop with C, and thus everything else. It is also very verbose, easy to shoot yourself in the foot, and requires a fair amount of proficiency to just use on a daily basis.
Not the parent, but I think in a vacuum Rust would be pretty good at filling C++'s niche (minimal performance compromise, low-level-when-needed, high-level-sort-of, native compilation, though C interop is less seamless), plus it's more expressive/beautiful (but more troublesome if you want to mutate aliased pointers), and teaches you upfront to avoid pitfalls. But Rust has less thorough library support (though Rust does have some really cool libraries), and the existing practices around separate compilation and stable ABI can't be carried to Rust. I also dislike the culture of downloading dependencies from the Internet.
I'm pretty in the dark about [new thing]. I don't have skills in it and really don't grok it. And even though it seldom gets mentioned, my insecurity about that gap in my knowledge -- that thing that makes my existing knowledge a little bit obsolete -- makes me laser focused on those instances where it does appear (Baader-Meinhof phenomenon of sorts): If one in a hundred posts mentions [new thing], I'll throw my hands up and complain about how these hipsters are trying to push this stuff down my throat at every venue. Maybe I'll no true scotsman in a futile effort to try to coerce people against talking about it, for instance by claiming that real pros don't actually talk about it at all, Fight Club style.
This has played out over, and over, and over again. Blockchain, NoSQL, JavaScript, Angular, "web3", Android, iOS, Swift, K8s, and on and on. Legitimate criticism gets drown out by people just fearful that something might take hold and then they're going to have to change how they do things or learn something new.
Quite right. On the other hand, plenty of other dumb technologies have launched, been mocked, and sunk without a trace (or worse) because they were just bad.
As Carl Sagan apparently said "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
And even when the technology itself has merit, it's absolutely true that some of the people who have complained about the technologies on your list (or OOP, or Go, or Electron apps, or many, many others) were doing it because this new technology devalued their skills and threatened them. But it's also true that valid criticisms of all of those exist, and all of those have been overhyped and oversold at least sometimes.
"Some people are threatened that NoSQL DBs may devalue their knowledge of SQL" can be true even as "shady startups are lying about the benefits of NoSQL" and "NoSQL DBs are not a panacea and SQL DBs will remain vital and omnipresent" are also true.
They were right to laugh at Columbus. He thought the world was 3x smaller than it had been known to be for more than 1000 years. He was lucky he found the new world instead of starving to death halfway to India.
He probably didn't think that, but could not sell his project without getting potential investors to believe it. (At the time, nobody knew exactly how wide Asia was, although travel time on foot showed it was not as big as it would have to be.) Things haven't changed so much.
But he continued insisting, to his dying day, that he had reached Asia.
The overwhelming majority of things have been launched and soon sank with little trace just because they were not enough better than the competition. (I count Modula, D and C# among those, from different arenas.)
It is still far from clear whether Rust will achieve the miracle of becoming mainstream. That puts it far ahead of most languages, where it is obvious from the outset that they will fizzle.
C#, a 21 year old programming language which consistently makes it into the top 6 programming languages by popularity in all methodologies of measuring, "launched and soon sank with little trace"? That's an interesting take.
is that saying anything if microsoft is basically eternal? what, you think the company that makes excel and windows is gonna go out of business any time soon?
The usual route is becoming irrelevant. Windos failed to achieve relevance in mobile and cloud, and desktops become less relevant every day. If at some point you don't need MS to do excel anymore, MS becomes irrelevant there, too.
There are still Burroughs, Univac, and Honeywell computer companies, in a way, but they attract no attention.
As a security guy, I'd much rather hear from the Rust "zealots" and all their Rust "hype" all day long than hear about yet another memory corruption vulnerability in software used by millions.
> rhetoric taking on levels of hostile zealotry like the linked post
Honestly, this feels like bad faith.
The article explicitly says "this is a rant for catharsis, not a serious argument" and ends with a list of caveats and "okay actually it's more complicated" bits left out of the article.
Even if you take it seriously, you're implying that it's representative of the average Rust advocacy post, but this is easily the strongest piece of rhetoric I've seen in Rust advocacy.
You're implying that "levels of hostile zealotry" are commonplace, but every post I've seen advocating Rust on HN has been polite; for every post saying "this is a problem that Rust could solve" there's at least one answer saying "I like Rust but in this case maybe the costs of refactoring would be too high".
Honestly, the community is the most off-putting part of the language. The hype makes it difficult to find quality content; all I find are strange comparisons to dissimilar languages and "I rewrote 'Thing' in Rust" posts.
> people absorbing a technology as an element of personal identity
This is true for all modestly popular technologies today. It’s fueled by social media culture. We are living in a world where people get wrapped up in their individual identity because it’s the only way to get any attention. This is a simply how social capital is distributed on the internet.
If you want your programming language, new tech, new video game, or new thing to be popular, then you need to create hype with influencers that wrap their identity up in your new thing and preach it’s endless benefits with cult-like fervor.
In fact, it’s impossible for a new language to survive unless they play this game. In other words, the hype we all hate isn’t rust’s fault, it’s our fault.
We don't need to know that your new shell / grep / text editor is coded in Rust. If it's good, it's good for other reasons, and those reasons are certain to be overwhelmingly more interesting. If it's bad, it's just bad, and that won't save it. We especially don't need to know in the title.
We especially don't need to know your (embarrassingly outdated) opinions about other languages. Those just invite us to point out your mistakes, which will tend to distract readers from what would surely have been deserved admiration for your work.
There is no harm in mentioning implementation languages in the bit at the end where you invite people to send patches, for what ought to be the one obvious reason. [Edit: an announcement about a library clearly needs to mention who can use it.]
> There is no harm in mentioning implementation languages in the bit at the end where you invite people to send patches
Okay, but... there's no harm in mentioning implementation languages in the title either?
If you don't care, that's fine, you can just ignore it.
To me, "built with [new technology]" is a sign that the person who made it had fun, and is proud of their work. It's like an engineer posting "look at our new car prototype, built with [fancy new internal chassis technology]". Maybe it doesn't change anything for the person driving, but it's obviously of interest for the engineer, and potentially for other car-internals-geeks as well.
That is exactly the point: pride in having succeeded at doing X using Y is not informative. It is an indulgence. "I graduated from Harvard" may be interesting to your Mom and, maybe, strangers still at Harvard, but not to us, and would be unwelcome on the HN dashboard.
If you published a thesis, that thesis topic could be interesting, but not that Harvard accepted it, unless they shouldn't have.
People "doing that all the time" for any language are exactly, equally obnoxious. (But, it must be said, they do it less.) The only exceptions are for a library, or when the language is apparently unsuited to or incapable of the task.
"I wrote a web browser in Apple ][ Integer BASIC" would mean something.
The natural inference about crowing "in Rust" is that you really did not expect to succeed.
if there was a production-grade memory-safe language with similar performance, i would also advocate for it. it's less that rust is good, and that memory unsafety is bad.
Stop invading spaces used by language x, evangelizing that x sucks and Rust is what everyone must switch to if you don't want users of language x to think you're a bunch of arrogant asses.
Rust could have been a great systems programming language. Unfortunately, it has been taken over by web developers. All systems programming jobs are still in C/C++.
It could have been different if Mozilla hadn't rewritten all of Firefox in Rust while complaining about C++. Firefox dropped from 10% of the web to 3% and into irrelevance during that Rust rewrite and gained nothing. Ironically, Chrome is written in C++ and ate their lunch from Firefox's plate.
Mozilla didn't rewrite all of Firefox in Rust--they didn't even rewrite most of it. The decline in Firefox share came well before anyone seriously contemplated moving pieces of Firefox into Rust, and all you can say is that what was rewritten didn't do much to arrest that decline.
I guess Web developers are planning to take over Linux kernel now by using Rust for it?
Firefox market share has nothing to do with usage of Rust. I very much welcome Mozilla using it in Firefox. They should have gone even further and started using Servo proper. But they didn't have enough resources for that.
i eagerly await the day when chrome realizes their current situation of being written in a memory unsafe language is untenable. it seems like they're still in denial, but they're slowly realizing https://docs.google.com/document/u/1/d/e/2PACX-1vSt2VB1zQAJ6...
You better go tell https://github.com/oxidecomputer/hubris to pack it up because they can't realistically continue to write their kernel in Rust and that Rust is for web developers now.
I really don't know why people need to get so defensive about programming languages. I'm generally happy to live and let live and I really don't think languages matter very much. But when it comes to Rust people, there is a special kind of obnoxiousness among their community. The do tend to come along uninvited into non-Rust spaces and evangelise, and it is kind of grating.
If you're not into selfies, you may ignore the fact that your smartphone has a front facing camera. It may not be for you, but other people do use it.
HN is a tech community, which means there're many programmers here. Some people may use X and also contribute to X, or at least want to dig into the source code.
For example, since I'm a Rust programmer and not an R programmer, I'm more interested in "A fast query engine written in Rust" than "A fast query engine written in R". There're benefits of using a program written in a language you're familiar with. One of them is when you find a bug you can dig into the source code, post an issue which point out which code might cause the bug, better yet post a PR. Instead of "Please help, X failed to do Y."
If you have looked at rust, you would understand that "Written in Rust" means something more than just the face value.
Written in Rust means that there will be less memory/concurrency bugs due to the language itself ruling out classes of those bugs and that is a feature that I would definitely care about in any peice of software I use.
This. I don’t really care about replacing Java or Python or Go with Rust (any perf difference might not be worth the extra effort), but evidence has been mounting for my entire career that we must leave C and C++ behind if we’re ever going to arrive at a platform that works reliably.
the worst part is that testing might give something that is reliable against non-malicious inputs, and then explode given malicious ones. actually, that's not the worst part. the worst part is when nothing seems to occur on a malicious input, but actually rce is occurring https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i....
>Do you remember when Java was the hot new thing? No, probably not. You’re probably too young.
I do. But no one hyped Java as the Silver Bullet or the Holy Grail. There were many known trade offs. ( Performance, GC, Memory usage etc ) And we were allowed to discuss those trade offs.
I never read anyone actually disapprove Rust for its absolute ability to provide memory safety. Nor any inherent distaste for Rust. It may be a difficult language to grasp, but that is about it in terms of negativity.
But when Rust Evangelism StrikeForce demands every single piece of new software to be written in Rust otherwise they are deemed unsafe. One have to question whether any additional Rust hype ( at the time when RESF were still active ) is simply adding fuel to fire, without also adding some balanced view on draw backs.
Technology evangelist, despite my hatred against the term as it should simply be "marketing", is somewhat a necessary evil in order to gain traction and critical mass. But the key word here is critical mass, not world domination, unless you are a marketing and PR genius like Steve Jobs.
The problem occurs when I arrive on a landing page for a project re-invented in Rust that advertises not encountering double frees as a feature of the project. I notice the project is nothing more than a build tool for web development, and I just shake my head.
Personally I tend to use C and C++ tools more often, and in that universe, being statically free of memory errors is an innovation. In the webdev world, I suppose native speed and not having a large runtime or GC is Rust's primary innovation (though for batch jobs like build tools, a small Go-like runtime/GC isn't actually a negative compared to Rust, and I've never noticed GC pauses when I previously use the Micro editor in Golang).
I'm sure any build tool for web dev can leak memory like crazy and it's fine, the OS will clean it up when the build tool exits. So Rust's features are wasted on that use case.
I've dabbled in rust and it's been good but I've never progressed further than just modifying existing codebases.
I've yet to find a good toolkit/framework that helps me build web apps. I stick to JavaScript merely because it's a language that allows me to do most of what I want, in a tolerable way, in most situations, on both the client and server.
But, I know the problems with it. And there are a lot.
Is there a toolkit for building web apps that has the ergonomics of something like Svelte? Or, at least is a toolkit that radically simplifies building things in the client with wasm?
Until I find that, I'm just going to stick with JavaScript, only because it's more important for me to ship quick prototypes than build something perfect before I know what that is.
> I've yet to find a good toolkit/framework that helps me build web apps.
Ironically, there's a sibling comment complaining about how so much of the Rust dev ecosystem is just people making "nothing more than build tools for web development". You can be sure that people are just whining when they can't even get their story straight.
Why would different individuals need to "get their story straight" just because they discussing a similar subject? The "there aren't enough web tools" folks and the "there's too much effort spent on web tools" people are not a collective mind. They are each individuals with their own experiences. What does it mean for them to "get their story straight"?
There is this phenomenon, when people confuse upgrade over previous iterations, with the hottest shit ever.
I think this has happened with Java style OOP. It came in existence to fix some things, became "the way to do programming", but honeymoon is over now.
We might see it happening now with gradual typing. Dynamically typed languages are being upgraded with some static typing, and you can see comments popping on HN how this is actually the best way of writing programs.
Rust is in this category and a dose of skepticism is always welcomed.
(Good) static typing is the single most useful thing of any programming language. A large, disorganized project in Java is far better than the same thing in Python or Ruby.
Python is fine if you have a good IDE and a very strict type checker config. I use the most strict configs I can manage and it's almost at par with static typed languages, at least where you're developing and refactoring. Runtime is another matter altogether, though I've never had problems with Python once I have ensured types going in and out match and validate inputs.
The problem with Python type checking is that the general community still does not write libraries with types. On the other hand, the JS community is further along and most libraries written today include TS files. I think the same will happen with Python, but it obviously takes time.
> Rust is “hard”. (It’s not, by the way. It’s not hard. It’s truly not.)
As someone who likes Rust, it takes days or weeks to wrap your head around the borrow checker, and "spaghetti object graph" code patterns in other languages don't transfer well to Rust (Cell<i32> is more awkward to use than C++ int, and RefCell introduces runtime panics). I've had the misfortune of dealing with code written in unsound unsafe Rust which freely converts aliased raw pointers into &mut, even when they likely conflict with other & or &mut. I still don't know how to rewrite it in safe Rust.
Rust is built around making mutable multiple ownership awkward. This is fine (and often results in more understandable code) when you're working in single-ownership code conceived and built around Rust, but when you're using something like gtk-rs (which binds to a C framework built around reference counting and cyclic parent pointers), Rust makes mutating shared state awkward (adding extra state alongside GTK widgets requires RefCell or similar), and reference-counted callbacks awkward (the clone! macro breaks rustfmt).
> Nobody thinks you’re smarter or better because you can remember all the pitfalls.
Oh, I know some people who think that way. Personally I think Rust teaches you the same things as C++ code (reasoning about state, knowing what parts of your code reference an object, knowing when to free an object).
> Soon your solution won’t be faster to market, and will be more expensive to maintain to boot. And someone’s going to eat your lunch while you complain.
There's no Rust GUI framework as comprehensive and mature as Qt. (Then again, there's no C++ GUI framework as clean, usable, and stable as Qt should've been. And people are moving to web UIs.) And some (not all) Rust libraries are amateurish from people who don't know what they're doing; for example, https://lib.rs/crates/samplerate allocates on every conversion (which isn't safe for real-time audio generation) rather than writing into a preallocated &mut buffer. https://docs.rs/hound/latest/hound/ is a WAV file reader which branches on every sample (IDK if it gets optimized out), rather than performing error checking at file open time and bounds checking once per block, which feels bizarre to me.
Re. "An ability to compensate for the shitty state of technology" that exists today isn’t some kind of a competitive “moat”.", writing your own bindings to C code, or performing unsafe C calls directly, instead of using the ergonomic libraries which don't work properly, is compensating for shitty technology.
IMO this article comes pretty close to flamebait and trolling.
let's check out https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i..., which has probably been used to enable "crimes against humanity". integer overflow results in undersized allocation which is indexed out of bounds. if c++ had either overflow checks or bounds checking as the default, how likely is this bug to happen?
It could be read as satire, especially in suggesting there was ever anything good about Java. Java ate the industry not on merit but on a billion dollars of promotion by Sun (hastening Sun's demise, which Java utterly failed to save), but much moreso on programmers' relief at finding a way out of sharecropping for Microsoft.
People today might not know that at the time, Microsoft introduced a whole new "app framework" every other year. People stuck coding for Windows were perpetually needing to get "certified" on the new thing. The New Thing was invariably horrendous. (Really, people paid to get certification as qualified to code for Windows! I am not joking.)
Lifetimes are not, in fact, hard, given a bit of library and language support. Persuading your compiler that you are right about them might be hard (even when you are).
I use it during the work week and it solves a lot of problems and the ecosystem is maturing very quickly. Serde is by far the biggest boon of the language. It is truly state of the art as far as serialisation goes. I also agree with the writer about it not being hard. It's hard in the same way Erlang is hard, it just doesn't operate the way C-like languages conventionally do, though there are some similarities. The borrow checker is pretty easy to wrap your head around once you program more with it.
Overall its a good language. Not perfect, and I'm sure in the future we'll see some better languages, but for what it presents, it's as good of a tool as you'll get in some domains.