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.

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.

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

> 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.

“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…

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.

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.

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.

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.

>"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.

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.

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.

>"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.

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.

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.