Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I think Rust has already failed in its mission to become a replacement for the existing entrenched systems programming languages. The reason is simple - it does not offer safety without spending an inordinate amount of up front complexity. In order to replace C/C++ a language must first and foremost be simple to learn and get started with. Even though Go is 90% a rehash of other languages, it's success comes down to embracing the foibles of programmers and our need for tools that can be ramped up simply and quickly.

Rust is perhaps the language that people SHOULD be using, but likely won't. Until someone can offer something as simple and easy to learn as C and also can automatically do the things Rust provides without asking the programmer to give double in mental effort, I don't think we will replace C in a major way.

View on HN

As a full time c++ developer that just started a rust side project (with rocket.rs) to learn the language, I fully disagree. Coding is actually fun again, and it is becoming increasing harder to code c++ at my job. I constantly get reminded that gb free languages can do better. Damn rust, you ruined c++ for me :(

Edit: Ok maybe a bit dramatic, but I really hoped we would get working modules with c++17 and here we are still years away...

We have working modules with C++20.

Granted the only way to fully enjoy them is being on Microsoft ecosystem, but hey plenty of us are.

I hope that in the future, new code written is C will be seen as similar to using unencrypted communication on the Internet.

It is not about how easy is it to write rust. It is about how, as a C programmer you are going to explain that your code is safe.

I know that as a long time C programmer, I still make occasional mistakes that lead to memory corruption.

In production code, there are still way to many pointer bugs. Use after free, etc. That needs to end.

>"I hope that in the future, new code written is C will be seen as similar to using unencrypted communication on the Internet."

And I hope that people stop preaching and would live and let live.

HTTPS took off when Let’s Encrypt (and to some degree Caddy) made it easy to be secure. Rust is more like, I dunno, openssl: easier than doing everything yourself by hand, but not even remotely easy.

Using C instead of Rust is similar to rolling your own crypto because openssl is too hard.

There are easy languages like Python or Go. But they are not suitable for many low-level, high performance tasks.

Rust is competing in the domain of easy to use languages. It is about low-level system code.

Edit: Rust in not competing in the domain of easy to use language

> Using C instead of Rust is similar to rolling your own crypto because openssl is too hard.

Probably, yeah. At least in a world where openssl is actually so hard that doing stuff yourself seems like a reasonable idea, because theoretically secure doesn't do anything for you if the thing is too hard to actually use - there's a reason PHP utterly dominated webdev even when it sucked for security.

> Rust is competing in the domain of easy to use languages.

Then it loses. If you meant to write that Rust is not competing for easy to use, then it loses separately, because technically superior but too high of a barrier to entry still loses (there is a reason we aren't all exclusively running software written in Ada on OpenBSD).

In what way does Ada have a high bar to entry? You just need GCC to get started with it.

It's not about compiling code, it's about being able to write it. IMO, C is easier to write than Ada. (Write badly, perhaps, but this is about the lowest barrier to entry)

> Rust in not competing in the domain of easy to use language

In a sense Rust very much is competing in this space. Consider the extensions to JS (wasm), Ruby, Python, and others that make it easy to call out to Rust. This is being used for performance critical sections of code (or access to high quality stable network and security focused libraries). This competes directly with that native language but offers a path that is easier than C or other options.

Rust appears to be finding a lot of success in that space.

Oh please. Preaching about safety in a globally inter-connected world devoid of privacy.

Newsflash, it's not a language's job to make software safe. It's job is to make programmer's job as simple as possible: ie. writing new software. If your language fails to do that, people will not use it, plain and simple.

How else could you explain the popularity of languages such as Python and Go?

You'll notice that both of those languages also give you safety by default. It's pretty much only C and C++ that still make programmers write artisanal memory leaks.

I didn't really understand Rust, until I saw a Cppcon talk about how to use STD.unique_ptr correctly, and I realized that the rust borrow checker is just that talk implemented in a compiler.

How can you explain the popularity of big macs and coca-cola if the purpose of food is to help people build healthy bodies?

Maybe your criteria isn't universal?

We are talking about software here, don't change the subject please. My language preference won't make me unhealthy.

If your project can be written in Python or Go, then yes, do that. I don't think Rust is trying to compete with Python or Go.

However, if the project needs a low-level language. Then skip C and C++ and use Rust.

Almost from the start, high level languages have been about safety. In assembly, memory is untyped. That leads to way too many bugs. So languages evolved to get more eleborate type systems. Compare for example K&R C with lacked function prototypes with current C that does have them. That saved huge numbers of bugs.

Traditionally, garbage collectors had to be used to maintain memory safety. However, that conflicts with many of the uses of C. So Rust had to come up with something that is both safe and compatible with C.

> Preaching about safety in a globally inter-connected world devoid of privacy.

What kind of logic is that? "Because Google sells your data, I don't have to worry about memory safety bugs in my code." Come on.

IMO rust is much easier to learn than both C and C++ for anyone who is not already familiar with those languages. I suspect it will pick up adoption merely because people don’t want to deal with C or C++.

The learning curve of Rust is extremely front loaded compared to C or C++, even though C++ might be more complex overall than Rust, that is the issue. C is simple, and I don't think anyone who has read K&R would honestly say it's harder to learn than Rust.

I think that’s only true for very simple programs. As soon as you need to use a dependency C and especially C++ front load a bunch of complexity around build systems, header files, etc. C doesn’t even come with a HashMap built in, so you end up hitting this very early on.

My C class was 12 years ago but I still remember vividly struggling with it on a relatively basic program: figuring out to make the teacher's library work, being greeted with “Segmentation fault core dumped” with zero additional clue, hence needing to install GDB and learn it…

Rust is much much more gentle to learn than C: when you don't understand what a pointer is and how it works, you get an explicit error message given by the borrow checker and you can just ask on the official discord channel for beginners and you've solved your problem.

"and you can just ask on the official discord channel for beginners and you've solved your problem."

If only we had discord 12 years ago... The reason you struggled with C is simple: lack of theoretical knowledge. Your teacher should have started with core workings of a CPU before he showed you C.

Maybe he did, but you simply didn't bother to learn?

One might argue that one of the problem with C is lack of good resources teaching that theoretical knowledge. For example, the Rust book has a great section teaching the difference between the stack and the heap. Most C resources I have tried to learn from in the past have just assumed that I would learn that sort of thing by osmosis.

Theoretical knowledge is aquired at an university or by reading a book on computer science. Then, you apply that knowledge when you use C or Rust. It is good that Rust book teaches about some CS concepts, but that is not a job of a book about Rust and can be considered a bonus.

To really learn about the innerworkings of the CPU, you must read a book about...the innerworkings of a CPU.

> To really learn about the innerworkings of the CPU, you must read a book about...the innerworkings of a CPU.

That's simply not true. There are all sorts of learning resources that aren't books. I have personally learnt a ton about the inner workings of CPUs by following the /r/rust subreddit for example.

Most program languages are accessible to people without a university degree or the desire to read a doorstop book on the subject. C and C++ are a notable exception to this. I don't know how you can argue that a language is easy to learn whilst simultaneously holding that it requires a university degree.

> To really learn about the innerworkings of the CPU, you must read a book about...the innerworkings of a CPU.

But C doesn't map to the "inner workings of the CPU", it maps to a certain abstract machine, defined in the C standard [1]. If you think that C maps to an actual CPU, you're already using C wrong, and it probably shows – in the form of undefined behavior bugs.

[1] standards, actually, pick your preferred version

“C isn't hard, you simply didn't bother to learn” is probably a great summary of why C and all of its ecosystem is really hard for beginners. I'm really glad that the Rust community as a whole accept the fact that Rust is harder than most languages (by that I mean Python, PHP, Java, etc. but not C) and putting a ton of effort in learning material and ergonomic tooling.

Holding this kind of argument in a thread about how Rust is too hard is a bit strange though…

Yet nobody has ever written & published a production grade persistent key-value store in rust. It's puzzling.

I thought tikv was supposed to be this, but perhaps I misunderstand.

Tikv uses rocksdb which is not written in rust.

It's not as simple as Python though, most people who are writing C++ are doing so because they already know it (e.g. from school or past work) or they have no option (building on an existing C++ codebase). Being in the position of "I need to learn a first systems language, should I pick C++ or Rust" is not very common, IMO.

The point of rust isn't to be simple. It's to prevent all the C++ people from whining that all the higher level languages have GC. In truth, 95% of them should just be using a language with GC (i.e. C#/Go/Python), and the other 5% that claim they understand how unique_ptr works should have no problem switching to rust, because they are already running an implementation of the borrow checker by hand to verify that their code doesn't have bugs.

>"It's to prevent all the C++ people from whining "

That's some very thoughtful and noble goal. Maybe people who use C++ (and bunch of other languages) are not the ones whining.

For most of my projects, I would switch from Rust to a GC language in a heartbeat, provided that it

1) is as safe and as fast as Rust, or at most 1.5x slower

2) offers "fearless concurrency" and easy, safe, and efficient parallelism

3) has sum types and a good static type system

