Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So does learning a language enough to claim to know it.

True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing. Some people manage to spend their entire career writing useful little python scripts without really "knowing" most of python.

Languages like Rust and Haskell make you learn a lot more of the language up front before you can become useful.

This should not be taken as a critique of the language however.



I don't get what's so hard about rust. You can be productive pretty quickly. I learned it in 2014 as a junior dev/ intern, it took maybe a few weeks to be productive, maybe a few months to really "get" the language/ internalize the borrow checker.

I haven't found that the on-ramp for productivity is higher than any other language tbh, I'd say that my experience with Python was similar, for example.

Can someone who struggled with the language explain what the hard part was? My first language was C++ so I think that's probably biasing, everything looks sane after that.


maybe a few months to really "get" the language/ internalize the borrow checker.

No one is saying it's super hard (assuming you are an OK programmer) just that it takes a month or three of actively working with it to wrap your brain around it, which you seem to agree with.

I'd say that my experience with Python was similar

I've had colleagues (that aren't programmers) who taught themselves just enough python to be productive with writing Python scripts that solved real problems while knowing maybe 20% of the language. Rust will not let you get away with learning only the very basics like that.

They have no idea what a list comprehension or function decorator is, hell most of them have probably never typed the word "class" into a script. In Python that doesn't matter, you can get very far with just basic data types, functions, for loops and cutting and pasting from random web sites.


My personal experience is that most engineers I encounter can onboard to rust very quickly, as I did. But I read online about people who are struggling for many months to do basic work.


There's a terrible combination: experienced developers that have forgotten how hard it was to learn new concepts from scratch, that expect to be able to pick and play by exploration, without a tutor to ask questions or catch their misunderstanding early. I believe that if you remove at least one of these things, learning Rust becomes much less frustrating.


> My first language was C++ so I think that's probably biasing

It is. Anyone coming from anything else than C or C++ will struggle for a while. A lot of things make sense now for me in Rust after days / weeks of playing around with small apps. But the 2 types of String is still one of these thing which anytime I read about it makes (sort of) sense, but then ... Well, I know that using a string literal (with possibly a lifetime) instead of a string, or adding `to_string()` will probably solve my problem. Thankfully the borrow checker along rust analyzer are extremely smart and 2 things which are built to the (close) perfection - the dev experience for beginners would be a total nightmare if it was as messy as the typescript linter


A lot of people seem to get hung up on String vs. &str, but never seem to have trouble with Vec<T> vs. &[T], which is pretty much completely analogous except for the fact that the UTF-8 representation of strings makes it so you can't easily index to a given character.


Part of the problem is naming. They got it right with Path/PathBuf, but str/String is really confusing.


I came to Rust from Scala and I think it actually really helped. My first non-trivial Rust project was a straight port of a Scala library and it was actually pretty uncanny how straightforward the translation was. I'm sure the Rust code could have been optimized to avoid a few clones here and there but in general I've found that you can avoid a lot of the really tricky edges of Rust by just using clone/Arc/Box/etc. In non performance-critical code sections it's probably not even worth avoiding those things.


I love rust . But it can definitely be confusing when you try to do something you are used to doing in another language but cannot do it exactly the same way . For instance , the GOF state pattern. I find it best to return the next state in an option in rust , which is different than other languages .


> True, but many languages let you do a lot of useful things while you are still learning, without requiring you to truly understanding what you are doing.

Well same can be done in Rust. Hate the borrow checker? Just Box/RefCell all the things. However learning that habit can be pricey from execution POV, so most Rust books don't teach it.


Box/RefCell are gonna be way harder than just ".clone()" or not sharing mutable references all over the place.


Well it's the only way to bypass borrow checker as fas as I know. And I assume teaching you a bad habit, then un-teaching it is going to be more expensive than not.

I guess another way could be by using Copy-able structs is anohther way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: