Comment by nevi-me | Hacker News Reader

Comment by nevi-me | Hacker News Reader

Parent Full thread

That sounds like a good opportunity to learn the language. I've had to learn things under duress in my career, often rhat 'low-code' platform whose app is now broken or needs some change, that COBOL system being migrated, whose rules were written before I was born, etc.

Most of what I learn ends up being throw-away, done out of necessity. However, I feel like something written in a popular and growing language like Rust, with an opportunity to learn, maintain, change and improve, would be a net positive.

I'm biased because I learnt Rust in ~2018 and have enjoyed it, however if this were say Scala or Go before I learnt them, I'd feel the same way.

Yesterday I was in a jam session with a colleague, we prototyped something quick and dirty, got it to work, and then refactored it into something neat and clean. This was such a pleasure, because I feel like the language empowers me to make large refactors mostly without introducing breakages (at least when you're shuffling code and types around).

> I've had to learn things under duress in my career

This is how I've learned most things in my career :D

For something like Rust (or other languages like go or objc) though, I could see how it would be hard for someone whose only background is in js or python. There are concepts completely missing or hidden from the programmer that they now have to deal with.

The simpler parts of Rust feel like TypeScript, let's say as long as you're doing simple things as a start and don't worry about threading.

Rust was probably also a lot easier to learn pre-async-await, because one would have to explicitly opt in to multithreading through std::thread.

My first productive language was JavaScript via NodeJS (I learned PHP first, but it was a mess). I did so much with it that by the time I learnt other languages on my own, it was out of necessity.

From a language syntax and concept angle, I'd say Java + Scala were difficult to grok at first. Java for the boilerplate, Scala because I could never understand what the underscore is for.

Kotlin became a breeze and pleasure, then Rust after that. I learnt each language by converting my projects from a previous language to a new one. So that helped me limit the concepts I'd introduce.

Mostly do some calcs, interact with a DB and expose stuff via gRPC. By the time I started with futures, channels and threads, I had gotten far enough programming against a single core.

I often advise people starting out to be gentle with themselves and stick to what they know first. Like other complex languages, one might remain a learner for very long.

> Rust was probably also a lot easier to learn pre-async-await, because one would have to explicitly opt in to multithreading through std::thread.

Worse, you can use both in the same program, which, while safe, is really complicated.

There's a lot to be said for Go's green threads for routine web back end stuff. They avoid the async/thread distinction, because they're both lightweight and can block.

> There are concepts completely missing or hidden from the programmer that they now have to deal with.

Hence the part about learning.

I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience. There are so many things I want to do in Rust when mapping from my C++ knowledge that are genuinely unsafe, e.g. copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes.

Perhaps when one isn't trying to map some similar-ish knowledge onto Rust it becomes easier, as one doesn't have to drop preconceived notions.

This very much feels like the time I tried to snowboard after having skied for a couple of decades; why can't I move my feet like before?!

> copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes

The underlying issue with this kind of informal assurance is that it may become incorrect in a large-scale project as it evolves. This is why "unsafe" in Rust is best used locally, as part of something that provides a safe interface to the rest of the code.

> I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience.

It seems to go one of two ways with C++ developers:

- Some C++ developers were alsready hyper aware of object lifetimes and were effectively enforcing Rust's constraints on their own code manually anyway. They find Rust the easiest of anyone

- Some C++ developers were blissfully unaware of object lifetimes and played fast and loose with them so long as it worked. Those C++ struggle with Rust more even those with no previous low-level experience.

> There are so many things I want to do in Rust when mapping from my C++ knowledge

As someone who came to Rust from JavaScript, I can attest that with a few exceptions the opposite is true for JS knowledge: basically everything I was used to being to do from JavaScript I can do in Rust.

Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement.

Just like there are plenty of idioms you can use in Haskell that are easy to make simple that Rust will make a nightmare to implement.

At the end of the day, Rust is neither of those. It is a safe low level language, and that comes with plenty of restrictions. The language is amazing for how little restrictions it actually has when compared to a naive estimate, but there are still plenty of them.

The problem is that very few idioms are both safe and compositional (which you need if you want your development approach to scale to the largest projects). Rust focuses on these as a sensible default, for everything else there's unsafe.

> Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement

Like? I know double linked lists and graphs are harder to get right, but aren't impossible.

But on the flip side getting Optional and Send/Sync to work in C/C++ and not to rely on people using best practices is downright impossible.

> I could see how it would be hard for someone whose only background is in js or python.

As someone who has trained several Rust programmers, I've seen people hit two major snags:

- Like TypeScript, Rust is a strongly-typed language that gently encourages functional programming.

- Like C/C++, Rust is a language where you need to know about references vs values, and the stack vs the heap.

Someone who's comfortable in TypeScript and C++ will often take to Rust like a duck to water. But someone who's never called "map" or who has never worked with pointers may take longer. A pure C programmer might struggle as much as pure Python programmer, just from the opposite direction.

That said, I love Rust precisely because it allows me to move between a TypeScript mindset and a C mindset as needed. When I want something fast, solid, correct and easy to maintain, it's my favorite tool. But for many team projects, Rust is overkill—garbage collected languages are often perfectly affordable. And there are many excellent choices!

Never heard this before but will now look out for it.

I was always surprised when people said rust had a steep learning curve, yet it seemed relatively easy to pick up to me.

My first language in school was C++ and my first language on the job was Typescript, exactly as you described. I knew both well and then heard about rust and tried it.

> But someone who's never called "map" or who has never worked with pointers may take longer.

When I wrote my comment I was thinking way back to when I was in undergrad and pointers were a huge stumbling block for many. Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging.

That's not say people can't learn, I'm just thinking about how long it takes someone to get up to speed.

> Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging.

To be clear, safe Rust doesn't actually have pointers. (Well, it does, but only unsafe Rust can dereference them.)

But Rust does have pass by value and pass by reference. It has both stack allocation and heap allocation. And it has a notion of who "owns" something. These aren't technically pointers, but taken together, they're basically a safe interface to doing "pointer stuff." Conceptually, all these ideas should make sense to anyone who has worked with pointers and allocation.

Similarly, Rust allows easy mutable state as long as only one piece of code can see the mutation happen. But many programmers are used to being able to share mutable state between widely separated bits of code. And this affects how you design the architecture of your program! Anyone who has done functional programming will see the implications of this early: "Oh, I need build my architecture around immutable state!" So something like an old-school game engine where any entity can update any other entity is a huge headache in Rust. But a game architecture like ECS that carefully restricts mutation (like Bevy) works beautifully with in Rust.

I don't want to trivialize this: Pointer stuff and mostly-functional architectures are both real skills that take time to learn. Rust is amazing for situations where you feel torn between TypeScript and C/C++. But lots of projects just need a nice GCed language and a good standard library, and Rust wouldn't be the right choice for many teams.

I agree with you. I’m learning Rust as a Python-only (bit of Typescript) mostly data-analyst experience and Rust has been challenging, but I’m slowly getting it thanks in part to its new popularity and variety of tutorials.

That said I don’t get what you meant by knowing about the stack vs heap in Rust. I’m not from C++ land so maybe this flew over my head, could you elaborate?

Reply on news.ycombinator.com