4) has great tooling and package management (see cargo)

5) has a vibrant and growing ecosystem

So far, that language doesn't seem to exist. Most fail at points 1+2.

The new concurrent ocaml is improving in all of them.

For me, Haskell is already there (maybe you find its ecosystem not vibrant enough?) and OCaml will be there with multicore OCaml.

I accept that Haskell is that language for some. As for me, I tried Haskell twice, and gave up each time:

1) reasoning about performance is just too difficult (due to lazy evaluation)

2) the community seems too focused on providing ever more abstract abstractions instead of practical solutions to actual problems

3) purity and freedom from side-effects cause a lot of friction and make many simple problems really hard; the libraries and patterns to solve that problem are too complicated for me to comprehend, so maybe I'm too dumb for Haskell (though I don't have any problems with Rust, so...)

Swift and Kotlin are partial matches. Sadly, that’s about it.

I don't think anyone is claiming that Rust is as simple as Python. Nor is Rust really targeting Python users. Java isn't as simple as Python either, but nobody thinks that makes Java unsuccessful.

> Being in the position of "I need to learn a first systems language, should I pick C++ or Rust" is not very common, IMO.

What makes you think that. Everyone who learns systems programming is in this position at some point. Perhaps not if they learn at university and the language is chosen for them, but that just pushes the choice onto the university itself. And universities are increasingly offering Rust courses.

