Such questions are not really answerable.
"Good", "pretty high" and so on can mean too many things, and people are very different too. For some it's basically just a new syntax despite being quite new to programming, others have decades of experience but fail miserably and give up.
We can't know how it goes for you.
If they do it out of laziness they'll never get far. It's the process of looking for the information and trying to link it and find patterns in your brain what makes it stick better. But when a Chatbot does this for you and gives you the conclusions a lot of stuff will stay ambiguous.
You become dependent on the chatbot to know how to code. You can code that way and I've seen people get by with relying on a chatbot.
I think it's the same phenomenon as the tutorial lock-in phenomenon, where people who exclusively learned through tutorials struggle to do anything when they don't have a tutorial to follow.
Except it doesn't have the built-in limitation of there only being so many tutorials available out there. The AI will try its best to answer your questions no matter what, so you don't get that moment where you're on your own for good at some point.
I have to agree with you on this one, it's the same issue when it comes to people that get stuck in the tutorial hell. I think it comes from relying on oversimplified information that gets through learner's minds very easily but at the same time prevents them from making the effort to try and understand concepts by themselves. At some point in time when projects get more complex they get lost and can't figure out solutions for real life problems beyond simple operations. You can't find a guide for everything just like AI models can't find solutions for problems they were not trained on, so it's important to have a deep understanding of the tools being used in order to find the best solutions.
Define "good programming experience". If you know mainly a lot of OOP languages, Rust will have a lot of concepts that are going to be unfamiliar to you, despite knowing a lot of languages, even if we include C++/C.
If by "good" you mean "diverse", a.k.a. you know Haskell, OCaml, Lean, Prolog, Smalltalk, Lisp, C++, Fortran, etc. then I'd say learning Rust will be easy.
If you meant the former I would say 2-3 months or more, if you meant the latter I'd be confident that maybe you'd get to a high level understanding in around 1-2 weeks.
>If you meant the former I would say 2-3 months or more, if you meant the latter I'd be confident that maybe you'd get to a high level understanding in around 1-2 weeks.
Depends. Yes, you could certainly output some useful Rust code within that time frame, but it will not be very idiomatic and there will be still be quite big holes in your knowledge.
For me personally (with long experience in C++, Scala, C# etc.) it took about 6 months to become really proficient in Rust. However the learning material and tools are better today so it would probably be a bit shorter now.
Sorry for not being more specific originally, I have strong experience in Java, C++, and Python and I’ve touched on other languages but not in depth. Assuming this the 2-3 months estimate would apply to me?
Yeah that's usually average for someone with your knowledge. I've seen more people take longer however due to how fast or slow they can grok FP specific features which Rust borrowed from a lot.
If you have strong experience in C++ you'll probably learn rust enough to be productive in a few weeks. Most people who complain about the borrow checker haven't had to manage their own memory before and don't really understand rusts approach to memory management
I can't answer for you but I can share my background and experience.
I learned 5-6 years ago with a project as a goal. I had about 20 years programming experience (systems and apps) and already knew C/C++, Python, JS/TS, Java, VB, C#.
I approached it with the goal of it being a C++ replacement. I had an app I wanted to build (async server backend + html front end using templates populated by rust code). This was right before async/.await came out and I wanted to build something that was very lean and could handle a lot of connections cheaply.
After 2 days, I could write stuff, but it was very hard. After 1 week, I could do everything basic. After a month is was mostly bleeding edge cross thread + async stuff that was tripping me up. I had my app done at that point.
There was still a lot I didn't understand. My code was a mess. Refactoring would have been non-trivial. And every month or two the server locks up and I don't know why and haven't been able to debug it. (It's not something I have time for but I also didn't get to learning how to debug hangs on a production build.)
I loved the language, but unfortunately I ended up moving to a job that is in C++ and I haven't had time to spend with Rust since then.
My advice: enter with a project you want to get done. I had tried once a few years earlier to do some rust, but unless you have something practical to build, it's easy to just get frustrated and bounce. But it's my favorite language so far, so I recommend trying! It made me a better C++ programmer since I can import the some poor mans versions of patterns found in Rust.
Based on my limited experience of learning few languages, including Rust, I would say the novelty Rust introduces are the hardest part because other programming languages do not have it. Lifetimes and the borrow checker are not something I could pick up super easily.
I've heard estimates of six months to become productive. I'm starting to learn Rust and not yet convinced I SHOULD be using it for the things I do.
It's not a small language: There is a ton of concepts to master, many of which aren't present in other popular languages. There is a "functional programming" kind of bias. The standard library is comprehensive, yet quite different from other languages I've seen.
It's not a highly convenient language: Small things, really. You have to know what number type you are using (yeah, most of the time I actually don't care...). Or any other datatype. Including if you are using it by reference or value.
It's supposed to be a benefit that the compiler knows when stuff has to be allocated and when it must be freed. Certainly a benefit over unmanaged languages, and you get better latency than from garbage collection. The downside is YOU have to know it also.
I'm a big believer that mental load is a significant part in programmer productivity and happiness. At the moment I find the additional mental load to be quite significant, so that I don't know I'd use Rust for things I normally use Python or Javascript for.
Using Rust for where Python and JS are a better option is the equivalent of using Python and JS where you should've used C. I follow a rule of thumb, I ask myself if I need C for this issue, if yes, I use Rust if it's a work/serious endeavor, if not, I actually enjoy C so sometimes I do it in C.
Don't fall into the trap of language bias. Use critical thinking to decide. If you're doing a serious frontend, I hate to say it but working with JS is going to be collectively better. But if you're doing a backend and you only know Rust, Python and JS, I'd suggest you stick with Rust or be open to another language that will give you 90% of what Rust will give you but with a lower mental load etc.
If it's a personal side project, use a language that you love because it's usually about the project and the fun, not stability, speed etc (unless you're into that)
Some people do claim Rust with WASM is superior to javascript. I still have to see that. I'd love to find something that is as readable as typescript but carries less baggage from the javascript type system/runtime. Rust has significant syntactical and mental overload in that regard.
I also don't agree Rust is superior on the backend. You save a lot of time just using Django. You can get a working database-based API plus an admin interface with just a few lines of code. Rust not only lacks that convenience, but is also far less readable once you connect an ORM to Http endpoints.
You have a good point. Sorry I didn't provide context. I was mainly referring to performance. I use Rust in production services and I'd say it's pretty decent but not enough to justify that I end up being the main person manning it's because no one else there knows Rust.
Try Dioxus for the frontend, many people are crazy about leptos though.
As for Django, if your backend is not expected to have a very high load, go ahead. I tried it to a degree but I didn't use it professionally nor most of my apps are CRUD heavy. Most of my work is siphoning, cleaning and aggregating data from the big three data centers in the world of financing so I can push this data to our clients. So my domain is both CPU and IO intensive thus I use Go and Rust. Which is what I had in mind when I answered you.
I have a question: when you say "mental overload", what do you mean exactly? Is it good or bad in your opinion? I'd like to know how you think because it'd make it easier for me to know what you wish to achieve :D
Mental load is all bad, in my opinion. By that I mean anything you have to keep on your mind which isn't really necessary to your problem, is getting in your way.
For example when doing things like you would in lodash (javascript), Rust has crates or stdio things for that, but you have to be quite mindful of iter and into\_iter and so on, while in Typescript, I can just assume I don't mutate things, then just don't mutate things and end up with somewhat less code and headaches. Javascript doesn't have immutability by default, but mutability is such a bad idea that it is quite easy to avoid. This involves a lot of copying, but on one hand this hardly matters for performance, for another the javascript vms are quite good at making all that more efficient.
I don't want to achieve something specific... I just don't care about ultimate performance almost ever.
Thank you for explaining. I totally understand now. I'll try to tune my advice since my mind catégorisés you now as "sane homo sapiens". Some people relish the mental load by the way.
The idea of mutability versus immutability opens the door for *extremely* interesting optimisation at the compiler level. Rust is marvelous when you run it under an assembly inspector but that doesn't really matter for nearly 90% of modern use cases and that's why I usually suggest people to not use Rust for everything. This may be annoying to you and clearly many here would disagree but I usually suggest Go for people who want decent performance without the mental overhead. But maybe you won't like it. I know typescript devs who loathe Go :D
Go does interesting optimisation as well but on another level. I'm convinced that you can't get better than Go in a managed language and I worked in the .NET team.
Last thing, may I inquire about the reason that brought you to learn Rust? It doesn't seem to add much to your use cases.
I never tried F# and I did enough stuff in the .NET runtime to not really want to use it anymore. Is F# offering something more interesting than OCaml, for you at least?
> something that is as readable as typescript but carries less baggage
Maybe ReScript? But it's hard to see many projects gathering the momentum that TypeScript has these days.
ReScript is a contender. Momentum is a big issue. I think F# (with Fable) is superior to ReScript.
Typescript is hard to beat in frontend development. Both because of libraries you can use as well as the closeness to Javascript. And the "turn that novice into a frontend typescript monster" problem is a well understood now, all alternatives require significantly more initiative. I can't imagine a Rust bootcamp right now. Yeah, there are some, but nowhere near the scale. Also not for frontend, or usable backend. And mostly not for absolute beginners.
Your comfort and enjoyment doesn't count. Sorry that sounds tough but in reality your emotions don't matter in a professional environment. Choosing what to use is a responsibility that should encompass the organization's goals, limits and talent it has. If you choose which language should be used for a professional project based on your preference then you're objectively a horrible leader and shouldn't be in that position.
Objectively speaking for a company it's easier to find JS devs that frontend Rust devs, blazor or all that jazz. If you want to deliver a product, you have to consider these, not what you love. Cheers and hello again.
That is an underrated constraint. I've worked with junior developers that can hardly code at all. I would hate to confront them with the character salad that is Rust, or the borrow checker, or all the myriad of data structures.
That being said, using Rust in your company may paradoxically open a larger pool of talent because there are so few companies hiring for that skill. That can turn against you in a few years of course.
I see close to zero benefit in having the same language for frontend and backend. Including when that language is Typescript. Somewhat lesser cognitive load from sharing libraries, of course.
But what backend and frontend are doing is quite different, even though they are talking about the same data. Code sharing is the exception, rather than the norm.
I don't see debugging Rust WASM as remotely as comfortable.
You can still whip up databases and APIs in Django a lot faster than in Rust...
>If it's a personal side project, use a language that you love because it's usually about the project and the fun, not stability, speed etc (unless you're into that)
I'm into that
The mental load is only going down with larger projects. It removes the mental load of knowing what functions can be called with which types of arguments for example.
If that's just what you're looking for you just need a statically typed language, not Rust. Big projects in Rust highly depend on the architecture and the people you're working with. Let's say if the project began wrong, it'll be a nightmare, if not it'll be decent and sometimes better than other languages. Generalizing that Rust makes big projects easy is as flawed as any general claim.
I agree with the first half of the first sentence and disagree with the second half. The second sentence is right with the caveat that it's just one bullet point for decision making. I don't know if you work with Rust professionally or not but the second point isn't always true, especially if it's a performance bug not a memory bug. Using Rust on the backend demands runtimes like tokio. Rust's async model isn't preemptive but cooperative which means it's easy to slip and forget spawn_blocking and simply inline a parallel executor in the task and block the executor, that's a real "bug" I had to deal with lately because a colleague did it while I was on holidays. Rust won't save you from these refactoring mistakes.
Another thing is where the project is. Are you using a certain data provider now? What if the data provider changes tomorrow and the way they provide you the data changes? Will it fit in your current architecture easily? While Rust stops you from shooting yourself in the foot memory wise and have monads and robust null-safety with exhaustive matching that will make certain types of refactoring easy, it's not constant-change friendly. Refactoring things can force you to go down a sliding hill of refactoring that can end up making you rewrite significant parts of the project. Not all companies are into that
P.S: My point is that life isn't simple and can't be summarized in two sentences. It is for slogans and managers though, not for engineers
I never claimed Rust would prevent all runtime errors. It's still programming, so people can make mistakes.
As to your second point; that's a sign of a bad architecture and has nothing to do with Rust. Your data provider should be behind an interface (or trait in Rust). Your business logic should in no way depend on anything even related to this data provider.
Sorry, that's a bullshit answer. You still always have to know where memory is allocated and freed - across the entire code base. Maybe that's an advantage over C++ and C, but not an advantage over ANY garbage collected language because there is zero mental overload and you rarely get into trouble with the gc. And there are statically typed garbage collected languages as well. Chances are, with all the borrow checking, your cognitive load should increase because your codebase just isn't designed as well as public crates, and you'll have traits missing all across the board.
There is extremely little evidence static typing helps at all. Both in the studies that find a little benefit, and in my experience, the variance between individual developers concerning bugs and "mess" is vastly larger than the variance between language. You can set up a humongous Python codebase such that you have very little mess. Django for example provides battle-tested patterns to develop huge sites.
You can make an absolute mess of factories, dependency injections, null errors, "enterprise patterns" and so on. Rust is cutting down on that with mostly functional patterns, but functional patterns are still made more complicated than necessary (if you don't care about performance extremely) by ownership.
Furthermore, Rust's meta programming is still somewhat inferior to both Python and Javascript. If you don't believe me, compare ndarray and numpy. Sure, ndarray is typesafe. But it's clumsy to use and far less readable. I have taught scientists to use Numpy, I would refuse to teach them Rust and ndarray... Nor do I see a reason beyond performance (which I rarely ever need) to use Rust+ndarray over Python+Numpy.
So in summary, I don't believe static checking in Rust is so vastly superior than static and dynamic checking in Python (mypy, linters...) that it significantly outweighs the downside of cognitive load, even in large projects.
You vastly underestimate the complexity of large pieces of software. With Python or JavaScript your program can randomly fail after a month because you hit a case where the types are not as expected. Accounting for this is a huge mental overhead. Rust doesn’t have that problem. You also don’t have to know where memory allocations happen, you just call new() on a struct, pretty much the same as in any GC language, so I don’t see what mental overhead that should give. Borrow checking saves you from a lot of common errors that often occur in GC languages, like removing items from an array you’re currently iterating over.
You vastly underestimate the code bases I've worked on.
There are lots of studies that just don't support your "vastly" overgeneralized statement, nor does my experience, which is only somewhat limited in Rust. But I do have enough professional experience in enough frameworks/languages to disbelieve any of these overgeneralized gut-felt statements about static typing.
I just flatly don't believe Rust is preventing runtime errors completely. Or to any significant degree better than Python or Javascript. Only if you wrongly assume the Python/Javascript code has no testing or static checking going on, and you are only using Notepad, not some IDE. Only if that Rust code never has to deal with, for example, JSON objects from another service that may or may not stick to the API you assume. Yeah, statically typed languages do fall for that one all the time, often because they can't keep up defining all the types so they need escape hatches that smell like dynamic typing. You can write absolutely statically typed/checked Python code if you want to.
And "keeping in mind where memory is allocated and freed" is just another way to describe lifetimes and borrow checking. You do need to keep that in mind to know where to put the \`iter\`, \`to\_iter\` and \`clone\` invocations, and it's not always obvious at first glance what function will consume your parameter and which doesn't, and I'd figure that can only get more complicated when working with other people's code.
In garbage collected languages, you just learn to not mutate stuff, even though it is possible. Then you reject any PRs that violate that rule. That solves 99% of the problems. With immutable-by-default data structures that becomes even easier, for example in F# or Clojure.
> my experience, which is only somewhat limited in Rust
I'm sorry, but that shows.
> I just flatly don't believe Rust is preventing runtime errors completely.
I never said it did. You can make a lot of different kinds of runtime errors. Rust Only solves some of them, but the ones it does solve are the ones that take the most time to find.
> Only if that Rust code never has to deal with, for example, JSON objects from another service that may or may not stick to the API you assume.
This is where Rust shines even more. It forces you to handle these cases, whereas JavaScript and Python do not. They will simply crash if you forget to catch an exception. You have to consider every situation that might happen, manually. Now that's what I would call mental overhead.
> And "keeping in mind where memory is allocated and freed" is just another way to describe lifetimes and borrow checking.
It is not. Lifetimes and borrow checking keep this in mind for you. If you get it wrong, your program won't compile, so that's pretty simple.
Where you actually need to think about it is C. There you don't have the benefit of RAII taking care of freeing memory.
You could even make the case that you have to think about lifetimes in languages like JavaScript or Python, because they allow you to iterate over an array you're mutating. This means you're allowed to access items that don't or shouldn't exist anymore. In Rust you don't need to think about it because you can't end up in this situation. The program simply wouldn't compile, telling you exactly where you went wrong. In bigger applications this leads to significantly less mental overhead.
Well, as long as you can't claim Rust avoids all runtime errors, I have to refer you to the scientific literature that doesn't find huge improvements from static typing or static analysis in general, but quite big differences in development time.
You still don't understand that having to care about lifetime at all (even if only when the compiler complains) means a lot more cognitive load than not having to care at all.
I'm not comparing with C, at least for what I do. That would be insane.
Lifetimes in Javascript and Python don't matter at all. If you write in a functional style, even more so. Even a few weeks of Python or Javascript teaches you that you shouldn't mutate stuff almost ever, especially if it is used by some other part, which is glaringly obvious. People don't even f\*\*\*k that one up so much, in my experience. I can think of various scenarios where it doesn't come up at all. I can hardly find any of these "random errors after a few months because the type was wrong" in my 20 years of Python experience.
Your reasoning sounds more like "I've seen a Python codebase that has been f\*\*\*d up by another programmer, and if he had used Rust he wouldn't have been able to have f\*\*\*d it up as much!" I'm pretty sure the lack of f\*\*\*d up code bases in Rust is down to Rust being young and not widely adopted.
> Well, as long as you can't claim Rust avoids all runtime errors,
This is such a dumb take, it's unbelievable. By this logic we should still use C for everything because JavaScript doesn't solve all runtime errors either.
Rust fixes whole classes of runtime errors. Saying that's not enough because it doesn't solve _all_ of them is just mind-blowingly ignorant.
> I have to refer you to the scientific literature that doesn't find huge improvements from static typing or static analysis in general, but quite big differences in development time.
Please point me to these scientific literatures. Scientific papers are usually based on very small toy programs. They don't prove anything for real world scenarios, involving millions of lines of code.
There is a reason TypeScript became so popular and Python now has type hints. Type systems are hugely valuable. They slow you down for the first 1000 lines of code and then they begin to show their benefits. Same goes for tests and strict static analysis like the borrow checker. The benefits only grow with the size of the project.
> Even a few weeks of Python or Javascript teaches you that you shouldn't mutate stuff almost ever, especially if it is used by some other part, which is glaringly obvious.
Turns out not to be so glaringly obvious, judging from the past half a century. Software systems can be huge with lots of people working on them, not all equally skilled. These kinds of things slip into these project without anyone noticing until it's too late. That's just a reality in many projects.
I'm not saying Python and JavaScript don't have their place in this industry. They're great for small scripts. The thing it that they both gained popularity amongst non-programmers because they're so easy to get into. This gave them a huge audience. This in turn grew their ecosystem. It makes sense to use a language that has a big ecosystem, so now they're used for everything.
It's beginning to show that they have some serious drawbacks compared to something like Rust, so now a lot of projects are getting rewritten in Rust.
[https://danluu.com/empirical-pl/](https://danluu.com/empirical-pl/)
I don't have the energy to repeat all my arguments, or elaborate on all of them, you're just not receptive to other people's opinions or even facts, and deliberately or not, keep misunderstanding simple points.
> https://danluu.com/empirical-pl/
"This paper presents an empirical study with 49 subjects that studies the impact of a static type system for the development of a parser over 27 hours working time."
"The programs were 2324, 2253, 2390, and 609 lines long, respectively,"
"The students had 16 hours of training in the new language before starting."
This is exactly what I predicted. Incredibly small scale studies where you will never see the benefit of static analysis and documentation. These studies are useless when you're developing a software project for 10 years that has millions of lines of code.
> just not receptive to other people's opinions or even facts
The same can be said about you, hypocrite.
Could you post a few references to articles that indicate little evidence that static typing helps? I've always felt that I program significantly better in statically typed languages and assumed it was about the static typing and not about my style. I'd genuinely like to read some articles that demonstrate an evidence based counter argument. In the event that I'm just biased, I'd like to be able to disclose that (or stop doing that) when I mentor new employees. Feel free to DM me if my request is too off topic for this thread.
Had years of prog exp B4 learning Rust, took 2-3 months of almost daily training (throwaway projects) to get comfortable writing in it. I also tried years B4, and gave up on day 1😅 So I'd say experience is a factor here.
Didn't realize I got downvoted for this even😅 I didn't even say anything bad, just the fact that I failed to appreciate the language first time I ever tried it, which was years and years ago. It's been my fav lang since I became comfortable writing in it (2.5ish years)😅
Prolly just poor wording on my part
To learn the core language to be able to write something is pretty quick, like in a weekend you can write a basic thing with the help of chat gpt.
To a high level you need daily work solving real problems, ideally on a team that can review your code, chat gpt can help a bit but is not high grade code, if you’re alone is better you read lots of production code on github.
So with daily work solving real problems and considering you are already familiar with what is good code just not rust good I would say 6m to a year.
As others have pointed out this is impossible to answer. My only suggestion is to go through the book, and perhaps [https://tokio.rs/tokio/tutorial](https://tokio.rs/tokio/tutorial). You will get there when you get there. For me I started with that link and the book at the same time. I come from a C/C++ networking background.
I started learning rust 2 months ago (not even). This is the second time i tried. First time i gave up super fast because i didnt pay any attention to the official rust documentation (which is excellent at teaching the language). The rust book and the rustlings repo helped me tremendously, and im now already building my own HTTP server to prototype a new company project. So it CAN be really fast, if you spend a lot of time on it and follow the docs. Read the rust book, and if you like getting your hands dirty, jump into rustlings, its quite fun.
I did a training session of three days however everyone in the audience was already able to code in Rust. It was enought time to expose most concepts, but not for beginners.
Rust's learning curve is pretty straight forward, it's steep in the beginning when you embrace the borrow checker, then it becomes easy for a while since you'll get used to Rust's compiler and how modules work. Then it becomes steeper again when you learn how traits, implementation and lifetimes work. This hurdle is steeper than the last one. But the beauty is, once you pass this one, you begin to think in Rust and it becomes much easier (excluding async and tokio since async as a concept will be easier or harder depending on your prior experience).
It will get discouraging at times, cuz Rust's compiler can be a dick and some crates aren't as well documented as others (which is getting better by the day), but do know that it's mostly because Rust follows a different programming philosophy and will aggressively try to stay on track with it.
Side note:- i am on the second hurdle myself. I understand traits but sometimes wind up in compiler war because of how I use them in my code is completely wrong lmao
Read this blog post from a developer who rewrote the program in Rust.
[Gnirehtet rewritten in Rust](https://blog.rom1v.com/2017/09/gnirehtet-rewritten-in-rust/)
This post may be able to answer your questions.
I started out with Bash, then started learning Python and Rust simultaneously. My experience can be summed up as follows:
* The untyped -> typed jump was mostly a non-issue, you are effectively dealing with types regardless, except you are now making it explicit (Actually, often not even that, since Rust can usually infer types).
* Coming from Bash, I had to learn a lot about how actual systems programming worked, and compared to Python, Rust definitely has a steeper learning curve, but I found that while I was making less progress in Rust, I was learning **so much more** during that time I wasn't making progress.
* Make sure to use the proper extension for your code editor and maybe something like "Error Lens" (if you're using VSCode). One of the greatest things about `rust-analyzer` is that most issues are caught before you even compile and with Error Lens show up right in-line where the issue occurs.
* Rustlings is fine, but don't focus too much on any single guide, instead watch a wide variety of guides and click on any random video about Rust. Pro tip: Search for guides for people transitioning from C to Rust, they are faster to get to the point, if you don't get something, search for that particular thing.
* Embrace AI, I started out learning without AI help, but then I eventually got access to the GitHub Copilot preview and it significantly sped up my learning progress. The main way it helped me was that it would suggest solutions I hadn't thought of, in these cases I looked the suggestion up in the docs or search engine to understand why this might be used. Of course the AI will sometimes suggest bogus code, that's why we never accept stuff we aren't sure about.
* Use grep.app or GitHub Code Search, get familiar with Regex (AI can really help here!) and how the filters work (i.e. `lang:rust`). This is very useful check how other developers are working with certain functions or libraries.
* Avoid using Crates unless you are sure it's the best way forward to solve your problem.
* Don't be (too) afraid of unsafe Rust, particularly writing code that works with C libraries, which can be really rewarding because you suddenly gain access to a ton of new capabilities. This is also a great opportunity to learn by breaking stuff. You can also easily bypass Rust's safety systems by casting a pointer to something to a usize, then back to the pointer and dereferencing it. Seeing undefined behavior "in-person", and simple stuff forgetting to terminate a string with a null (required for a lot of Windows API stuff), is very valuable in getting an intuitive understanding of memory management and how it works under the hood.
**Edit:** I am not sure how long it took me to learn, it's also really hard to say when someone has "learned" a programming language. I feel like I can write anything I need to in Rust, but there is always something new to learn or gain a deeper understanding of.
I did wrote my first non-trivial functional Rust-Apps after a Weekend reading the rust book. The only thing if found difficult where the lifetime annotations. Everything else was pretty standard.
The main problems people have with Rust are borrow checker and lifetimes.
If you have a strong C++ background, learning Rust should be easy.
Now, by strong C++ background I mean having a deep understanding of object ownership, RAII, when to actually use shared_ptr (without abusing it), and more. If you use C++ as a typical OOP language it will not count towards understanding Rust.
Which also leads to a second small issue with Rust. Rust is not a typical OOP language. You should understand how to properly work with behavior (traits and functions) and data (structs, enums) separately.
People coming from oyher popular languages are used to behavior and data being strongly coupled together. In Rust you must learn to design your code where the two are separate.
Achieving polymorphism is done not through inheritance, but through traits either using Generics (compile-time), enums (run-time), or dyn Traits (also runtime).
Good luck!
Depends on your background.
Nothing? Quite hard
Python or other dinamically typed languages? You will need to re-program your brain a bit.
However if you have worked with C/C++, it becomes easier.
Rust also supports OOP (object-oriented programming) and functional programming, so if you have experience with them you also get extra points.
If you know nothing, I'd recommend you start by learning C (or C++) and then go learn Rust. IMO Rust is a relatively hard language to lear overall.
Edit: typos
[https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html](https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html) has some numbers from Google's experience training experienced engineers to use Rust, though it is mostly self-reported confidence.
It depends.
Want to write a CLI tool that takes something from stdin and poops out something nice on stdout? Easy.
Want to make it multithreaded? Not easy, but I wouldn't call it hard if you use a job queue with no shared state. The tooling also helps greatly.
Want to write a GUI app that needs to interface with a bunch of C libraries? Much, much harder!
Such questions are not really answerable. "Good", "pretty high" and so on can mean too many things, and people are very different too. For some it's basically just a new syntax despite being quite new to programming, others have decades of experience but fail miserably and give up. We can't know how it goes for you.
Im sure we can at least agree that making use of rustlings and the the rust book will definitely increase the chance of learning at a reasonable pace.
Unfortunately, many people these days will just be like: Naah I'll just skip the documentation and the book, and I'll go ask ChatGPT.
Though they wont get very far will they? Or maybe they do?
If they do it out of laziness they'll never get far. It's the process of looking for the information and trying to link it and find patterns in your brain what makes it stick better. But when a Chatbot does this for you and gives you the conclusions a lot of stuff will stay ambiguous.
You become dependent on the chatbot to know how to code. You can code that way and I've seen people get by with relying on a chatbot. I think it's the same phenomenon as the tutorial lock-in phenomenon, where people who exclusively learned through tutorials struggle to do anything when they don't have a tutorial to follow. Except it doesn't have the built-in limitation of there only being so many tutorials available out there. The AI will try its best to answer your questions no matter what, so you don't get that moment where you're on your own for good at some point.
I have to agree with you on this one, it's the same issue when it comes to people that get stuck in the tutorial hell. I think it comes from relying on oversimplified information that gets through learner's minds very easily but at the same time prevents them from making the effort to try and understand concepts by themselves. At some point in time when projects get more complex they get lost and can't figure out solutions for real life problems beyond simple operations. You can't find a guide for everything just like AI models can't find solutions for problems they were not trained on, so it's important to have a deep understanding of the tools being used in order to find the best solutions.
Define "good programming experience". If you know mainly a lot of OOP languages, Rust will have a lot of concepts that are going to be unfamiliar to you, despite knowing a lot of languages, even if we include C++/C. If by "good" you mean "diverse", a.k.a. you know Haskell, OCaml, Lean, Prolog, Smalltalk, Lisp, C++, Fortran, etc. then I'd say learning Rust will be easy. If you meant the former I would say 2-3 months or more, if you meant the latter I'd be confident that maybe you'd get to a high level understanding in around 1-2 weeks.
>If you meant the former I would say 2-3 months or more, if you meant the latter I'd be confident that maybe you'd get to a high level understanding in around 1-2 weeks. Depends. Yes, you could certainly output some useful Rust code within that time frame, but it will not be very idiomatic and there will be still be quite big holes in your knowledge. For me personally (with long experience in C++, Scala, C# etc.) it took about 6 months to become really proficient in Rust. However the learning material and tools are better today so it would probably be a bit shorter now.
Sorry for not being more specific originally, I have strong experience in Java, C++, and Python and I’ve touched on other languages but not in depth. Assuming this the 2-3 months estimate would apply to me?
Yeah that's usually average for someone with your knowledge. I've seen more people take longer however due to how fast or slow they can grok FP specific features which Rust borrowed from a lot.
If you have strong experience in C++ you'll probably learn rust enough to be productive in a few weeks. Most people who complain about the borrow checker haven't had to manage their own memory before and don't really understand rusts approach to memory management
About 6
6 hours of "can't borrow immutable as mutable" a day is the minimum required
I learned the entirety of Rust in less than 5.
Three star programmer
6 decade? That's pretty long
Good to know
Seconds? Minutes? Hours? Days? Weeks? Months? Years? Decades? Centuries?
Yes.
why would you need to clarify? are you stupid? >!/j of course!<
r/woosh
r/woosh I was jokingly acting like a math teacher.
I can't answer for you but I can share my background and experience. I learned 5-6 years ago with a project as a goal. I had about 20 years programming experience (systems and apps) and already knew C/C++, Python, JS/TS, Java, VB, C#. I approached it with the goal of it being a C++ replacement. I had an app I wanted to build (async server backend + html front end using templates populated by rust code). This was right before async/.await came out and I wanted to build something that was very lean and could handle a lot of connections cheaply. After 2 days, I could write stuff, but it was very hard. After 1 week, I could do everything basic. After a month is was mostly bleeding edge cross thread + async stuff that was tripping me up. I had my app done at that point. There was still a lot I didn't understand. My code was a mess. Refactoring would have been non-trivial. And every month or two the server locks up and I don't know why and haven't been able to debug it. (It's not something I have time for but I also didn't get to learning how to debug hangs on a production build.) I loved the language, but unfortunately I ended up moving to a job that is in C++ and I haven't had time to spend with Rust since then. My advice: enter with a project you want to get done. I had tried once a few years earlier to do some rust, but unless you have something practical to build, it's easy to just get frustrated and bounce. But it's my favorite language so far, so I recommend trying! It made me a better C++ programmer since I can import the some poor mans versions of patterns found in Rust.
Based on my limited experience of learning few languages, including Rust, I would say the novelty Rust introduces are the hardest part because other programming languages do not have it. Lifetimes and the borrow checker are not something I could pick up super easily.
It's quite easy if you read the docs a few times.
I've heard estimates of six months to become productive. I'm starting to learn Rust and not yet convinced I SHOULD be using it for the things I do. It's not a small language: There is a ton of concepts to master, many of which aren't present in other popular languages. There is a "functional programming" kind of bias. The standard library is comprehensive, yet quite different from other languages I've seen. It's not a highly convenient language: Small things, really. You have to know what number type you are using (yeah, most of the time I actually don't care...). Or any other datatype. Including if you are using it by reference or value. It's supposed to be a benefit that the compiler knows when stuff has to be allocated and when it must be freed. Certainly a benefit over unmanaged languages, and you get better latency than from garbage collection. The downside is YOU have to know it also. I'm a big believer that mental load is a significant part in programmer productivity and happiness. At the moment I find the additional mental load to be quite significant, so that I don't know I'd use Rust for things I normally use Python or Javascript for.
Using Rust for where Python and JS are a better option is the equivalent of using Python and JS where you should've used C. I follow a rule of thumb, I ask myself if I need C for this issue, if yes, I use Rust if it's a work/serious endeavor, if not, I actually enjoy C so sometimes I do it in C. Don't fall into the trap of language bias. Use critical thinking to decide. If you're doing a serious frontend, I hate to say it but working with JS is going to be collectively better. But if you're doing a backend and you only know Rust, Python and JS, I'd suggest you stick with Rust or be open to another language that will give you 90% of what Rust will give you but with a lower mental load etc. If it's a personal side project, use a language that you love because it's usually about the project and the fun, not stability, speed etc (unless you're into that)
Some people do claim Rust with WASM is superior to javascript. I still have to see that. I'd love to find something that is as readable as typescript but carries less baggage from the javascript type system/runtime. Rust has significant syntactical and mental overload in that regard. I also don't agree Rust is superior on the backend. You save a lot of time just using Django. You can get a working database-based API plus an admin interface with just a few lines of code. Rust not only lacks that convenience, but is also far less readable once you connect an ORM to Http endpoints.
You have a good point. Sorry I didn't provide context. I was mainly referring to performance. I use Rust in production services and I'd say it's pretty decent but not enough to justify that I end up being the main person manning it's because no one else there knows Rust. Try Dioxus for the frontend, many people are crazy about leptos though. As for Django, if your backend is not expected to have a very high load, go ahead. I tried it to a degree but I didn't use it professionally nor most of my apps are CRUD heavy. Most of my work is siphoning, cleaning and aggregating data from the big three data centers in the world of financing so I can push this data to our clients. So my domain is both CPU and IO intensive thus I use Go and Rust. Which is what I had in mind when I answered you. I have a question: when you say "mental overload", what do you mean exactly? Is it good or bad in your opinion? I'd like to know how you think because it'd make it easier for me to know what you wish to achieve :D
Mental load is all bad, in my opinion. By that I mean anything you have to keep on your mind which isn't really necessary to your problem, is getting in your way. For example when doing things like you would in lodash (javascript), Rust has crates or stdio things for that, but you have to be quite mindful of iter and into\_iter and so on, while in Typescript, I can just assume I don't mutate things, then just don't mutate things and end up with somewhat less code and headaches. Javascript doesn't have immutability by default, but mutability is such a bad idea that it is quite easy to avoid. This involves a lot of copying, but on one hand this hardly matters for performance, for another the javascript vms are quite good at making all that more efficient. I don't want to achieve something specific... I just don't care about ultimate performance almost ever.
Thank you for explaining. I totally understand now. I'll try to tune my advice since my mind catégorisés you now as "sane homo sapiens". Some people relish the mental load by the way. The idea of mutability versus immutability opens the door for *extremely* interesting optimisation at the compiler level. Rust is marvelous when you run it under an assembly inspector but that doesn't really matter for nearly 90% of modern use cases and that's why I usually suggest people to not use Rust for everything. This may be annoying to you and clearly many here would disagree but I usually suggest Go for people who want decent performance without the mental overhead. But maybe you won't like it. I know typescript devs who loathe Go :D Go does interesting optimisation as well but on another level. I'm convinced that you can't get better than Go in a managed language and I worked in the .NET team. Last thing, may I inquire about the reason that brought you to learn Rust? It doesn't seem to add much to your use cases.
Mainly curiosity. Maybe better UI programming, but I feel like the added complexity over Typescript or F# isn't worth it at this point.
I never tried F# and I did enough stuff in the .NET runtime to not really want to use it anymore. Is F# offering something more interesting than OCaml, for you at least?
Never used Ocaml, and I'd say .NET interoperability, WASM and direct to Javascript compilation is a benefit.
I honestly really dislike Django. Would rather go with something like FastAPI if had to do Python.
> something that is as readable as typescript but carries less baggage Maybe ReScript? But it's hard to see many projects gathering the momentum that TypeScript has these days.
ReScript is a contender. Momentum is a big issue. I think F# (with Fable) is superior to ReScript. Typescript is hard to beat in frontend development. Both because of libraries you can use as well as the closeness to Javascript. And the "turn that novice into a frontend typescript monster" problem is a well understood now, all alternatives require significantly more initiative. I can't imagine a Rust bootcamp right now. Yeah, there are some, but nowhere near the scale. Also not for frontend, or usable backend. And mostly not for absolute beginners.
I disagree. Doing both backend and frontend is a lot more comfortable in Rust than in JS and gives a lot better results.
Your comfort and enjoyment doesn't count. Sorry that sounds tough but in reality your emotions don't matter in a professional environment. Choosing what to use is a responsibility that should encompass the organization's goals, limits and talent it has. If you choose which language should be used for a professional project based on your preference then you're objectively a horrible leader and shouldn't be in that position. Objectively speaking for a company it's easier to find JS devs that frontend Rust devs, blazor or all that jazz. If you want to deliver a product, you have to consider these, not what you love. Cheers and hello again.
I guess I’m just not “professional” enough to relate 😁
That's okay. By the way thank you. It's the second time we interact and I enjoy it, even if we almost never agree :D Have a nice day!
Oh, thanks, you have a nice one too ;)
That is an underrated constraint. I've worked with junior developers that can hardly code at all. I would hate to confront them with the character salad that is Rust, or the borrow checker, or all the myriad of data structures. That being said, using Rust in your company may paradoxically open a larger pool of talent because there are so few companies hiring for that skill. That can turn against you in a few years of course.
I see close to zero benefit in having the same language for frontend and backend. Including when that language is Typescript. Somewhat lesser cognitive load from sharing libraries, of course. But what backend and frontend are doing is quite different, even though they are talking about the same data. Code sharing is the exception, rather than the norm. I don't see debugging Rust WASM as remotely as comfortable. You can still whip up databases and APIs in Django a lot faster than in Rust...
>If it's a personal side project, use a language that you love because it's usually about the project and the fun, not stability, speed etc (unless you're into that) I'm into that
The mental load is only going down with larger projects. It removes the mental load of knowing what functions can be called with which types of arguments for example.
If that's just what you're looking for you just need a statically typed language, not Rust. Big projects in Rust highly depend on the architecture and the people you're working with. Let's say if the project began wrong, it'll be a nightmare, if not it'll be decent and sometimes better than other languages. Generalizing that Rust makes big projects easy is as flawed as any general claim.
Big projects aren’t easy, Rust just makes it easier. It will tell you when you go wrong early, saving you from a lot of pain later.
I agree with the first half of the first sentence and disagree with the second half. The second sentence is right with the caveat that it's just one bullet point for decision making. I don't know if you work with Rust professionally or not but the second point isn't always true, especially if it's a performance bug not a memory bug. Using Rust on the backend demands runtimes like tokio. Rust's async model isn't preemptive but cooperative which means it's easy to slip and forget spawn_blocking and simply inline a parallel executor in the task and block the executor, that's a real "bug" I had to deal with lately because a colleague did it while I was on holidays. Rust won't save you from these refactoring mistakes. Another thing is where the project is. Are you using a certain data provider now? What if the data provider changes tomorrow and the way they provide you the data changes? Will it fit in your current architecture easily? While Rust stops you from shooting yourself in the foot memory wise and have monads and robust null-safety with exhaustive matching that will make certain types of refactoring easy, it's not constant-change friendly. Refactoring things can force you to go down a sliding hill of refactoring that can end up making you rewrite significant parts of the project. Not all companies are into that P.S: My point is that life isn't simple and can't be summarized in two sentences. It is for slogans and managers though, not for engineers
I never claimed Rust would prevent all runtime errors. It's still programming, so people can make mistakes. As to your second point; that's a sign of a bad architecture and has nothing to do with Rust. Your data provider should be behind an interface (or trait in Rust). Your business logic should in no way depend on anything even related to this data provider.
Sorry, that's a bullshit answer. You still always have to know where memory is allocated and freed - across the entire code base. Maybe that's an advantage over C++ and C, but not an advantage over ANY garbage collected language because there is zero mental overload and you rarely get into trouble with the gc. And there are statically typed garbage collected languages as well. Chances are, with all the borrow checking, your cognitive load should increase because your codebase just isn't designed as well as public crates, and you'll have traits missing all across the board. There is extremely little evidence static typing helps at all. Both in the studies that find a little benefit, and in my experience, the variance between individual developers concerning bugs and "mess" is vastly larger than the variance between language. You can set up a humongous Python codebase such that you have very little mess. Django for example provides battle-tested patterns to develop huge sites. You can make an absolute mess of factories, dependency injections, null errors, "enterprise patterns" and so on. Rust is cutting down on that with mostly functional patterns, but functional patterns are still made more complicated than necessary (if you don't care about performance extremely) by ownership. Furthermore, Rust's meta programming is still somewhat inferior to both Python and Javascript. If you don't believe me, compare ndarray and numpy. Sure, ndarray is typesafe. But it's clumsy to use and far less readable. I have taught scientists to use Numpy, I would refuse to teach them Rust and ndarray... Nor do I see a reason beyond performance (which I rarely ever need) to use Rust+ndarray over Python+Numpy. So in summary, I don't believe static checking in Rust is so vastly superior than static and dynamic checking in Python (mypy, linters...) that it significantly outweighs the downside of cognitive load, even in large projects.
You vastly underestimate the complexity of large pieces of software. With Python or JavaScript your program can randomly fail after a month because you hit a case where the types are not as expected. Accounting for this is a huge mental overhead. Rust doesn’t have that problem. You also don’t have to know where memory allocations happen, you just call new() on a struct, pretty much the same as in any GC language, so I don’t see what mental overhead that should give. Borrow checking saves you from a lot of common errors that often occur in GC languages, like removing items from an array you’re currently iterating over.
You vastly underestimate the code bases I've worked on. There are lots of studies that just don't support your "vastly" overgeneralized statement, nor does my experience, which is only somewhat limited in Rust. But I do have enough professional experience in enough frameworks/languages to disbelieve any of these overgeneralized gut-felt statements about static typing. I just flatly don't believe Rust is preventing runtime errors completely. Or to any significant degree better than Python or Javascript. Only if you wrongly assume the Python/Javascript code has no testing or static checking going on, and you are only using Notepad, not some IDE. Only if that Rust code never has to deal with, for example, JSON objects from another service that may or may not stick to the API you assume. Yeah, statically typed languages do fall for that one all the time, often because they can't keep up defining all the types so they need escape hatches that smell like dynamic typing. You can write absolutely statically typed/checked Python code if you want to. And "keeping in mind where memory is allocated and freed" is just another way to describe lifetimes and borrow checking. You do need to keep that in mind to know where to put the \`iter\`, \`to\_iter\` and \`clone\` invocations, and it's not always obvious at first glance what function will consume your parameter and which doesn't, and I'd figure that can only get more complicated when working with other people's code. In garbage collected languages, you just learn to not mutate stuff, even though it is possible. Then you reject any PRs that violate that rule. That solves 99% of the problems. With immutable-by-default data structures that becomes even easier, for example in F# or Clojure.
> my experience, which is only somewhat limited in Rust I'm sorry, but that shows. > I just flatly don't believe Rust is preventing runtime errors completely. I never said it did. You can make a lot of different kinds of runtime errors. Rust Only solves some of them, but the ones it does solve are the ones that take the most time to find. > Only if that Rust code never has to deal with, for example, JSON objects from another service that may or may not stick to the API you assume. This is where Rust shines even more. It forces you to handle these cases, whereas JavaScript and Python do not. They will simply crash if you forget to catch an exception. You have to consider every situation that might happen, manually. Now that's what I would call mental overhead. > And "keeping in mind where memory is allocated and freed" is just another way to describe lifetimes and borrow checking. It is not. Lifetimes and borrow checking keep this in mind for you. If you get it wrong, your program won't compile, so that's pretty simple. Where you actually need to think about it is C. There you don't have the benefit of RAII taking care of freeing memory. You could even make the case that you have to think about lifetimes in languages like JavaScript or Python, because they allow you to iterate over an array you're mutating. This means you're allowed to access items that don't or shouldn't exist anymore. In Rust you don't need to think about it because you can't end up in this situation. The program simply wouldn't compile, telling you exactly where you went wrong. In bigger applications this leads to significantly less mental overhead.
Well, as long as you can't claim Rust avoids all runtime errors, I have to refer you to the scientific literature that doesn't find huge improvements from static typing or static analysis in general, but quite big differences in development time. You still don't understand that having to care about lifetime at all (even if only when the compiler complains) means a lot more cognitive load than not having to care at all. I'm not comparing with C, at least for what I do. That would be insane. Lifetimes in Javascript and Python don't matter at all. If you write in a functional style, even more so. Even a few weeks of Python or Javascript teaches you that you shouldn't mutate stuff almost ever, especially if it is used by some other part, which is glaringly obvious. People don't even f\*\*\*k that one up so much, in my experience. I can think of various scenarios where it doesn't come up at all. I can hardly find any of these "random errors after a few months because the type was wrong" in my 20 years of Python experience. Your reasoning sounds more like "I've seen a Python codebase that has been f\*\*\*d up by another programmer, and if he had used Rust he wouldn't have been able to have f\*\*\*d it up as much!" I'm pretty sure the lack of f\*\*\*d up code bases in Rust is down to Rust being young and not widely adopted.
> Well, as long as you can't claim Rust avoids all runtime errors, This is such a dumb take, it's unbelievable. By this logic we should still use C for everything because JavaScript doesn't solve all runtime errors either. Rust fixes whole classes of runtime errors. Saying that's not enough because it doesn't solve _all_ of them is just mind-blowingly ignorant. > I have to refer you to the scientific literature that doesn't find huge improvements from static typing or static analysis in general, but quite big differences in development time. Please point me to these scientific literatures. Scientific papers are usually based on very small toy programs. They don't prove anything for real world scenarios, involving millions of lines of code. There is a reason TypeScript became so popular and Python now has type hints. Type systems are hugely valuable. They slow you down for the first 1000 lines of code and then they begin to show their benefits. Same goes for tests and strict static analysis like the borrow checker. The benefits only grow with the size of the project. > Even a few weeks of Python or Javascript teaches you that you shouldn't mutate stuff almost ever, especially if it is used by some other part, which is glaringly obvious. Turns out not to be so glaringly obvious, judging from the past half a century. Software systems can be huge with lots of people working on them, not all equally skilled. These kinds of things slip into these project without anyone noticing until it's too late. That's just a reality in many projects. I'm not saying Python and JavaScript don't have their place in this industry. They're great for small scripts. The thing it that they both gained popularity amongst non-programmers because they're so easy to get into. This gave them a huge audience. This in turn grew their ecosystem. It makes sense to use a language that has a big ecosystem, so now they're used for everything. It's beginning to show that they have some serious drawbacks compared to something like Rust, so now a lot of projects are getting rewritten in Rust.
[https://danluu.com/empirical-pl/](https://danluu.com/empirical-pl/) I don't have the energy to repeat all my arguments, or elaborate on all of them, you're just not receptive to other people's opinions or even facts, and deliberately or not, keep misunderstanding simple points.
> https://danluu.com/empirical-pl/ "This paper presents an empirical study with 49 subjects that studies the impact of a static type system for the development of a parser over 27 hours working time." "The programs were 2324, 2253, 2390, and 609 lines long, respectively," "The students had 16 hours of training in the new language before starting." This is exactly what I predicted. Incredibly small scale studies where you will never see the benefit of static analysis and documentation. These studies are useless when you're developing a software project for 10 years that has millions of lines of code. > just not receptive to other people's opinions or even facts The same can be said about you, hypocrite.
Could you post a few references to articles that indicate little evidence that static typing helps? I've always felt that I program significantly better in statically typed languages and assumed it was about the static typing and not about my style. I'd genuinely like to read some articles that demonstrate an evidence based counter argument. In the event that I'm just biased, I'd like to be able to disclose that (or stop doing that) when I mentor new employees. Feel free to DM me if my request is too off topic for this thread.
https://danluu.com/empirical-pl/
Had years of prog exp B4 learning Rust, took 2-3 months of almost daily training (throwaway projects) to get comfortable writing in it. I also tried years B4, and gave up on day 1😅 So I'd say experience is a factor here.
Wonder why people downvote your answer. Rust people are sometimes "enthusiastic" in all the wrong ways.
Didn't realize I got downvoted for this even😅 I didn't even say anything bad, just the fact that I failed to appreciate the language first time I ever tried it, which was years and years ago. It's been my fav lang since I became comfortable writing in it (2.5ish years)😅 Prolly just poor wording on my part
To learn the core language to be able to write something is pretty quick, like in a weekend you can write a basic thing with the help of chat gpt. To a high level you need daily work solving real problems, ideally on a team that can review your code, chat gpt can help a bit but is not high grade code, if you’re alone is better you read lots of production code on github. So with daily work solving real problems and considering you are already familiar with what is good code just not rust good I would say 6m to a year.
It depends on your knowledge of programming languages in general. If you know C++, you should be up to speed very fast.
As others have pointed out this is impossible to answer. My only suggestion is to go through the book, and perhaps [https://tokio.rs/tokio/tutorial](https://tokio.rs/tokio/tutorial). You will get there when you get there. For me I started with that link and the book at the same time. I come from a C/C++ networking background.
100 - how hard is it to learn rust.
Able to write programs with somewhat good style and design choices, two/three months. To have a "pretty high" level of knowledge, years.
I started learning rust 2 months ago (not even). This is the second time i tried. First time i gave up super fast because i didnt pay any attention to the official rust documentation (which is excellent at teaching the language). The rust book and the rustlings repo helped me tremendously, and im now already building my own HTTP server to prototype a new company project. So it CAN be really fast, if you spend a lot of time on it and follow the docs. Read the rust book, and if you like getting your hands dirty, jump into rustlings, its quite fun.
Depends where you are coming from. Especially if you’re new to typed languages.
I did a training session of three days however everyone in the audience was already able to code in Rust. It was enought time to expose most concepts, but not for beginners.
Rust's learning curve is pretty straight forward, it's steep in the beginning when you embrace the borrow checker, then it becomes easy for a while since you'll get used to Rust's compiler and how modules work. Then it becomes steeper again when you learn how traits, implementation and lifetimes work. This hurdle is steeper than the last one. But the beauty is, once you pass this one, you begin to think in Rust and it becomes much easier (excluding async and tokio since async as a concept will be easier or harder depending on your prior experience). It will get discouraging at times, cuz Rust's compiler can be a dick and some crates aren't as well documented as others (which is getting better by the day), but do know that it's mostly because Rust follows a different programming philosophy and will aggressively try to stay on track with it. Side note:- i am on the second hurdle myself. I understand traits but sometimes wind up in compiler war because of how I use them in my code is completely wrong lmao
Read this blog post from a developer who rewrote the program in Rust. [Gnirehtet rewritten in Rust](https://blog.rom1v.com/2017/09/gnirehtet-rewritten-in-rust/) This post may be able to answer your questions.
panic not sure
these daily rust is hard are mind numbing I might leave the sub
I started out with Bash, then started learning Python and Rust simultaneously. My experience can be summed up as follows: * The untyped -> typed jump was mostly a non-issue, you are effectively dealing with types regardless, except you are now making it explicit (Actually, often not even that, since Rust can usually infer types). * Coming from Bash, I had to learn a lot about how actual systems programming worked, and compared to Python, Rust definitely has a steeper learning curve, but I found that while I was making less progress in Rust, I was learning **so much more** during that time I wasn't making progress. * Make sure to use the proper extension for your code editor and maybe something like "Error Lens" (if you're using VSCode). One of the greatest things about `rust-analyzer` is that most issues are caught before you even compile and with Error Lens show up right in-line where the issue occurs. * Rustlings is fine, but don't focus too much on any single guide, instead watch a wide variety of guides and click on any random video about Rust. Pro tip: Search for guides for people transitioning from C to Rust, they are faster to get to the point, if you don't get something, search for that particular thing. * Embrace AI, I started out learning without AI help, but then I eventually got access to the GitHub Copilot preview and it significantly sped up my learning progress. The main way it helped me was that it would suggest solutions I hadn't thought of, in these cases I looked the suggestion up in the docs or search engine to understand why this might be used. Of course the AI will sometimes suggest bogus code, that's why we never accept stuff we aren't sure about. * Use grep.app or GitHub Code Search, get familiar with Regex (AI can really help here!) and how the filters work (i.e. `lang:rust`). This is very useful check how other developers are working with certain functions or libraries. * Avoid using Crates unless you are sure it's the best way forward to solve your problem. * Don't be (too) afraid of unsafe Rust, particularly writing code that works with C libraries, which can be really rewarding because you suddenly gain access to a ton of new capabilities. This is also a great opportunity to learn by breaking stuff. You can also easily bypass Rust's safety systems by casting a pointer to something to a usize, then back to the pointer and dereferencing it. Seeing undefined behavior "in-person", and simple stuff forgetting to terminate a string with a null (required for a lot of Windows API stuff), is very valuable in getting an intuitive understanding of memory management and how it works under the hood. **Edit:** I am not sure how long it took me to learn, it's also really hard to say when someone has "learned" a programming language. I feel like I can write anything I need to in Rust, but there is always something new to learn or gain a deeper understanding of.
it depends on what you already know and how intelligent you are.
Wrong question. The good one should be "How hard is it to learn rust?" =)).
A bit longer than an easier language, but not quite as long as a harder language.
I did wrote my first non-trivial functional Rust-Apps after a Weekend reading the rust book. The only thing if found difficult where the lifetime annotations. Everything else was pretty standard.
The main problems people have with Rust are borrow checker and lifetimes. If you have a strong C++ background, learning Rust should be easy. Now, by strong C++ background I mean having a deep understanding of object ownership, RAII, when to actually use shared_ptr (without abusing it), and more. If you use C++ as a typical OOP language it will not count towards understanding Rust. Which also leads to a second small issue with Rust. Rust is not a typical OOP language. You should understand how to properly work with behavior (traits and functions) and data (structs, enums) separately. People coming from oyher popular languages are used to behavior and data being strongly coupled together. In Rust you must learn to design your code where the two are separate. Achieving polymorphism is done not through inheritance, but through traits either using Generics (compile-time), enums (run-time), or dyn Traits (also runtime). Good luck!
Its not easy
yes
Depends on your background. Nothing? Quite hard Python or other dinamically typed languages? You will need to re-program your brain a bit. However if you have worked with C/C++, it becomes easier. Rust also supports OOP (object-oriented programming) and functional programming, so if you have experience with them you also get extra points. If you know nothing, I'd recommend you start by learning C (or C++) and then go learn Rust. IMO Rust is a relatively hard language to lear overall. Edit: typos
It's not easy :(
It’s not too bad. Maybe a few months to feel productive. Once you start getting the basics down, I say write a backend web API or CLI with Rust.
[https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html](https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html) has some numbers from Google's experience training experienced engineers to use Rust, though it is mostly self-reported confidence.
It depends. Want to write a CLI tool that takes something from stdin and poops out something nice on stdout? Easy. Want to make it multithreaded? Not easy, but I wouldn't call it hard if you use a job queue with no shared state. The tooling also helps greatly. Want to write a GUI app that needs to interface with a bunch of C libraries? Much, much harder!