Ask HN: What's the Deal with HN and Rust?
Just curious, I see so much "pumping" around Rust, and as an engineer myself, I beg the question: why the hype here specifically?
107 comments
As someone who looks at Rust and other alternative languages every now and then. I think many C/C++ programmers are looking for an alternative. C/C++ accumulated a lot of legacy stuff over the years, and things like #includes, .h vs .cpp, non-trivial metaprogramming, limited IDE capabilities, no standarized package manager show how old these languages are.
Compare it to Rust, which has one build tool/package manager. No more hunting down dependencies, arguing make vs cmake vs 20 other tools. 99% of projects just use cargo and building a project on every platform is just one cargo build run away. Compiler is smart and can show you many errors in your code that C++ never could. Old mechanisms like header files are replaced with a modern module mechanism. Also some interesting features like the traits system.
All that with performance close to C/C++ and with increased safety. Also, there is a lot of hype behind the language making it reach critical mass. It's not surprising to see many people flock to it. Some people dumped C/C++ in the past for Java/C#, but these languages don't support the same usecases as C/C++ do. Rust does.
Personally I dumped C/C++ for D years ago and don't regret it. It's not as popular as Rust is, and doesn't have the same ecosystem or big companies behind it, but it works for my needs. If Rust existed at the time I was looking for an alternative, I'd probably be using Rust now.
Compare it to Rust, which has one build tool/package manager. No more hunting down dependencies, arguing make vs cmake vs 20 other tools. 99% of projects just use cargo and building a project on every platform is just one cargo build run away. Compiler is smart and can show you many errors in your code that C++ never could. Old mechanisms like header files are replaced with a modern module mechanism. Also some interesting features like the traits system.
All that with performance close to C/C++ and with increased safety. Also, there is a lot of hype behind the language making it reach critical mass. It's not surprising to see many people flock to it. Some people dumped C/C++ in the past for Java/C#, but these languages don't support the same usecases as C/C++ do. Rust does.
Personally I dumped C/C++ for D years ago and don't regret it. It's not as popular as Rust is, and doesn't have the same ecosystem or big companies behind it, but it works for my needs. If Rust existed at the time I was looking for an alternative, I'd probably be using Rust now.
> 99% of projects
I don't know where you got this figure from, but I highly doubt 1% of Rust projects use a different build/package system. More like 0.001% (this number is scientifically extracted from thin air).
I don't know where you got this figure from, but I highly doubt 1% of Rust projects use a different build/package system. More like 0.001% (this number is scientifically extracted from thin air).
99% in this context is an expression of speech.
OP doesn't literally mean 99%, they mean "almost everyone". The actual numerical value is irrelevant.
OP doesn't literally mean 99%, they mean "almost everyone". The actual numerical value is irrelevant.
Most rust projects with special deps (libtorch) need another build manager.
Regardless parent was implying that almost everyone everywhere uses cargo.
Regardless parent was implying that almost everyone everywhere uses cargo.
Rust is really appealing for applications with native code. C/C++ is still responsible for somewhere between 20 and 50% of software depending on who you ask and how you count. These languages have a ton of legacy to deal with and persistent tedious memory leaks which introduce security issues etc.
Rust doesn't have these issues owing to the "newness" of the language and the memory model. If you're are a C or C++ dev then this is very exciting. If you are an engineer who was always turned off of native coding due to C/C++, then this is very exciting. If you just like languages, then this is pretty exciting to.
Rust doesn't have these issues owing to the "newness" of the language and the memory model. If you're are a C or C++ dev then this is very exciting. If you are an engineer who was always turned off of native coding due to C/C++, then this is very exciting. If you just like languages, then this is pretty exciting to.
Not just native code either, Rust also makes WASM development practical in a way few other languages can.
For that I see it as a matter of tooling more than the language design: wasm is nicely integrated into cargo and is maintained far better than other choices. You can also compile C/C++ to WASM if you want (and the language semantics definitely allows for it, since it doesn't have a garbage collector), but you just really don't want to deal with CMake while doing so.
garbage collector isn't a limiting factor for wasm.
my main issue with wasm is no standard interopt for primitive types. thankfully some sort of FFI is in the works from my understanding.
my main issue with wasm is no standard interopt for primitive types. thankfully some sort of FFI is in the works from my understanding.
In theory yes, but in practice managed languages need native GC support because garbage collectors in WASM code are quite slow. There's a proposal in the works: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
That is one of the appeals of rust for me. I want one language that I can flip from
- Native
- Web
- Distributed
- ML
- Service
programming without having to switch toolchains. Rust is surprisingly close to achieving this.
- Native
- Web
- Distributed
- ML
- Service
programming without having to switch toolchains. Rust is surprisingly close to achieving this.
This is indeed an interesting point. I've worked with C/C++ and every single project or experience had some peculiarity: the platform, the compiler, some version limitation, etc.
HN is about interesting stuff.
Rust is VERY interesting: Novel memory management, low-level, great tooling, can ACTUALLY compete against C/C++ across the board, have a lot of modern stuff: ML heritage, functional idioms (but you can do imperative code, not worry!), const/immutability promoted, NOT NULL thank you very much!, UTF-8 string "oh amazing", a lot of edge cases accounted for...
And, with interesting tools you get people, interested, in build things. And things that before, you can't do without get the complain "but C".
Now, there is NOT excuse to get into the bandwagon of Fast, Safe, yet ergonomic.
--
And when something like this happens, it invigorate the "market" and other will try taking advantage of what this do good and what it not much (so, I see zig, Nim, odin, catapulted because Rust/Go/Elixir make people talk about programming languages)
Rust is VERY interesting: Novel memory management, low-level, great tooling, can ACTUALLY compete against C/C++ across the board, have a lot of modern stuff: ML heritage, functional idioms (but you can do imperative code, not worry!), const/immutability promoted, NOT NULL thank you very much!, UTF-8 string "oh amazing", a lot of edge cases accounted for...
And, with interesting tools you get people, interested, in build things. And things that before, you can't do without get the complain "but C".
Now, there is NOT excuse to get into the bandwagon of Fast, Safe, yet ergonomic.
--
And when something like this happens, it invigorate the "market" and other will try taking advantage of what this do good and what it not much (so, I see zig, Nim, odin, catapulted because Rust/Go/Elixir make people talk about programming languages)
While Nim has of course evolved, it was first released publicly in 2008, and I believe began in private around 2003..2004. Nim is also safe [1] and competes fine with C/C++ across the board, IMO { as do many other PLs. }.
[1] https://uploads.peterme.net/nimsafe.html
[1] https://uploads.peterme.net/nimsafe.html
I understand, and I don't say Rust was first, instead, that having high-profile new langs make people interested in new langs (like nim), because it draw attention to that...
Fair enough. I thought your text was only vaguely suggestive of an alternate timeline, and was just clarifying (and almost said so). :-)
Rust fixes some issues that haven been present in most mainstream languages for decades, while maintaining performance.
There are many such languages or tools - Haskell (or other FP languages) or Erlang being among them - that have some vocal minorities that actually use them. The reality is that these language are highly unlikely to ever gain the traction they might arguable deserve.
There are many such languages or tools - Haskell (or other FP languages) or Erlang being among them - that have some vocal minorities that actually use them. The reality is that these language are highly unlikely to ever gain the traction they might arguable deserve.
Are you putting Haskell and Rust in the same category when it comes to likely future adoption? They seem very different to me - Haskell being unlikely to get much more traction, and the opposite for Rust.
Same take. I don't see Haskell / Erlang / Elixir and the like truly ever taking off. It's not because they aren't awesome (because they are) - it's because what they solve isn't as desperately needed as what Rust solves.
I don't feel like this aspect is debatable. Our systems are miserably insecure and unwilling to trade off performance to become more secure. Without Rust or something like it, there's no chance - that's the difference.
If those here are hoping for the hype to die down, they are going to be waiting a while.
I don't feel like this aspect is debatable. Our systems are miserably insecure and unwilling to trade off performance to become more secure. Without Rust or something like it, there's no chance - that's the difference.
If those here are hoping for the hype to die down, they are going to be waiting a while.
> it's because what they solve isn't as desperately needed as what Rust solves.
Undoubtedly, the issue of memory safety while remaining performant is a game-changer, but the word need is a bit strong here...
Undoubtedly, the issue of memory safety while remaining performant is a game-changer, but the word need is a bit strong here...
> but the word need is a bit strong here...
When 52% of curl's security vulnerabilities were due to it being written in C (mostly buffer overreads/overwrites), I say "need" is indeed adequate.
https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnera...
When 52% of curl's security vulnerabilities were due to it being written in C (mostly buffer overreads/overwrites), I say "need" is indeed adequate.
https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnera...
Why do you think it's just Hacker News?
I noticed on Manning (http://manning.com) "Rust in Action" was the top-selling book for over a month. I think Rust is just a hot topic right now.
I noticed on Manning (http://manning.com) "Rust in Action" was the top-selling book for over a month. I think Rust is just a hot topic right now.
Because I use this as a technical source for many things on a daily basis. Other sites or communities still "balance" the conversation between all kinds of stuff, Python, Java, Node, C/C++, etc. Maybe startups have a stronger Rust following?
You're not wrong.
HN Rust articles: 4 in the last 24 hours (not including this one)
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
HN Go articles: 0 in the last 24 hours https://hn.algolia.com/?dateRange=all&page=1&prefix=true&que...
JavaScript: 5 in the last 24 hours - a much more popular language but none of these got to the front page
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Counting comments per article the difference is even more dramatic
HN Rust articles: 4 in the last 24 hours (not including this one)
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
HN Go articles: 0 in the last 24 hours https://hn.algolia.com/?dateRange=all&page=1&prefix=true&que...
JavaScript: 5 in the last 24 hours - a much more popular language but none of these got to the front page
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Counting comments per article the difference is even more dramatic
Not sure if this is interesting but only one of those Rust articles is about Rust or its usage. The rest are about programs written in Rust.
For Javascript it's the opposite; only one is about something written in Javascript. The rest are about language or its usage.
Not sure if one can say that that's an indication of pumping. Seems more an indication of usage.
For Javascript it's the opposite; only one is about something written in Javascript. The rest are about language or its usage.
Not sure if one can say that that's an indication of pumping. Seems more an indication of usage.
Good point.
I don't know what "pumping" means in this context.
Should we take this as an indication of community interest? Community members are using JavaScript, but interested in Rust and what it can do.
I don't know what "pumping" means in this context.
Should we take this as an indication of community interest? Community members are using JavaScript, but interested in Rust and what it can do.
"Pumping" in this context is a very thinly veiled pejorative. The original question is using it in the sense of a "pump and dump" [1]. They're implying that the amount of Rust content on HN is in some way artificial: it's the strike force[2] posting a bunch of articles, or its some startup throwing "made in Rust" in their title for attention, etc.
As you might guess, it's hard to distinguish between a "pump" and general interest in something. And, of course, each probably does feedback into other.
---------
[1] https://en.wikipedia.org/wiki/Pump_and_dump
[2] https://enet4.github.io/rust-tropes/rust-evangelism-strike-f...
As you might guess, it's hard to distinguish between a "pump" and general interest in something. And, of course, each probably does feedback into other.
---------
[1] https://en.wikipedia.org/wiki/Pump_and_dump
[2] https://enet4.github.io/rust-tropes/rust-evangelism-strike-f...
Not pump and dump, didn't mean to be pejorative. Promoting, or "celebrating" could be suitable to my original question. =)
Well, the Go 1.18 article dropped 3 hours after you wrote this, and has been on the front page ever since. 295 comments so far.
Maybe to some extent it's a similar situation to git. Everybody knew CVS and SVN kinda sucked, there were lots of competitors, but they all remained esoteric until git, which a) had immediate "mainstream" adoption due to the linux kernel and b) was really good. Rust got early adoption due to Mozilla and.. is also really good.
It solves a lot problems, but mainly it solves problems in a kind of idiomatic way that makes it feel like a big paradigm shift, which contributes to genuine enthusiasm. This combined with the massive funding and community around it helps it feel like something you can give yourself to a be supported.
Whether its the best solution or "deserves" its hype is not a real fruitful question you can ask, as there are many things you need a computer to do, and some of them aren't systems programming. Some things benefit from different kinds of ergonomics, thats ok.
Is there a language that is more funded out there right now?
Whether its the best solution or "deserves" its hype is not a real fruitful question you can ask, as there are many things you need a computer to do, and some of them aren't systems programming. Some things benefit from different kinds of ergonomics, thats ok.
Is there a language that is more funded out there right now?
There is a loud group of developers that want to get rid of C, because of it's lack of memory safety, and all the security issues that come with that. Also, there is still love for Mozilla, despite some of their annoying behavior lately.
I don't think Rust is being promoted more than any other language people feel passionate about, but these things tend to go in clusters, so it may seem that way. I think if something specific to a language makes it to the front page, the discussion leads people into looking up things about that language, which then makes them discover, or remember something they think is worth sharing and repeat. The last few weeks I've noticed more Ruby than usual, I see clusters of Python and Go very often, and every year or so there are a few lisp stories in a row. Sometimes this also coincides with conferences.
You don't generally see stuff advocating for bigger languages because they don't need advocates. Instead you might see particular libraries or techniques. I suspect the hype around Rust specifically is people that really like rust hoping that it catches on before it dies out like so many other technologies.
I don't think Rust is being promoted more than any other language people feel passionate about, but these things tend to go in clusters, so it may seem that way. I think if something specific to a language makes it to the front page, the discussion leads people into looking up things about that language, which then makes them discover, or remember something they think is worth sharing and repeat. The last few weeks I've noticed more Ruby than usual, I see clusters of Python and Go very often, and every year or so there are a few lisp stories in a row. Sometimes this also coincides with conferences.
You don't generally see stuff advocating for bigger languages because they don't need advocates. Instead you might see particular libraries or techniques. I suspect the hype around Rust specifically is people that really like rust hoping that it catches on before it dies out like so many other technologies.
It solves a large class of problems that are not handled in C and C++. Some people are hyped that it can solve all problems under the son, while others don't like the hype talk or are deeply invested in C and C++ knowledge and don't like their belittlement.
Without compare language/platform abilities, it looks like a major hype cycle like Node or even Java back in the 90s and early 2000s. I read HN and see a lot of stuff around Rust that I don't see elsewhere, so this is also kind of a "why here?" question too. =)
I don't know where do you compare it to, but the advantages of rust are more technical and not so business oriented as Node or Java. Node and Java were "write once, use twice or more" and it was a major business saving of time and developer resources. Rust's advantage is correctness and lack of bugs which is harder to sell to execs whose horizon is the next quarter profits and not the long-term maintenance costs of the project.
I remember getting into a an argument about Java being overhyped in 1995 but you know Java is still here…. AWT is dead, Swing is dead, JavaFX is dead, applets are dead but Java is still heavily used.
JavaFx is dead?
There isn’t anything you can do in Rust that somebody couldn’t do in C-Thulu, but the Rust version might be secure and the C-Thulu version won’t be.
There are lots of things C++ can do where Rust can't (ex. templates in C++ are much more powerful than Rust's generics as of now), and lots of things Rust can do where C++ can't (ex. handling memory ownership in a much more secure way, hygienic and procedural macros). You might still want to use C++ for any sort of complex programming involving numerical computation and graphics (Rust is getting there but is still a bit weak in some aspects), but for any mission-critical service related to the Web you would be more inclined to choose Rust (because of async support, and since C++ is horribly insecure for any sort of web programming).
Note that generics in Rust are not intended to replicate everything that C++ templates do, Rust has macros for the more complex uses. There's also a lot of vaporware coming from C++ standard development proposals about "metaclasses" and "reflection" being added to some future version of C++, this would basically be their way of doing the equivalent of hygienic macros in Rust. C++ has also added recent support for parallel and heterogenous programming (GPUs, accelerators etc.) for which Rust has no equivalent as of yet.
Curious - what class of problems do you see Rust and its ecosystem handling that C++ doesn't?
Rust may allow 100 engineers to work on the same codebase without spending all their time debugging memory corruption errors. I say "may" because I don't have firsthand experience in a team that big.
I'm hoping to hear something other than debugging memory corruption errors. I've worked in C++ for 15 years in 4 different organizations and across many different teams and memory corruption was never really an issue, certainly not enough of an issue to abandon C++ and adopt a whole new ecosystem. This is the primary reason I hear for adopting Rust and it just isn't an issue for me so I'm interested in learning what other classes of problems does Rust and its ecosystem resolve?
> and it just isn't an issue for me
You have those two findings from Google and Microsoft that roughly 2/3 of the vulnerabilities that they find in their code are memory related, so it is definitely something that someone finds important. Also, if you have large scale codebase that is serving millions of people, the assurance of less bugs is much better starting proposition than maybe it won't fail.
You have those two findings from Google and Microsoft that roughly 2/3 of the vulnerabilities that they find in their code are memory related, so it is definitely something that someone finds important. Also, if you have large scale codebase that is serving millions of people, the assurance of less bugs is much better starting proposition than maybe it won't fail.
If you aren't handling string data from external sources then memory bugs aren't a big deal, I think most low level developers today don't deal with a lot of external string data so to them Rust doesn't really offer much. But for the roles where almost all you do is pipe or parse around data packets then I see the strong appeal, but to me such applications aren't very interesting. So crypto libraries, browser engines and the networking part of servers.
I wonder if part of the problem Google and Microsoft has is they have so many developers having so little real-world experience in a language such as C++? Back in the day we used to be very careful with who did C++ work because it makes it so easy for inexperienced developers to shoot themselves in the foot. But really though, for an established team not having these kinds of issues and not having a lot of new hires to contend with then what else is Rust providing?
No idea. However, every sufficiently complex project will become harder to manage with the accumulation of changed requirements, refactorings, and unavailable contributors. For this reason only the automated analysis of code could benefit an organization by transfering part of the work outside of the human competency domain.
Rust might be a better C++. (Zig is the better C)
The memory safety thing seems to be appealing to some people who believe it will dramatically reduce the security issues found in many software. (they usually know very little about actual security exploits)
Rust is building a cult-like community around it, and I think it could be its demise, I personally hate it (the community)
The memory safety thing seems to be appealing to some people who believe it will dramatically reduce the security issues found in many software. (they usually know very little about actual security exploits)
Rust is building a cult-like community around it, and I think it could be its demise, I personally hate it (the community)
> The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source.
https://www.chromium.org/Home/chromium-security/memory-safet...
> As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more.
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
Removing 70% of security exploits, especially those which can easily lead to arbitrary code execution compared to e.g. logic bugs or DoS issues right at the compiler seems like a huge win?
https://www.chromium.org/Home/chromium-security/memory-safet...
> As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more.
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
Removing 70% of security exploits, especially those which can easily lead to arbitrary code execution compared to e.g. logic bugs or DoS issues right at the compiler seems like a huge win?
I took a look at the Chromium codebase a long time ago, out of curiosity.
I am not surprised it is full of bugs and vulnerabilities, and yes modern C++ idioms are harmful in that regard.
But I am not convinced that Rust is the solution.
But I am not convinced that Rust is the solution.
I haven't seen much pumping for Rust. It is a great language but I see Go and even Ada and Ocaml are mentioned a lot (relative to actual adaption) here. There are lots more esoteric languages getting hyped on HN. There was even a popular post about .NET the other day.
>Go and even Ada and Ocaml are mentioned a lot (relative to actual adaption) here.
That is just not true. Go submissions rarely reach front page. Ocaml has one in months if not years. Go is used a lot, while OCaml appears in comments mostly for programming language comparison purposes along with Haskell and Erlang. C# and Dot Net ecosystem is fifth most popular language on Tiobe and Stack Overflow. Ada mostly get brought up in the context of Pascal and sometimes in the context of Rust competitor. I would even put it to 1:100 appearance compare to rust and people are already put off by it.
There are may be one or two submission about Zig every one or two months that made it to front page and some are already "asking" why are there so many zig submission on HN.
That is just not true. Go submissions rarely reach front page. Ocaml has one in months if not years. Go is used a lot, while OCaml appears in comments mostly for programming language comparison purposes along with Haskell and Erlang. C# and Dot Net ecosystem is fifth most popular language on Tiobe and Stack Overflow. Ada mostly get brought up in the context of Pascal and sometimes in the context of Rust competitor. I would even put it to 1:100 appearance compare to rust and people are already put off by it.
There are may be one or two submission about Zig every one or two months that made it to front page and some are already "asking" why are there so many zig submission on HN.
Maybe I am just biased and notice those.
But .NET is still way more popular (by popular I mean used) than Ocaml, Haskell or even Rust no? (I could be completely wrong, just my impression).
But not necessarily by HNs audience, and it's perceived as "old and boring" and thus doesn't get as much attention, even if large changes happen (I notice this with C++, since that's what I primarily work with: There have been large changes in C++ over the past ~decade, but it takes a long time for people that have an established opinion based on older style to recognize that, a language thats obviously new sticks out more obviously)
There's a cycle to these things, e.g. a few years back "XYZ in Go" was a lot on HN, because that was the new cool thing people were curious about. Now probably more people use Go, but it's not as interesting anymore as something people don't really know yet. And thus projects written in it don't highlight it as often, so even if they are discussed its not as obvious. OCaml and Haskell also aren't new, but haven't reached the saturation of "many people know them", so if something about them pops up its still interesting to more people.
There's a cycle to these things, e.g. a few years back "XYZ in Go" was a lot on HN, because that was the new cool thing people were curious about. Now probably more people use Go, but it's not as interesting anymore as something people don't really know yet. And thus projects written in it don't highlight it as often, so even if they are discussed its not as obvious. OCaml and Haskell also aren't new, but haven't reached the saturation of "many people know them", so if something about them pops up its still interesting to more people.
One problem with new C++ is mainly that old C++ comes along for the ride.
New C++ indeed is a lot better, but the chance that your codebase was created recently is quite low. You will have to deal with al the old C++ in there. The conflict between new and old C++ will cause some lavaflow architecture as a bonus.
Even if you've got a greenfield C++ project, you're not going it alone. If you're a team of 10, it's almost guaranteed at least 1 of them will be programming like it's 1999 with no intention to change. Code samples by your vendor will not be up to date. A quick google will deliver a working answer from the good old days.
It's like hydra. Every time you axe a block of old code, 5 new ones have sprouted up.
New C++ indeed is a lot better, but the chance that your codebase was created recently is quite low. You will have to deal with al the old C++ in there. The conflict between new and old C++ will cause some lavaflow architecture as a bonus.
Even if you've got a greenfield C++ project, you're not going it alone. If you're a team of 10, it's almost guaranteed at least 1 of them will be programming like it's 1999 with no intention to change. Code samples by your vendor will not be up to date. A quick google will deliver a working answer from the good old days.
It's like hydra. Every time you axe a block of old code, 5 new ones have sprouted up.
I might be part of the cult, so take this with a grain of salt. Rust is the first time a language had actually been exciting to me since the 2000’s.
It's pretty good and practical.
The only real downsides are in the library availability and deployment vs. more established languages.
I'd choose to use it if I could though, it has the least downsides of any language IMO.
The only real downsides are in the library availability and deployment vs. more established languages.
I'd choose to use it if I could though, it has the least downsides of any language IMO.
Library availability is pretty much anything with a C FFI, that should cover a lot of ground. Deployment is also very simple, there are ways of making your app into a "portable", self-contained binary that will work essentially anywhere. Rust is also one of few languages that can seamlessly (e.g. with no need for an added runtime) target WASM.
Wasn't Amazon buying ownership of it recently? Seems a substantial disadvantage if that comes to pass
Amazon is a member of the Rust Foundation, they haven’t “bought” the language.
Edit to add: https://foundation.rust-lang.org/members/
Edit to add: https://foundation.rust-lang.org/members/
Hiring core devs and imposing control that way if I'm following the discussions successfully, e.g https://news.ycombinator.com/item?id=28513130.
Interested in reasons to believe Amazon are not going to determine the future of the language, I'm at least six months out of date.
Interested in reasons to believe Amazon are not going to determine the future of the language, I'm at least six months out of date.
inexperienced novices and disheartened veterans alike get infatuated with that new shiny thing ...
the rest of just smirk at the pump articles, as we have achieved state of Zen and realize _all_code_is_garbage_ and that nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care about code let alone a programing language the app was written in
the rest of just smirk at the pump articles, as we have achieved state of Zen and realize _all_code_is_garbage_ and that nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care about code let alone a programing language the app was written in
There is a reason disheartened veterans gravitate toward a project like Rust. We've seen a lot in our career and much of what we do when it comes to our own tools is automate the detection and elimination of causes of bugs where we can.
It is possible to recognize that "all code is garbage" and "it is a miracle anything works" while also still pushing our industry forward and improving lives for software engineers. A language like Rust is about a particular kind of ergonomic fix. It gives engineers tools to prevent certain kinds of bugs from the beginning if they properly utilize them. It gives you tools that other languages do not have built in so will require more work to use in a disciplined way.
For some people they won't care. They aren't craftsmen they are factory floor assemblers. They glue stuff together and quality isn't the top concern. This is not meant to be a critique. There is a large market for that. IKEA serves an actual need for many people. By all means there is still a place for the Java, Node, Ruby, or Python developer out there. There is more of a market for factory floor assemblers than there are craftsmen.
I personally though still prefer to be in the craftsmen category and for that reason Rust is exciting because it gives me tools that I would formerly have had to reach for OCaml, Haskell, or Lisp to use but makes them more ergonomic without introducing other issues at the some same time. It's a pragmatic application of concepts that we've been exploring since the 70's and finally get to see bearing fruit. Brushing it off as just the "next shiny thing" is doing it a disservice.
It is possible to recognize that "all code is garbage" and "it is a miracle anything works" while also still pushing our industry forward and improving lives for software engineers. A language like Rust is about a particular kind of ergonomic fix. It gives engineers tools to prevent certain kinds of bugs from the beginning if they properly utilize them. It gives you tools that other languages do not have built in so will require more work to use in a disciplined way.
For some people they won't care. They aren't craftsmen they are factory floor assemblers. They glue stuff together and quality isn't the top concern. This is not meant to be a critique. There is a large market for that. IKEA serves an actual need for many people. By all means there is still a place for the Java, Node, Ruby, or Python developer out there. There is more of a market for factory floor assemblers than there are craftsmen.
I personally though still prefer to be in the craftsmen category and for that reason Rust is exciting because it gives me tools that I would formerly have had to reach for OCaml, Haskell, or Lisp to use but makes them more ergonomic without introducing other issues at the some same time. It's a pragmatic application of concepts that we've been exploring since the 70's and finally get to see bearing fruit. Brushing it off as just the "next shiny thing" is doing it a disservice.
The LISP comparison doesn’t ring true to me or even the ‘ergonomic ML’. There is nothing ergonomic about Rust at all compared to managed languages, but if you are willing to fight with the borrow checker you can get managed language safety with C speed. (I wonder though if we’d be better off with a closely integrated assembler and theorem prover if portability was not so important.)
You don't really end up fighting the borrow checker after a while. At that point it approaches the ergonomics of managed languages, and particularly it's ML roots really shine.
I write Python professionally and Rust in my limited spare time, and Wow! do I miss the borrow checker when I go to work in the morning.
And of course: the enums, match, Option/Result, performance and a handful of other great stuff.
And of course: the enums, match, Option/Result, performance and a handful of other great stuff.
Rust has AST level macros, i.e. the real ones that lisp is fond of, albeit with more awkward syntax.
What's wonderful about rust is that by making ownership explicit and enforced, it enables less experienced people to learn those concepts and confidently use new approaches to write performant software without having to shoot off their own foot learning C or other languages where understanding ownership is necessary but not enforced.
More experienced people will generally be happy to offload ownership tracking to the compiler and save some of their brainpower for other things.
More experienced people will generally be happy to offload ownership tracking to the compiler and save some of their brainpower for other things.
> More experienced people will generally be happy to offload ownership tracking to the compiler and save some of their brainpower for other things.
For me, the great benefit here is we can explicitly mark down in the code if a parameter is mutable vs immutable. This is a gain since you know explicitly if what you pass in will be changed or not inside the function.
For me, the great benefit here is we can explicitly mark down in the code if a parameter is mutable vs immutable. This is a gain since you know explicitly if what you pass in will be changed or not inside the function.
Rust was a shiny new thing back in like 2018. It gets talked about a lot because it has a lot of ergonomic and conceptual fixes that make life better. People like that. No, not every programming language is the same.
"nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care"
So nobody, other than nearly every software engineer out there. Nobody, except the majority of people working in our field. Okay...
"nobody, other than minuscule amount of people who ever had a git write access in their life, actually care or will ever care"
So nobody, other than nearly every software engineer out there. Nobody, except the majority of people working in our field. Okay...
Pretty much. People are gonna find ways to write atrocious Rust code just like they have with any other language, and no-one is gonna bother to check all the unsafe blocks. Severe bugs may be less prevalent, but life as a a developer will suck just as much. :)
People do consistently audit unsafe usage. And I would rather have atrocious rust code that's memory safe, than atrocious C/C++ code that comes with a free package of CVEs.
There are tools that explicitly exist for this use case, such as cargo-geiger [0]. There was some drama with a large framework called Actix a while ago due to the maintainer having a bit of a cavalier attitude towards unsafe usage. Etc.
0: https://github.com/rust-secure-code/cargo-geiger
There are tools that explicitly exist for this use case, such as cargo-geiger [0]. There was some drama with a large framework called Actix a while ago due to the maintainer having a bit of a cavalier attitude towards unsafe usage. Etc.
0: https://github.com/rust-secure-code/cargo-geiger
History has shown though, that people do check all the unsafe blocks in some projects. I think that was Actix (web?) and probably others. So at least that part of the statement is already contradicted.
I do think the language offers some genuine advantages and strikes a difficult balance between features, practicality and speed.
I think it has some problems as well (the learning curve is still steep, and I don't know if that's solvable).
However I think the reason Rust gets attention here is because it is heavily used in crypto, which is regularly pumped in HN as well as in other places.
(ducks)
I think it has some problems as well (the learning curve is still steep, and I don't know if that's solvable).
However I think the reason Rust gets attention here is because it is heavily used in crypto, which is regularly pumped in HN as well as in other places.
(ducks)
Not sure if you meant cryptography or cryptocurrency, but assuming cryptocurrency...is it actually used that much? I can't think of any major cryptocurrencies that use it. All of the major ones are C/C++.
I can only list Solana (from my experience in Rust spaces with people hoping to use Solana expecting us to be experts)
I'd love a Rust job but there are even fewer around than golang and much less than C++. Any suggestions for a newbie?
Personally I'd take a job based on the pay & how much you like the company vs what specific tech stack they're currently looking for. When I'm getting paid to do it, I like just about any language; getting to use rust is just a bonus. You might also be able to select rust for a new project in the future.
That said, I see postings from time to time in /r/rust. Maybe check the monthly HN hiring threads?
That said, I see postings from time to time in /r/rust. Maybe check the monthly HN hiring threads?
Most rust jobs seems to require a few years of professional rust experience.
We at Nitrokey develop firmware in Rust and are looking for (also newbie) developers. You are welcome to send your application.
It's just at the peak of the hype cycle. Other languages/technologies have gone through this in their day - Node.js and Go come to mind. Eventually it settles. No doubt the advent of some new hotness would catalyze the process.
https://hn.algolia.com/?dateEnd=1262304000&dateRange=custom&...
What are Erlang days for?
Erlang days are where we live.
They come, they wake us
Time and time over.
They are to be happy in:
Where can we live but Erlang days?
Ah, solving that question
Brings the priest and the doctor
In their long coats
Running over the fields.
What are Erlang days for?
Erlang days are where we live.
They come, they wake us
Time and time over.
They are to be happy in:
Where can we live but Erlang days?
Ah, solving that question
Brings the priest and the doctor
In their long coats
Running over the fields.
There is also very bad moderation from HN moderators. Almost every thread discussing C/C++/Go is quickly spammed by Rust evangelist. Which makes it hard to discuss news about those languages.
If you'd like to help with that, you could let us know at [email protected] when you see offtopic or generic tangents. We downweight those when we see them, but we don't come close to reading everything that gets posted here. There's far too much.
Well, many people don’t want to pay the factor of 2 performance cost of a managed language like Java and strcpy in C is Turing complete and most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…
> 2 performance cost of a managed language like Java
It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped.
> strcpy in C is Turing complete
Not something I've heard of - is this an abuse of Unicode?
> most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…
(I've not looked into this deeply) - It should in theory be possible to offer translation from one architecture to another, but I guess it is much more effort than it is worth.
Seems like if you could translate your assembly into LLVM equivalent assembly (or just use it directly), you could then build for the target architecture [1].
[1] https://stackoverflow.com/questions/7773194/is-it-possible-t...
It can be a lot worse too. Java lacks the ability to have really compact data structures and can not lean in too much into the hardware acceleration without becoming incompatible. You can't exactly set `--fast-math`. Shame GCJ got dropped.
> strcpy in C is Turing complete
Not something I've heard of - is this an abuse of Unicode?
> most code has to portable to at least x86 and ARM (often both 32 and 64 bits) so assembly is out…
(I've not looked into this deeply) - It should in theory be possible to offer translation from one architecture to another, but I guess it is much more effort than it is worth.
Seems like if you could translate your assembly into LLVM equivalent assembly (or just use it directly), you could then build for the target architecture [1].
[1] https://stackoverflow.com/questions/7773194/is-it-possible-t...
> strcpy in C is Turing complete
Maybe GP meant printf [0]?
[0] https://www.ioccc.org/2020/carlini/index.html
Maybe GP meant printf [0]?
[0] https://www.ioccc.org/2020/carlini/index.html
> strcpy in C is Turing complete
I was curious too, but my google-fu did not succeed. The closest I found is about printf being Turing-complete [1], which is also new to me.
[1] https://www.ioccc.org/2020/carlini/index.html
I was curious too, but my google-fu did not succeed. The closest I found is about printf being Turing-complete [1], which is also new to me.
[1] https://www.ioccc.org/2020/carlini/index.html
It’s not the strcpy that’s Turing complete, it’s the return afterwards… this is not true about PASCAL and many other programming languages.
> strcpy in C is Turing complete
How so? You've made this claim twice (https://news.ycombinator.com/item?id=27910640), but I can find nothing else to back this up. We know about C++ templates "accidentally" being discovered to be Turing complete, but I've never heard of strcpy() being so...
Honest question, can you shed light on how this can be?
How so? You've made this claim twice (https://news.ycombinator.com/item?id=27910640), but I can find nothing else to back this up. We know about C++ templates "accidentally" being discovered to be Turing complete, but I've never heard of strcpy() being so...
while((*p++=*q++));
Honest question, can you shed light on how this can be?
Strcpy is a good setup for a buffer overflow despite having to run a gauntlet of countermeasures to really pull it off in 2022.
Well, OK, but that isn't fair to say "C" or strcpy(). That's the implementation - so is it surprising that the common underlying implementation of "C" can be coerced into indeterminate or even Turing complete behavior?
It's fair to say that C allows unsafe calls. It's useless to point out that undefined-behavior and unsafe calls could result in Turing completeness. Strcpy() is not Turing complete - it doesn't automatically detect and protect against unsafe usages. That are evil.
It's fair to say that C allows unsafe calls. It's useless to point out that undefined-behavior and unsafe calls could result in Turing completeness. Strcpy() is not Turing complete - it doesn't automatically detect and protect against unsafe usages. That are evil.
IMO C++ was and is still the leading language for writing performance-intensive and memory-intensive applications (excluding Rust), and C++ is really flawed. Like, I know that Java and JavaScript and Python get criticism, but the fact is those languages are still usable compared to C++:
- There are several different ways to do everything and half of them are wrong. For example, you can define an unsigned int type with "unsigned", "unsigned int", "uint32", "uint32_t", "unsigned long". Why are there 5 different types for unsigned integer? C++ also supports C-style arrays and pointers and casting, but most of the time you end up using std::shared_ptr and std::vector or std:array or static_cast or dynamic_cast instead.
- Speaking of which, C++ is even more verbose than Java. Most classes will require 2 files, the .h and .cpp, and it's not exactly clear which code belongs in which.
- The C++ compiler and parser is probably the most complicated compiler that ever existed. There is seriously no other language as complicated as C++.
- C++ errors are very long, very verbose, and it's hard to even find where the error is. I literally had projects where I had a simple error (e.g. calling a standard library function with the wrong arguments), and I spent time trying to debug it because I couldn't even find the error location since the error messages were so long they went past the terminal buffer limit.
- CMake is really bad. I can't speak much to how bad it is because I don't even really know how to use it despite working on multiple C++ projects. But I do know, trying to clone C++ projects with CMake they often fail, and that out of all the build systems I've worked with (including npm, Maven and Gradle), CMake is the one I still don't really understand.
- The C compiler is also really slow. Static analysis is also not very good, even with the effort put towards it, because C++ is so complicated.
- There is no easy way to declare a tagged union (excluding third-party libraries). There are also a few other features that Rust does which take a lot of boilerplate to implement in C++.
- And on top of that, you have buffer overflows triggering security vulnerabilities.
In conclusion, C++ is basically broken, which is why so much time and effort has been put into Rust. In fact, a lot of Rust design decisions (good error messages, simple package manager, tagged unions, the entire borrow checker) were put in precisely because of how badly they were handled in C++. Rust definitely has its own flaws, and is a lot newer and more unstable. But it's the best alternative that allows programmers to write performant and scalable applications which is not C++.
- There are several different ways to do everything and half of them are wrong. For example, you can define an unsigned int type with "unsigned", "unsigned int", "uint32", "uint32_t", "unsigned long". Why are there 5 different types for unsigned integer? C++ also supports C-style arrays and pointers and casting, but most of the time you end up using std::shared_ptr and std::vector or std:array or static_cast or dynamic_cast instead.
- Speaking of which, C++ is even more verbose than Java. Most classes will require 2 files, the .h and .cpp, and it's not exactly clear which code belongs in which.
- The C++ compiler and parser is probably the most complicated compiler that ever existed. There is seriously no other language as complicated as C++.
- C++ errors are very long, very verbose, and it's hard to even find where the error is. I literally had projects where I had a simple error (e.g. calling a standard library function with the wrong arguments), and I spent time trying to debug it because I couldn't even find the error location since the error messages were so long they went past the terminal buffer limit.
- CMake is really bad. I can't speak much to how bad it is because I don't even really know how to use it despite working on multiple C++ projects. But I do know, trying to clone C++ projects with CMake they often fail, and that out of all the build systems I've worked with (including npm, Maven and Gradle), CMake is the one I still don't really understand.
- The C compiler is also really slow. Static analysis is also not very good, even with the effort put towards it, because C++ is so complicated.
- There is no easy way to declare a tagged union (excluding third-party libraries). There are also a few other features that Rust does which take a lot of boilerplate to implement in C++.
- And on top of that, you have buffer overflows triggering security vulnerabilities.
In conclusion, C++ is basically broken, which is why so much time and effort has been put into Rust. In fact, a lot of Rust design decisions (good error messages, simple package manager, tagged unions, the entire borrow checker) were put in precisely because of how badly they were handled in C++. Rust definitely has its own flaws, and is a lot newer and more unstable. But it's the best alternative that allows programmers to write performant and scalable applications which is not C++.
C++ is also hard to read, especially after introducing lambdas.
My 2cents, I'm a software engineer and have been in industry for long time(~20 years). A new programming language doesn't excite me anymore as it used to do 5-10 years ago, then I encountered Rust and I really liked it. All my personal projects, small utilities are written in rust. I specifically look for Rust related HN posts. I think there are many people like me who appreciate rust as a programming language and they make such posts.
people like it?
I'd say rust is the *only* true open-source modern compiled language that can replace C/C++
Go: Too much Google influence and GC/allocation being constrained by it's authors. Swift: Same for Apple, see above Nim/Zig/Crystal/Elixir: Too behind in terms of widespread support and development. (At least not as good as rust)
Go: Too much Google influence and GC/allocation being constrained by it's authors. Swift: Same for Apple, see above Nim/Zig/Crystal/Elixir: Too behind in terms of widespread support and development. (At least not as good as rust)
I know that Rust seems quite powerful, but after years spent invested into learning C-family languages (C, C++, Java, Javascript, etc) it's just a pain to learn.
I've not personally spent much time in it, but I hear the biggest complaint is still the compiler support/performance being somewhat random. Can anybody here speak to that?
I've not personally spent much time in it, but I hear the biggest complaint is still the compiler support/performance being somewhat random. Can anybody here speak to that?
The current issue is really to prevent rebuilding of entire compilation units. Incremental compilation helps somewhat but I haven't found it to be good enough when the size increases. My gut feeling is that it comes from linear or n^2 searches across the entire module due to e.g. parts of the trait system. There's no issue depending on huge crates, when they have been compiled. The first compilation can be painful though. This is especially a problem in CI environments where you need to be clever about the caching vs. clean builds.
To solve this you can move to a workspace structure with internal crates, this makes local changes and tests very fast to compile. For the larger structure you only recompile what is needed starting at where the change originates in true DAG form. On the other hand you can't create dependency cycles.
For a workspace setup look at for example Rust-Analyzer:
https://github.com/rust-analyzer/rust-analyzer/blob/master/C...
To solve this you can move to a workspace structure with internal crates, this makes local changes and tests very fast to compile. For the larger structure you only recompile what is needed starting at where the change originates in true DAG form. On the other hand you can't create dependency cycles.
For a workspace setup look at for example Rust-Analyzer:
https://github.com/rust-analyzer/rust-analyzer/blob/master/C...
Sometimes it feels that I'm being left behind since I don't use Rust yet. Better get crackin'
I know you are likely saying this in jest but I made this comment a couple years ago:
> Also that the HN bubble will always make readers feel behind when in reality 90% of the industry hasn’t even begun to catch-up. I felt behind with K8S in 2016, for example, not realizing we were just seeing the wave form when I felt like it was cresting. [0]
That being said I do have a goal of learning more Rust in 2022 :) I don't care for all the macro usage so I want to learn more about it so it feels less magical to me.
0 https://news.ycombinator.com/item?id=23448835
> Also that the HN bubble will always make readers feel behind when in reality 90% of the industry hasn’t even begun to catch-up. I felt behind with K8S in 2016, for example, not realizing we were just seeing the wave form when I felt like it was cresting. [0]
That being said I do have a goal of learning more Rust in 2022 :) I don't care for all the macro usage so I want to learn more about it so it feels less magical to me.
0 https://news.ycombinator.com/item?id=23448835
Don't feel too bad. I've been wrong plenty of times before, but my prediction is that the Rust hype will fizzle out outside of Hacker News. There's just a lot of use cases that simply don't need its guarantees, and I think developers sticking square pegs into round holes will cause some dissatisfaction in the future.
When you're done with Rust it'll be time to switch to working on Nix. Of course, if you're smart, you'll figure out a way to tackle both at once.
That's how I felt in 2015. 7 years later, i still haven't learnt Rust and i don't see companies around here using Rust anyway
You're not being left behind unless you're in the non-GC language space.
- learn to hate tuning Garbage Collectors
- learn to hate memory safety issues
once you master both of those bullet points, rust starts looking very attractive.
- learn to hate memory safety issues
once you master both of those bullet points, rust starts looking very attractive.
The unwritten rule of HN:
You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.
You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.