Of course, plenty of programmers aren't systems programmers and never will be. But that doesn't negate the need for systems programming languages, as demonstrated by the continued use of C and C++. If you do need a systems languages then Rust can make a good case for being the simplest. And could well become the de facto standard over the next few years.

>"But that doesn't negate the need for systems programming languages, as demonstrated by the continued use of C and C++"

C++ uses far exceed systems programming.

That’s all reasonable, I just feel like there’s a bit of a critical mass needed to really enter the mainstream as a “de facto standard” and I don’t know if the activation energy on Rust is too high to reach that critical mass

Rust to me is starting to feel like how Haskell was a decade ago, where it seemed like everybody was talking about it but serious adoption was always just on the horizon.

But maybe my expectations are just too high. It seemed quite exciting at first to see everything being rewritten in Rust but I guess that’s not how the software world really works. Old projects are entrenched because they take many years of dev time to mature

> Rust to me is starting to feel like how Haskell was a decade ago, where it seemed like everybody was talking about it but serious adoption was always just on the horizon.

I think you might just not be aware of how widely adopted Rust already is. Google, Microsoft, Amazon, Dropbox, Cloudflare to name just a few companies already have important projects in Rust. Curl is adding a Rust backend. The Linux Kernel hasn't committed yet, but groundwork has begun and it's looking like it's going to happen. Serious adoption has already happened.

You're right that we won't see mass rewrites (although there have been some). That's just too big a project. But new projects are increasingly choosing Rust. It'll be a decade before Rust is the de facto standard if it happens. But personally I consider that quite likely.

Yes python was easy but I've never really bothered with C++. It looked so hard and scary. But Rust gave me more guarantees. It was easier to start learning and do something with it.

You casually mention C++ along with C but you can't really put them in the same bucket. C++ is terribly, mindbogglingly, utterly, complex, its main selling points being zero-cost abstractions and compatibility with C. Perhaps we have different experiences but I don't see Rust as complex to learn with respect to C++. In C++, coming from C, the syntax is deceptively similar but you have to track in your head where the memory is, and seemingly simple operators like "=" or "()" can mean a whole lot of different stuff. Not to mention the craziness of the more advanced features.

Rust is first a system programming language with zero-cost abstractions with the least possible pain, then it is a safe language, way safer than C++.

In any case I am following the community and I have a hard time finding people saying C++ is nice for them. There are few people who have been coding C++ for 20+ years and "love" it but they are far and between. Almost nobody tried both Rust and C++ and continued using C++ for new projects.

So I predict Rust won't replace C, they have different use cases, but it will make a dent in C++.

There is one caveat though, as long as Rust depends on LLVM, it won't fully make it.

> as long as Rust depends on LLVM, it won't fully make it

Why won't it? I haven't really used rust or LLVM before, so I am genuinely curious.

LLVM is written in C++, so any change of Rust compiler that requires changes in the backend requires C++ knowledge, and naturally dependency on a C++ compiler to get the rust compiler binary.

Ah, I see what you mean now. The follow up question I have is: so what? Python is an extremely popular language that is built on C/C++. Unless you are a contributor to the rust spec, why would it matter what language the compiler is written in?

The way I take it, the rust compiler team can either spend their time trying to get to being self hosted, or they can spend their time making improvements to the language.

Because one of the Rust goals is to improve the security landscape and reduce the use of C and C++.

It is a bit hard to achieve such goal if improving Rust requires to some extent, to keep writing C++.

Naturally some day the compiler might be fully bootstraped, however that implies throwing away the work being done by legions of C++ devs on LLVM (same applies to be front ends being written to plug Rust into GCC).

