Hacker News Reader

Comment by DeathArrow | Hacker News Reader

>Rust was far from perfect when it started seeing adoption by pragmatists

Isn't Rust still a niche programming language? When compared to C, C++, C#, Javascript, Java, Python?

It certainly is and if alone because the corpus of all Rust software is minuscule compared to that of other mainstream languages.

With Rust being in the kernel of both the most mainstream operating systems and it gaining traction in the embedded world it would require a catastrophe of gigantic dimensions to bring that tanker off course from becoming mainstream.

It will take time of course, but that is no difference from other contemporary mainstream languages. I remember that Guido van Rossum being asked what he'd consider Python's breakthrough and he answered that it had none, that it just grew slowly and steadily over a long time. Now, things have been set in motion for Rust, we will see where it leads.

I think Rust will remain a niche language because its main benefits compared to its learning curve are high.

Also, Modern C++ is reasonably safe for most uses, almost safe, and things like Hylo language are IMHO just a better model than Rust-borrow-everything, which is basically viral at the API level and hard to manage compared to mutable value semantics.

Except Microsoft recently decided, even being a C++ powerhouse, that all Azure systems programming that would have been done in C++ in the past, will be done in Rust from now on.

This is bound to 10 million dollar engineering effort, alongside one million more as donation to the Rust Foundation.

The issue with Modern C++, is that we are already in a Post-Modern C++ phase, and plenty of people keep writing classical C with Classes instead.

What learning curve? Between the borrow checker, copilot, and gpt it’s not really hard to know when to use &.

I’ve been rewriting my python personal project in rust the past month and it’s going much quicker than I expected. And with Dioxus I’ll be able to distribute a full multi platform gui app at 10mb vs python + JS and all the fun that comes with that.

Not everyone works in gpt and copilot. Not only using &, but annotating 'a and 'b and 'c all the call stack and when refactoring, redo it again.

I do not have extensive Rust experience, but the times I tried it got on my way. My background is C++ (20 years using, 14 years working on it). They say that best practices in C++ are in Rust, but I think it is not that similar sometimes even from my mindset when thinking in C++. It is just quite a bit more ceremony in real life IMHO what I saw.

The problem is you're probably well above the median developer in terms of talent. Now imagine all the enterprise devs that do boring Java and C# and only got into software because of the pay not because of any passion for it, and imagine how easy it would be for them to learn Rust.

Lmao Ty I’ll put that on my resume if I ever apply for a dev job.

I have not yet tried copilot with Rust, but when GPT-4 came out I made many experiments with Rust, Python and Java to see what it can do.

My conclusion back then was that Rust was by far the worst and that it is mostly because GPT-4 just didn't get the borrow checker. Coming from C/C++ and being a bit of the opinion that the people complaining about Rust's steep learning curve are often a bit overdramatic, it convinced me that they might actually have a point. If even the LLM doesn't get it...

>I think Rust will remain a niche language because its main benefits compared to its learning curve are high.

Honestly? I simply don't think the learning curve of Rust is worth mentioning, or at least it is in my opinion on the same level as C++'s. Or putting it this way: using C or C++ does not mean that you are free of managing the objects' lifetimes.

In Rust you have to annotate all lifetimes, when refactoring them, do it again all the way up and down the call stack.

Since it does not have exceptions, same for propagating Result type up and down. Both go viral. The compiler is strict.

Of course you have to think about lifetimes in C++ but it is more flexible.

That said, Rust pattern matching and traits are nice.

Rust is stricter and the learning curve is steeper overall IMHO.

I really think a borrow checker is not the way to go for safety. Hylo language model is what I would choose first above everything else.

That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain.

You still have to do all the hard work thinking about lifetimes even in C++, things like whether lifetime A will surpass lifetime B and all that jazz. It's just not spelled out.

> That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain

As long as you work a bit defensive and do not use references or raw pointers and use smart pointers and values (span and string_view are NOT values, they have reference semantics), things should be ok lifetime-wise.

It is just that we just want to go, sometimes, a tiny bit faster and fall into the temptation of returning a reference or similar and we mess it up when refactoring. But if you take into account the 80/20 rule, then sticking to safe practices should be the default most of the time and leave a pointer or a reference for an inner loop or something performance-critical in a very controlled environment is the wise choice.

In my experience, sticking to these practices make things work very well in practice. I rarely see a segfault in my code when coding C++. I also use `.at()` systematically, btw. And I am very conservative when using `string_view` and `span`.

This is a really good point and I agree that this is challenge for Rust. The counterpoint I have to offer is that the learning curve is reasonable flat when you are coming from C/C++ and that that is a significant enough target group to pull Rust trough until its new ideas become mainstream. I still remember when object oriented programming came around and that many programmers found it quite alien. A notion that is hardly conceivable today. I hope that it will be similar with Rust.

Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.

Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/ Look at "generational references".

I find the first solution for Hylo as the correct mainstream one and the one in Vale as promising, though not sure where it will lead or if it can keep up to its promises.

Both remove from you a high cognitive overload and keep memory safety intact without a GC.

I think in the grand scheme of things, it probably is. But it seems to have a momentum behind it that I can't quite see in, say, D or F#. Rust's popularity ratings in Stack Overflow's annual survey are pretty impressive https://survey.stackoverflow.co/2023/#section-admired-and-de...

For JavaScript there's been a sharp increase in the amount of tooling that is written (or rewritten) in Rust: Turbopack, SWC, Vite's upcoming rewrite of roll-up. It doesn't seem like it is competing with JavaScript for writing web applications, but the tooling is definitely seeing more adoption of Rust.

In general Rust is great for writing developer tooling. You need low latency, high throughput, low memory footprint while being stable enough that it doesn’t crash much. Projects like Turbopack, Ruff (Python linter), Biome have all had some success and may continue to.

Reply on news.ycombinator.com