Yeah, it would be nice if the compiler team was dog-fooding, but we need to be pragmatic don't we?

Indeed, hence why many need to understand that Rust vs C++ isn't a zero sum game, and any improvements to C++'s own security story are more than welcomed.

Excellent point!

Rust isn't nearly as hard as it seems. Most people who think it is hard went up against it once or twice for a week or so and gave up. What they didn't realize is unlike some other hard languages (ie. C++) once you are over the initial learning curve, it is pretty smooth sailing, and it codes quite fast - almost like a higher level language. It has a very nice payback for the effort I think.

I recommend the 2nd edition Oreilly book + writing lots of code for about a month or possibly two. After that, I think many will agree it isn't nearly as hard to write as they initially thought it would be.

The biggest bonus: Writing Rust is very fun. I can't pinpoint why this is, but I totally understand why it keeps getting voted favorite language. A total joy to write.

There is a way in which Rust reduces mental effort: a compiled program is more likely to work in the way you expect. It cuts out a swathe of post-compile testing and prodding, or at least, it does in my experience. I can't speak for the other people who have voted it "most loved language" six years running, but that's one of the reason why I love it.

It was the phenomenal Rustlings course that got me over the learning hump.

I continue to be surprised by this despite logging some good number of Rust hours. Cargo run and it just works as expected even with complicated data sharing code etc.

Of course most of the work gets done by the compiler safe guarding and guiding during development. People make noise about lifetimes etc but once you are ready to pay the penalty of Arc (and in most cases if you are using lifetimes you are already on the verge of using Arc). Same with using cloning as needed. End of the day, these incur a predictable and acceptable performance penalty than many other languages do while providing good safety.

> something as simple and easy to learn as C

C is neither simple nor easy to learn. Incorrect and buggy C is simple and easy to learn.

If you think C is "simple" and "easy to learn", your C code is almost certainly full of undefined behavior bugs and security holes.

Testing for off-by-ones considered hard. Gotcha.

You're trying to make a joke, but the flippant dismissal of all the UB is pretty much exactly what they're talking about.

Writing C with a "how hard can it be?" attitude is a great way to get a CVE named after you.

Writing software, especially systems, low-level software is hard. Writing C the language, is not hard by itself. You can't confuse problem domain with language's percieved shortcommings.

Rust won't make systems programming any easier, it will still require the usage of unsafe part of the language. Only, you will also have to deal with a much more complex langage than C. That is why Rust has failed to replace C and C++.

In C you find

- types of varying width (how big is an int?). Rust solves that

- null terminated strings. Rust's are saner

- what happens in an overflow? What are implicit casts? Rust clarifies those edge cases

- standard libraries often use NULL to signal error, no actually -1, no actually non-NULL. Rust has Result

And I haven't even scratched the surface...

All those cases are pretty basilar and happen everywhere. For me it's clear that C is much more complex than Rust if you think about the edge cases. All those safeguards are vital.

But yes, Rust is a much bigger language than C so it won't replace it for really low level, scarce resources tasks. For that look at Zig

Indeed, otherwise the CVE database wouldn't be full of exploits due to off-by-ones memory corruption issues.

By the way, it is sooo easy to test for them,

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

Rust was created to replace C++ in Firefox. Today, lots of Rust code in Firefox, replacing C++, and no Go code in Firefox. Therefore, for this goal, Go failed and Rust already succeeded.

Not a good example, since the Firefox experiment is going to be way more tolerant if rust's shortcomings than the rest of the industry.

I think it's too early to say it's failed to replace the existing systems programming languages and its trajectory looks positive. For example, in the 2019 Stack Overflow developer survey[1] only 3% of professional developers reported using Rust. A year later[2] it was 4.8% and a year after that[3] it was 6.4%. So in two years professional developer use doubled, by that metric. For reference, in the SO surveys C++ and C use was about 20% and 16%, respectively and, if anything, slowly declining (as a percentage of respondents, of course).

1. https://insights.stackoverflow.com/survey/2019#technology-_-...

2. https://insights.stackoverflow.com/survey/2020#technology-pr...

3. https://insights.stackoverflow.com/survey/2021#technology-mo...

If I where to write a small command line tool utility that needs to be fast, safe and lean I would definitely write it in Rust. It's got the tooling C++ don't (cargo), the ability to statically compile a minimal binary that small and fast (because we don't pay for abstraction like C++) and allow me to write reasonably clean code using functional paradigm. It is reasonably easy to interface with C code (did that recently to access libelf and fuse). Unit testing and documentation is embedded with the language.

So, I agree with you, it will probably not become a replacement, but it succeeded in providing a credible alternative that has been used by many already.

Reply on news.ycombinator.com