Ask HN: Should I learn Rust or Go?
126 comments
If your goal is to be a better coder long term, I’d suggest learning both. As many have pointed out, Go is quick to learn, and I think learning both will only take a small amount of extra time (compared to learning Rust).
They each present trade offs that make them a better tool under particular circumstances. While Rust exposes you to more sophisticated typesystem features, Go's M:N scheduler is an incredible piece of technology that is (IMO) unmatched by any other mainstream language.
Finally, regarding the garbage collector, if you learn both languages, you'll get to viscerally experience the tradeoffs of having the garbage collector (try writing the same program in each language). There are some projects where it makes sense to use one and others where you shouldn't. Trying out both is the best way to build up intuition for this kind of trade off.
They each present trade offs that make them a better tool under particular circumstances. While Rust exposes you to more sophisticated typesystem features, Go's M:N scheduler is an incredible piece of technology that is (IMO) unmatched by any other mainstream language.
Finally, regarding the garbage collector, if you learn both languages, you'll get to viscerally experience the tradeoffs of having the garbage collector (try writing the same program in each language). There are some projects where it makes sense to use one and others where you shouldn't. Trying out both is the best way to build up intuition for this kind of trade off.
> Go's M:N scheduler is an incredible piece of technology that is (IMO) unmatched by any other mainstream language.
Java’s Loom will change the picture big time, and it is already available in preview mode! But otherwise I agree.
Java’s Loom will change the picture big time, and it is already available in preview mode! But otherwise I agree.
> Go's M:N scheduler is an incredible piece of technology that is (IMO) unmatched by any other mainstream language.
I guess it depends how you define mainstream, but in Rust, Rayon has a work stealing scheduler too.
On the other hand, it has existed in Erlang for decades, and Elixir takes full advantage of it.
As for my 2c, I would say Rust is a better choice than Go in terms of the first language to learn. The main reason for this, is it is easy to embed in other languages. When I get to a problem that is too slow in a higher level language, eg. Python or Elixir, Rust is a great way to solve this problem. Just have a look at polars (https://www.pola.rs/).
I guess it depends how you define mainstream, but in Rust, Rayon has a work stealing scheduler too.
On the other hand, it has existed in Erlang for decades, and Elixir takes full advantage of it.
As for my 2c, I would say Rust is a better choice than Go in terms of the first language to learn. The main reason for this, is it is easy to embed in other languages. When I get to a problem that is too slow in a higher level language, eg. Python or Elixir, Rust is a great way to solve this problem. Just have a look at polars (https://www.pola.rs/).
Afaik Go's scheduler is not unique. What does it do better then Haskell or Elixir?
It allows you to create many more language threads (go routines) than kernel threads, and unlike other languages properly hides this abstraction from you with a rope stack (so you don't need to create coroutines or use async/await syntax).
I'm not up to speed with the latest and greatest in Haskell or Elixir, so they very well may have something similar. Rust has great runtimes, like tokio, that do similar things, but without rope stacks and with painful async/await syntax.
I'm not up to speed with the latest and greatest in Haskell or Elixir, so they very well may have something similar. Rust has great runtimes, like tokio, that do similar things, but without rope stacks and with painful async/await syntax.
A M:N Scheduler was neither revolutionary nor rare even when Go was launched. Even a mainstream like C# already had one (albeit based on continuations, until C# 5.0 came out). At the same time, some mainstream programming languages either had similar third-party M:N stackful schedulers when go came out (gevent in Python) or got them a little while after (Quasar in Java).
Go's scheduler was only somewhat unique in the combination of features it pursued:
1. M:N
2. Stackful (i.e. unoptimized memory usage for each task/goroutine)
3. But using very small stacks[1] so it's easier to create a very large number of goroutines.
4. Integrated with the GC
5. Colorless functions
6. Built-in
7. No access to native threads
8. Not configurable or customizable.
9. Run as Native code, without using a virtual machine.
Colored functions (Async/await or Kotlin's suspend) are a matter of taste. They're heavily criticized for the burden they add, but advocates prefer the extra type-safety they provide. If you want to be able to statistically analyze or data races (or prevent them completely, as Rust does), I don't think you can avoid them.
Speaking of Rust, Rust did start with an M:N, work-stealing scheduler based on stackful coroutines. This scheduler was eventually removed[2] from the standard library, since it was deemed a bad match for a systems language.
Go was originally marketed as a systems language, but it was really a language that was optimized for writing concurrent servers by large teams of programmers with varying experience[3]. Specifically it was designed for server software at Google[4], and to replace the main place C++ was used for in Google: I/O-bound server software. That's why Go made very radical choices:
- Go Native (we still need good performance, but not C++-level) - Maximize concurrency - Make concurrency easy - Use GC (we need the language to be much easier than C++) - Minimize GC pause times (we need reasonable performance at server workloads)
This meant that the Go M:N Scheduler was usually the best performing stackful scheduler for server loads for a while. Interpreted languages like Python, Node and Lua were slower and were either single-threaded or had a GIL. Erlang and Java used a VM, and weren't optimized for low latency GC. C and C++ had coroutines libraries, but since these languages were not garbage-collected, it was harder to optimize the coroutine stack size.
I think it created a wrong impression that the Go scheduler was revolutionary or best-in-class. It never was. The groundbreaking thing that Go did is to optimize the entire language for highly concurrent I/O-bound workloads. That, along with a sane (i.e. non-callback-based) asynchronous model and great PR from being a Google language helped Go popularize asynchronous programming.
But I wouldn't say it is unmatched by any mainstream language nowadays. Java has low-latency GC nowadays and it's working on it's own Go-like coroutine implementation (Project Loom). But all mainstream JVM languages (Kotlin, Scala and Clojure) already have their own M:N schedulers.
Rust, in the meantime, is strictly more performant than Go: It's using state-machine based stackless coroutines, which emulate the way that manual asynchronous implementations (like Nginx) are done in C. You can't get more efficient than that. Not to mention that Rust doesn't have a GC and features more aggressive compiler optimizations.
[1] IIRC, initial stack sizes has changed between 2k-8k during the language lifetime, and the stack resizing mechanism has changed as well.
[2] https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
[3] https://talks.golang.org/2012/splash.article
[4] This is why it didn't have a package managers for many years. Google was just using a monorepo after all.
Go's scheduler was only somewhat unique in the combination of features it pursued:
1. M:N
2. Stackful (i.e. unoptimized memory usage for each task/goroutine)
3. But using very small stacks[1] so it's easier to create a very large number of goroutines.
4. Integrated with the GC
5. Colorless functions
6. Built-in
7. No access to native threads
8. Not configurable or customizable.
9. Run as Native code, without using a virtual machine.
Colored functions (Async/await or Kotlin's suspend) are a matter of taste. They're heavily criticized for the burden they add, but advocates prefer the extra type-safety they provide. If you want to be able to statistically analyze or data races (or prevent them completely, as Rust does), I don't think you can avoid them.
Speaking of Rust, Rust did start with an M:N, work-stealing scheduler based on stackful coroutines. This scheduler was eventually removed[2] from the standard library, since it was deemed a bad match for a systems language.
Go was originally marketed as a systems language, but it was really a language that was optimized for writing concurrent servers by large teams of programmers with varying experience[3]. Specifically it was designed for server software at Google[4], and to replace the main place C++ was used for in Google: I/O-bound server software. That's why Go made very radical choices:
- Go Native (we still need good performance, but not C++-level) - Maximize concurrency - Make concurrency easy - Use GC (we need the language to be much easier than C++) - Minimize GC pause times (we need reasonable performance at server workloads)
This meant that the Go M:N Scheduler was usually the best performing stackful scheduler for server loads for a while. Interpreted languages like Python, Node and Lua were slower and were either single-threaded or had a GIL. Erlang and Java used a VM, and weren't optimized for low latency GC. C and C++ had coroutines libraries, but since these languages were not garbage-collected, it was harder to optimize the coroutine stack size.
I think it created a wrong impression that the Go scheduler was revolutionary or best-in-class. It never was. The groundbreaking thing that Go did is to optimize the entire language for highly concurrent I/O-bound workloads. That, along with a sane (i.e. non-callback-based) asynchronous model and great PR from being a Google language helped Go popularize asynchronous programming.
But I wouldn't say it is unmatched by any mainstream language nowadays. Java has low-latency GC nowadays and it's working on it's own Go-like coroutine implementation (Project Loom). But all mainstream JVM languages (Kotlin, Scala and Clojure) already have their own M:N schedulers.
Rust, in the meantime, is strictly more performant than Go: It's using state-machine based stackless coroutines, which emulate the way that manual asynchronous implementations (like Nginx) are done in C. You can't get more efficient than that. Not to mention that Rust doesn't have a GC and features more aggressive compiler optimizations.
[1] IIRC, initial stack sizes has changed between 2k-8k during the language lifetime, and the stack resizing mechanism has changed as well.
[2] https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
[3] https://talks.golang.org/2012/splash.article
[4] This is why it didn't have a package managers for many years. Google was just using a monorepo after all.
I've tried both and failed.
It really depends on the goal. If one wants to end up with an elaborate hellow world, probably yes, one can learn both.
Learning Rust to make it applicable to mid/large-scale projects, and potentially for a professional transition (my case), is a one-of-a-kind commitment, in my opinion, hardly compatible with learning another language at the same time.
It really depends on the goal. If one wants to end up with an elaborate hellow world, probably yes, one can learn both.
Learning Rust to make it applicable to mid/large-scale projects, and potentially for a professional transition (my case), is a one-of-a-kind commitment, in my opinion, hardly compatible with learning another language at the same time.
In that case, I'd suggest learning Go first, as a kind of "step up" to learning Rust. If you haven't already, I'd also suggest learning C.
I think there's some linearity to these tasks. Rust (and C++) are an amalgamation of many complex features that are present in simpler predecessors. Learning C for example will not only speed up your ability to learn Rust, but also leave you with a deeper understanding of the core principles.
I think there's some linearity to these tasks. Rust (and C++) are an amalgamation of many complex features that are present in simpler predecessors. Learning C for example will not only speed up your ability to learn Rust, but also leave you with a deeper understanding of the core principles.
> If you haven't already, I'd also suggest learning C.
Learning a new language is not something to take lightly. Should I take 6 months in order to get more solid foundations before moving to Rust? 1 year? N years?
My biggest hurdle has been ownership ("borrow checking", which is the common problem) in the broad sense (which includes: learning to design a whole program considering ownership). This is something that C/++ programmers are surely familiar with, so it absolutely helps, but I don't think it's efficient to learn C/++ in order to step up to Rust.
Learning a new language is not something to take lightly. Should I take 6 months in order to get more solid foundations before moving to Rust? 1 year? N years?
My biggest hurdle has been ownership ("borrow checking", which is the common problem) in the broad sense (which includes: learning to design a whole program considering ownership). This is something that C/++ programmers are surely familiar with, so it absolutely helps, but I don't think it's efficient to learn C/++ in order to step up to Rust.
The more languages you learn, especially with reusable concepts, the less of a tax it is to learn a new one. As someone who has written C/C++ for over a decade, learning Rust felt very straightforward -- I just had to learn about the borrow checker, and it was fairly straightforward to reason about how it works based on my knowledge of unique pointers in C++.
I certainly don't think C++ is a prerequisite to learning Rust, but I do think your path to deeply understanding Rust will accelerate if you understand C (or specifically, understand pointers and heap allocations). But to each their own!
I certainly don't think C++ is a prerequisite to learning Rust, but I do think your path to deeply understanding Rust will accelerate if you understand C (or specifically, understand pointers and heap allocations). But to each their own!
Learning new languages is certainly useful/important, but time is finite. The idea of learning a certain language as a bridge to another is unrealistic unless one has a _lot_ of time.
I come from Haskell and fought fiercely with the borrow checker for two months. We’re friends now.
I talked to a C programmer who said thinking in lifetimes (when to free()) was second nature, so didn’t even think heavily about it.
I talked to a C programmer who said thinking in lifetimes (when to free()) was second nature, so didn’t even think heavily about it.
Just replied to another comment recommending C. Can you help me understand which core principles C would help to refine i.e. what am I leaving on the table if I go with a Rust or C++?
Nothing, these languages all expose the same underlying memory controls. But going with C may still be valuable, because rust and C++ has much better abstractions and especially with Rust, it can easily hide the pointer manipulation part from you, when that’s the reason one presumably learnt the language for.
Thanks, exactly what I was looking for!
> Just replied to another comment recommending C. Can you help me understand which core principles C would help to refine i.e. what am I leaving on the table if I go with a Rust or C++?
In the other thread you mention features. I suggest C because of its "simplicity", that is, its lack of features. It really is a thin abstraction on top of assembly. C's closeness to the hardware is edifying.
Moreover, since the goal is learning, History is quite relevant. Languages evolve in the context of their predecessors. You probably already know this for typescript since it is so close to JavaScript. But how do C++ and rust relate to C? And how does Go relate to C++ and C?
Languages always involve tradeoffs. For example, a language that checks memory bounds at runtime (Go) uses more CPU cycles than one that doesn't (C). A compiler that does checks is more complex than one that doesn't. Language features can help with safety (rust), but then the language takes more time to learn. Complexity can be hidden (Go garbage collection) to make up front learning easier, but this can make the language less flexible or more difficult to debug. Complexity can be exposed later but then the language learning curve is lengthened.
I'm not suggesting you go become a C pro, but learn enough to shoot yourself in the foot. It will help contextualize the features of these other languages and give your more mental tools for decision making in your own code.
In the other thread you mention features. I suggest C because of its "simplicity", that is, its lack of features. It really is a thin abstraction on top of assembly. C's closeness to the hardware is edifying.
Moreover, since the goal is learning, History is quite relevant. Languages evolve in the context of their predecessors. You probably already know this for typescript since it is so close to JavaScript. But how do C++ and rust relate to C? And how does Go relate to C++ and C?
Languages always involve tradeoffs. For example, a language that checks memory bounds at runtime (Go) uses more CPU cycles than one that doesn't (C). A compiler that does checks is more complex than one that doesn't. Language features can help with safety (rust), but then the language takes more time to learn. Complexity can be hidden (Go garbage collection) to make up front learning easier, but this can make the language less flexible or more difficult to debug. Complexity can be exposed later but then the language learning curve is lengthened.
I'm not suggesting you go become a C pro, but learn enough to shoot yourself in the foot. It will help contextualize the features of these other languages and give your more mental tools for decision making in your own code.
Pointers :). C++ and Rust try to hide the concept away with References, which add a very helpful amount of type safety, but do not protect you from the fundamental idea of allocating memory and then later free-ing it.
It's not that you leave it on the table with Rust/C++ but more that you'll have a deeper understanding for what's going on if you understand how pointers work in C.
It's not that you leave it on the table with Rust/C++ but more that you'll have a deeper understanding for what's going on if you understand how pointers work in C.
Thanks this is what I was looking for! Pointers are one of those things I’ve heard about for years but don’t know too much about. I know that in js objects are passed by copies of a reference to that object in memory. I have never felt that there was something missing here — only that it requires an understanding of which types in js are passed by value vs reference. What is the upside to pointers in C? For instance in js I can pass an object to a function that modifies the object’s properties. The only thing I can’t do (I think) is pass an object to a function, and then reassign that object’s reference to a new object literal such that the original object reference now references the new object literal. Is this gap in a language like js where pointers come in, or am I missing the forest for the trees? If this is where pointers become useful/beneficial to be knowledgeable on, can they really be that useful? Full disclaimer that I don’t know anything about pointers aside from implementing data structures in js e.g. a linked list node has a `this.next` property, but in other languages this seems to be called/implemented as a pointer from what I’ve seen.
To sum my thoughts on this up: can you help me understand why pointers would be useful for me to invest in learning on the level of C versus continuing to let them be abstracted away/not present in my language? What would that knowledge do for me? Will I be a better problem solver etc. thanks again!
To sum my thoughts on this up: can you help me understand why pointers would be useful for me to invest in learning on the level of C versus continuing to let them be abstracted away/not present in my language? What would that knowledge do for me? Will I be a better problem solver etc. thanks again!
It's not that there's an "advantage" to pointers, but rather it's the reality that they exist. Everything you're doing in JS also "uses" pointers under the hood, but the language and runtime abstract that away from you. C exposes you to pointers directly, so you have an opportunity to learn what they are and how they work.
It's important to learn how they work, because it'll give you a better idea of what's actually happening in the higher level languages you're using. That may not be important if you stick to JS or Go, but if you'd like to learn Rust then it's impossible to accurately think through tradeoffs like whether to use Box, Rc, Arc, etc. without understanding how pointers work. In other words, I'd only recommend learning Rust if you take the time to understand pointers, and the best way to understand pointers is to write C.
It's important to learn how they work, because it'll give you a better idea of what's actually happening in the higher level languages you're using. That may not be important if you stick to JS or Go, but if you'd like to learn Rust then it's impossible to accurately think through tradeoffs like whether to use Box, Rc, Arc, etc. without understanding how pointers work. In other words, I'd only recommend learning Rust if you take the time to understand pointers, and the best way to understand pointers is to write C.
"Yes"
I personally find that even spending a little bit of time in a programming language with a different paradigm is incredibly helpful. So I'd suggest that Go is probably too similar to be maximally helpful, Rust is really good, but something like Haskell might give your brain a better workout even if you never actually use it for anything concrete.
If your priority is to get things done, do them in TypeScript unless you've a really good reason to learn another ecosystem at the same time. If your priority is to learn and get better at programming in general, digging into pretty much anything else will help. Just don't necessarily expect to get anything done.
I personally find that even spending a little bit of time in a programming language with a different paradigm is incredibly helpful. So I'd suggest that Go is probably too similar to be maximally helpful, Rust is really good, but something like Haskell might give your brain a better workout even if you never actually use it for anything concrete.
If your priority is to get things done, do them in TypeScript unless you've a really good reason to learn another ecosystem at the same time. If your priority is to learn and get better at programming in general, digging into pretty much anything else will help. Just don't necessarily expect to get anything done.
Very pragmatic perspective. I find this helpful in that it defines a line between getting things done vs investing in my own growth. Before reading this, my thoughts on Go were that it was a better way of “getting things done” than how I do it now in TS, but you’ve shifted my perspective to it being more of a middle path. I am perfectly able to get things done in TS and then could supplement that with Rust for growth purposes. Thanks for taking the time to reply Andrew!
I have a Python and TypeScript background, and I worked with them on a daily basis as a web developer.
Rust will be more familiar and easy on the eyes, as the syntax and concepts are close to friendlier languages.
I just started to get into Rust as well, and so far I'm loving it.
Here are some resources to help throughout the journey:
https://fasterthanli.me/articles/a-half-hour-to-learn-rust
https://stevedonovan.github.io/rust-gentle-intro/readme.html
https://learning-rust.github.io/docs/a1.why_rust.html
And for Youtube: https://www.youtube.com/c/LetsGetRusty
Good luck and have fun!
Rust will be more familiar and easy on the eyes, as the syntax and concepts are close to friendlier languages.
I just started to get into Rust as well, and so far I'm loving it.
Here are some resources to help throughout the journey:
https://fasterthanli.me/articles/a-half-hour-to-learn-rust
https://stevedonovan.github.io/rust-gentle-intro/readme.html
https://learning-rust.github.io/docs/a1.why_rust.html
And for Youtube: https://www.youtube.com/c/LetsGetRusty
Good luck and have fun!
As someone with background in Perl, Java, Bash, Scala, and others (FoxPro anyone?, ...), for me the choice is also Rust. I want to spend my finite learning energy and time on what will give me the fewest limitations and most abilities, long-term. :)
Had to learn FoxPro to support some legacy software. Fun times :)
(a ps: and some C/C++ which make me like Rust even more)
Thanks I appreciate the context and resources from someone with a similar background!
Reading the Go spec will only take an hour or two if you don't get distracted. If wasting time is your concern, it's such a small amount that you've probably recently wasted more time on a number of trivial things. Reading the Rust Book takes a bit longer, but it's still just a handful of hours.
https://go.dev/ref/spec https://doc.rust-lang.org/book/
https://go.dev/ref/spec https://doc.rust-lang.org/book/
> Reading the Rust Book takes a bit longer, but it's still just a handful of hours.
Speaking as someone who is really enjoying learning Rust, time taken to read the book isn't a good metric for understanding the language.
Speaking as someone who is really enjoying learning Rust, time taken to read the book isn't a good metric for understanding the language.
The book is just a first step. The really important thing is "how much work do I have to do to get a decent level of foundational knowledge about the language", which is relatively little for either Go or Rust (or most other languages).
> The really important thing is "how much work do I have to do to get a decent level of foundational knowledge about the language", which is relatively little for either Go or Rust (or most other languages).
I might have agreed with this before I tried using Rust's strings, borrow checker and lifetimes in anger. I had some real speed bumps with these even given my prior knowledge of C#, Common Lisp and C.
I might have agreed with this before I tried using Rust's strings, borrow checker and lifetimes in anger. I had some real speed bumps with these even given my prior knowledge of C#, Common Lisp and C.
I agree that Go is a much smaller language and it can be learned more quickly. But I'm not sure if reading the spec is the right approach here. Shouldn't OP rather learn from a tutorial? The spec will explain the "how" part of the language but probably not the "why" part.
https://go.dev/learn/
https://go.dev/learn/
The spec is very easy to read, and followed with some code examples can have you up to speed very quickly. Better to just spend the time up-front when it's cheap and then get the practice actually using the knowledge.
I'm not terribly familiar with Go, but surely the comparison here must be with Rusts Reference[0]? It is a bit shorter than the Rust Book (a simple print-to-pdf says 435 pages vs. 664 pages, and 104 pages for the Go spec).
0: https://doc.rust-lang.org/reference
0: https://doc.rust-lang.org/reference
I think the Go reference was designed with learning users in mind, whereas the Rust one isn't. That's where the book comes in; it's a more structured way to learn the language than just reading the reference. The reference can be supplementary, thought.
Thanks for sharing! That’s good to know. I’ll likely knock out the go spec in that case. Lmk if you have any opinions either way
I’ve been doing mainly JS and TS the last few years and picked up Rust because I wanted to build a video editor. It worked out, the product is launched (used Tauri which is also nice) and I’d choose Rust again, even despite the initial pain.
The basics weren’t too hard, but I definitely felt the learning curve! I used C and C++ professionally my first few years out of school, and in some senses Rust felt like coming home - thinking about memory again, references vs values, the short naming conventions… but in other ways (lol borrowing) it was a very different thing. Rust was the first language I learned in recent years where I couldn’t just cobble things together once I knew the basic syntax. The ownership system was at the heart of that, and I kept doing things that went against the grain and made the compiler unhappy.
Having come out the other side though, I’m really happy with Rust. It’s fast, and the safety aspect is awesome because I can be pretty sure that as long as I avoid .unwrap()ing things, the program isn’t going to crash. There’s none of the “null or undefined” anxiety like with JS.
It’s also interesting to see the difference in the communities. I really like how performance is a first-class citizen in Rust! A lot of libraries have benchmarks. People go out of their way to avoid allocating memory. Maybe overkill in some spots for sure, but it’s a stark contrast to the JS world where I often get the sense that talking about performance will attract cries of “premature optimization!”
For learning I used the official Rust Book initially, then Programming Rust (the O’Reilly one) to get another explanation of some things, and then Rust for Rustaceans - which was great but way over my head at the time and I should probably revisit it again.
I would say learning Rust needs a very hands-on approach. It wasn’t, at least for me, the kind of language where I could read a book and then go write Rust. It took practice and failure and mental shifts that I don’t think would’ve happened if I was reading or watching videos.
Good luck with whatever you choose and happy 4th!
The basics weren’t too hard, but I definitely felt the learning curve! I used C and C++ professionally my first few years out of school, and in some senses Rust felt like coming home - thinking about memory again, references vs values, the short naming conventions… but in other ways (lol borrowing) it was a very different thing. Rust was the first language I learned in recent years where I couldn’t just cobble things together once I knew the basic syntax. The ownership system was at the heart of that, and I kept doing things that went against the grain and made the compiler unhappy.
Having come out the other side though, I’m really happy with Rust. It’s fast, and the safety aspect is awesome because I can be pretty sure that as long as I avoid .unwrap()ing things, the program isn’t going to crash. There’s none of the “null or undefined” anxiety like with JS.
It’s also interesting to see the difference in the communities. I really like how performance is a first-class citizen in Rust! A lot of libraries have benchmarks. People go out of their way to avoid allocating memory. Maybe overkill in some spots for sure, but it’s a stark contrast to the JS world where I often get the sense that talking about performance will attract cries of “premature optimization!”
For learning I used the official Rust Book initially, then Programming Rust (the O’Reilly one) to get another explanation of some things, and then Rust for Rustaceans - which was great but way over my head at the time and I should probably revisit it again.
I would say learning Rust needs a very hands-on approach. It wasn’t, at least for me, the kind of language where I could read a book and then go write Rust. It took practice and failure and mental shifts that I don’t think would’ve happened if I was reading or watching videos.
Good luck with whatever you choose and happy 4th!
Wow, I can’t believe I’m seeing you in these comments! I was so inspired when I first saw Recut, and I’ve been using your interview questions for inspiration in my own interviews recently. My plan as soon as I get my next day job has been to sit down and start making products with the hope of launching on product hunt and the like to start earning money on the side. This post was mainly shopping for input on long-term conceptual growth, so it’s really nice to get this bonus anecdote on Rust in production from you.
I definitely would wait to fully invest my time in it until I have my next job given this + the other replies. I am curious if you did any research on Go or other languages for Recut and why you ended up choosing Rust. Would you make the same decision again? Was it worth the time it took to learn Rust for both product/personal purposes, or would you go with something easier if you had to do it again?
Recut was especially interesting to me since I’ve had a real time video chat based app on my mind for almost 2 years now and have known js just won’t cut it. Seems like quite the indicator that I should invest in Rust.
Thanks for your reply. Means a lot getting feedback from you down here in the HN trenches!
I definitely would wait to fully invest my time in it until I have my next job given this + the other replies. I am curious if you did any research on Go or other languages for Recut and why you ended up choosing Rust. Would you make the same decision again? Was it worth the time it took to learn Rust for both product/personal purposes, or would you go with something easier if you had to do it again?
Recut was especially interesting to me since I’ve had a real time video chat based app on my mind for almost 2 years now and have known js just won’t cut it. Seems like quite the indicator that I should invest in Rust.
Thanks for your reply. Means a lot getting feedback from you down here in the HN trenches!
Awesome, glad to hear that :) So, for Rust vs Go, honestly I had kinda wanted to learn Rust for a while and have only read a little bit of Go, and – this is going to sound incredibly silly, but I'm not a big fan of some of the syntax and conventions from Go.
For Recut, the choice was more between (a) coupling Rust with a web-based cross-platform framework like Electron or Tauri or (b) using C++ and Qt. I guess option (c) would be to write and maintain two versions of the app, one in Swift and the other in something Windows-specific, but as a solo developer I ruled that out pretty quickly.
So - Rust vs. C++ - and would the Rust + JS be fast enough? I did some experiments to test out some of the things I was worried about, like rendering video frames, and sending data between the UI and Rust.
I've had experience with C++ and Qt in the past, so that was a decent option. But I didn't love the idea of getting back into C++ and fighting with the inevitable hard-to-find crashes and race conditions and stuff. And, from building v1 of Recut in Swift, I came to really enjoy some of Swift's safety, too - like guard clauses that rule out null-pointer-related crashes. Rust seemed similar in those aspects.
Given how it turned out, I would definitely choose Rust again. I think it might've been wise to try to learn more about the language and tackle some smaller toy problems first, instead of trying to learn it while writing the app. I didn't do much exploratory hacking, and ended up rewriting whole swaths of the video pipeline stuff multiple times. Like at least 5 times. But maybe that was the best way to actually learn it, too. I don't really know if I would've picked up the intuition for some of the patterns if I hadn't had to fight my way through it. So maybe there's some survivorship bias here haha.
For Recut, the choice was more between (a) coupling Rust with a web-based cross-platform framework like Electron or Tauri or (b) using C++ and Qt. I guess option (c) would be to write and maintain two versions of the app, one in Swift and the other in something Windows-specific, but as a solo developer I ruled that out pretty quickly.
So - Rust vs. C++ - and would the Rust + JS be fast enough? I did some experiments to test out some of the things I was worried about, like rendering video frames, and sending data between the UI and Rust.
I've had experience with C++ and Qt in the past, so that was a decent option. But I didn't love the idea of getting back into C++ and fighting with the inevitable hard-to-find crashes and race conditions and stuff. And, from building v1 of Recut in Swift, I came to really enjoy some of Swift's safety, too - like guard clauses that rule out null-pointer-related crashes. Rust seemed similar in those aspects.
Given how it turned out, I would definitely choose Rust again. I think it might've been wise to try to learn more about the language and tackle some smaller toy problems first, instead of trying to learn it while writing the app. I didn't do much exploratory hacking, and ended up rewriting whole swaths of the video pipeline stuff multiple times. Like at least 5 times. But maybe that was the best way to actually learn it, too. I don't really know if I would've picked up the intuition for some of the patterns if I hadn't had to fight my way through it. So maybe there's some survivorship bias here haha.
IMO it's short term enablement versus long term.
You will feel productive early on in Go, but it plateaus. Rust has a lot more CS concepts and I think will be the more fruitful learning experience.
Also, Rust can lead you to WASM, which might work well with your web background.
You will feel productive early on in Go, but it plateaus. Rust has a lot more CS concepts and I think will be the more fruitful learning experience.
Also, Rust can lead you to WASM, which might work well with your web background.
This feels like something I needed to hear. Everything I do in life I try to maximize for long term gains, so this tells me that Rust is very likely for me even if it means I’ll make less flashy stuff at first. Also I am definitely interested in wasm and have been hearing about it for a long while but still admittedly can’t put my finger on what it’d really do for me. I generally find my front end performance to not be limited by js thanks to Cloudflare/web workers, but then again I haven’t done anything I’d consider truly heavyweight just yet. I’d be curious if you knew of any interesting rust/wasm use cases, or if you have any thoughts on where that space is headed and why it’d be good to invest in learning it. Thanks for the insightful reply :)
WASM is still fairly niche, some immediate/near term use cases might be: advanced animation (beyond CSS), 3D/VR, low-latency / low level work e.g. webUSB. MAYBE some very forward looking web-apps/hybrid apps.
There's no disputing that v8 has come a long way, so likely it's not going to be that much of a perf gain, more interesting to me is bringing more advanced languages (such as Rust) into play, great and all as TypeScript is.
There's no disputing that v8 has come a long way, so likely it's not going to be that much of a perf gain, more interesting to me is bringing more advanced languages (such as Rust) into play, great and all as TypeScript is.
Go can also compile to WASM.
AFAIK since Go is garbage-collected, the WASM it generates probably needs to include a runtime, right? While in Rust since the ownership is verified at compile-time there is no need for GC.
Please correct me if I am wrong.
EDIT: s/runtime/compile-time
Please correct me if I am wrong.
EDIT: s/runtime/compile-time
Can you say a little about what it means that since Rust has provable ownership at runtime, there is no need for GC? I’m familiar with Rust ownership on the surface, but lack the knowledge to see how it eliminates the need for GC. Is it just Rust’s way of guaranteeing that a program is memory safe, or is there more to it?
(A bit simplified)My understanding is that reference counting is one of the easiest way to deal with memory assignments and it needs GC.
If the ownership rules determine at compile time that your memory assignments are fine (no double free, etc.), you can avoid using reference counting (and the associated GC).
If the ownership rules determine at compile time that your memory assignments are fine (no double free, etc.), you can avoid using reference counting (and the associated GC).
Garbage collection deals with removing allocated objects that are no longer used. Non-managed languages without a garbage-collected runtime will have to issue the corresponding “free” command for each heap-allocated memory at the necessary place. This is a hard thing to do, because freeing it before the time can result in use-after-frees that are huge vulnerabilities, and not freeing it is a memory leak.
Reference counting is a form of GC, but in itself it is not sufficient (it will leak circular references as those will always reference each other). Due to its simplicity, in a sufficiently expressive language one can create this abstraction (see shared_ptr in c++, RC, ARC in Rust) and with the necessary caveats of not using circular structures with it, you get an ergonomic semi-GC without runtime support.
Compile time/runtime issue is slightly different - in case of many allocations one can know where you will have to free it even at compile time. C++ has a concept called RAII, which is basically “put a free at the end of the scope”. This works surprisingly well for most use cases and Rust sort of mandates this semantics by the compiler in the general case.
But an object’s lifetime can’t be known in advance (think of a User object for a logged in user. Is it still needed or had it expired?) in the general case, that’s why runtime GC is needed like refcounting or tracing GC in managed languages.
Reference counting is a form of GC, but in itself it is not sufficient (it will leak circular references as those will always reference each other). Due to its simplicity, in a sufficiently expressive language one can create this abstraction (see shared_ptr in c++, RC, ARC in Rust) and with the necessary caveats of not using circular structures with it, you get an ergonomic semi-GC without runtime support.
Compile time/runtime issue is slightly different - in case of many allocations one can know where you will have to free it even at compile time. C++ has a concept called RAII, which is basically “put a free at the end of the scope”. This works surprisingly well for most use cases and Rust sort of mandates this semantics by the compiler in the general case.
But an object’s lifetime can’t be known in advance (think of a User object for a logged in user. Is it still needed or had it expired?) in the general case, that’s why runtime GC is needed like refcounting or tracing GC in managed languages.
These give me some good context to go off of. Are there any resources you’d recommend on an intro to garbage collection for devs without the low level cs background? I’ll read a textbook if I have to, I just don’t know where to start with that sort of thing in terms of biting off comprehend-able amounts of info
Unfortunately, I am not aware of too much intro-level texts on the topic (I would be happy to get some from other commenters). One well-regarded book is Crafting Interpreters, though it covers a wider topic. Didn’t check this section, but perhaps its GC chapter is a good introduction: https://craftinginterpreters.com/garbage-collection.html
Go has also wasm output.
If you want to build web services, I'd go with Go. It has an http library in its standard library. It generally has a bigger standard library. Rust has a bigger stdlib than say C++, but it's still pretty anemic by the standards of modern languages. Go also compiles a lot faster than Rust, which is a major point.
If you like functional programming, or want to write embedded software, or high-performance software, I'd go with Rust. All those things are a lot easier in Rust.
Personally, I use Go for scripting and Rust for big projects, because Go compiles fast enough, has a nicer stdlib and dependency management than Python; while for big project my natural tendency to think functionally would make it too annoying having to translate simple concepts into programs twice as long as they need to be, expressing what they're doing very indirectly. But I don't write web services, so that's a different story.
If you like functional programming, or want to write embedded software, or high-performance software, I'd go with Rust. All those things are a lot easier in Rust.
Personally, I use Go for scripting and Rust for big projects, because Go compiles fast enough, has a nicer stdlib and dependency management than Python; while for big project my natural tendency to think functionally would make it too annoying having to translate simple concepts into programs twice as long as they need to be, expressing what they're doing very indirectly. But I don't write web services, so that's a different story.
I worked mainly in web dev for almost 2 decades now and having programmed both with Rust and Go, my vote would be to default for Rust, so I guess you everyone's mileage may vary.
Also the argument about the stdlib is kind of weird. It's a deliberate choice to keep the stdlib small, also because adding a new package to the projects takes a few seconds. If you were tasked to do a web backend with a limitation of "you can't use any external libraries" then yeah, I'd say Go might be easier, but otherwise there's almost no difference in practice
Also the argument about the stdlib is kind of weird. It's a deliberate choice to keep the stdlib small, also because adding a new package to the projects takes a few seconds. If you were tasked to do a web backend with a limitation of "you can't use any external libraries" then yeah, I'd say Go might be easier, but otherwise there's almost no difference in practice
Learn elixir. The way you program elixir will push you towards better coding. There's a good chance you'll get better at testing, better at writing documentation. If you stick around long enough, you will learn about distributed systems (and their failure and recovery modes) and failure domain management -- this stuff is built into the stdlib
I was going to say Elixir, thanks for mentioning it.
I'll also add that Haskell, Clojure, and other functional languages will help you think in an entirely new way to program. Python or Ruby are also less mind-expanding, but was a nice change of pace for me at least from my C# day job.
Learning window functions and more advanced bits of SQL that an ORM doesn't give you for free can also be a fun time, along with getting deeper into what indexes can really do.
I'll also add that Haskell, Clojure, and other functional languages will help you think in an entirely new way to program. Python or Ruby are also less mind-expanding, but was a nice change of pace for me at least from my C# day job.
Learning window functions and more advanced bits of SQL that an ORM doesn't give you for free can also be a fun time, along with getting deeper into what indexes can really do.
This is the first I’ve heard a recommendation to learn elixir. I’m definitely interested based on your description + a quick google. Is there anything that comes to mind in terms of what it does different from Go/Rust that makes you recommend it? My understanding was that I’d get these types of benefits from those two languages
Painting with a broad brush... Elixir is like the new ruby where Go is like the new C and Rust is like the new C++.
Elixir shines at concurrency so it will feel more like nodejs and similarly runs on a VM like Node or Java.
Elixir, like Rust, will help with learning functional programming paradigms more than Go.
Elixir shines at concurrency so it will feel more like nodejs and similarly runs on a VM like Node or Java.
Elixir, like Rust, will help with learning functional programming paradigms more than Go.
I disagree here, Elixir looks similar to Ruby from a syntax perspective. But as soon as you dig into OTP it is a completely new world.
It's true that as a beginner you can simply do web development with Phoenix and that feels similar to Rails (Or Django / Laravel / Spring / whatever web framework ). But OTP requires a different way of approaching problems.
It's true that as a beginner you can simply do web development with Phoenix and that feels similar to Rails (Or Django / Laravel / Spring / whatever web framework ). But OTP requires a different way of approaching problems.
I think your comparisons are at the superficial "what does syntax look like" level. If you're thinking culturally, roles, what they're expected to be used for, what hires look like:
Elixir is the new Erlang. Ruby is dead (I used to <3 ruby). Go is the new python, zig is the new c, and rust is the new c++.
Elixir is the new Erlang. Ruby is dead (I used to <3 ruby). Go is the new python, zig is the new c, and rust is the new c++.
I don't think Go or Rust provides anything similar to what you have in Erlang/Elixir. I've done a lot of Ruby and then while learning Haskell and Elm has been a paradigm change with their type systems, Elixir/Erlang felt like a much bigger step in terms of a different required way of approaching problems.
It's not that it's functional (that's completely secondary in Erlang) but its fault tolerance primitives (processes, pids, mailboxes, monitors and links) and the OTP abstractions (GenServers, Supervisors, etc).
You learn to think in terms of distributed systems and think about fault tolerance in a way you cannot in other languages as they don't provide the primitives. It's quite a big leap and it takes time to sink in.
It's not that it's functional (that's completely secondary in Erlang) but its fault tolerance primitives (processes, pids, mailboxes, monitors and links) and the OTP abstractions (GenServers, Supervisors, etc).
You learn to think in terms of distributed systems and think about fault tolerance in a way you cannot in other languages as they don't provide the primitives. It's quite a big leap and it takes time to sink in.
I've used both for a couple of projects, but my primary language of choice for most things nowadays is Rust so this will be a bit biased. However, Go is a fun language to use, it is incredibly easy to get up and running, it provides most of the tooling you need in a language (formatting, testing, linting etc) and compiles very fast (especially compared to Rust). It is a simpler language than Rust, and is missing a fair bit of more advanced features that other new languages has. Coming from TypeScript, I suspect Go will feel like a simpler version of it, the generic programming and type level magic you can do in TypeScript is far more advanced than the generics that Go (finally) has.
Comparing this to Rust however is a different ball game, where Go is straight forward and fairly easy to use, with Rust it can feel like the compiler is your enemy. Learning how the borrow checker works, why there are a whole bunch of string types, how mutability and references work when passing them around and so on is a serious undertaking. But once you get somewhat comfortable with it Rust is great. The compiler will guide you along with very helpful error messages, you can use pattern matching, traits and a advanced type system to your advantage to build very performant and easy to maintain programs.
In terms of getting "to the next level", I would highly recommend trying out Rust. Go is not a language that will challenge you the same way learning Rust will, the concepts and patterns from other languages map over fairly well to it (though the concurrency story in Go is really cool, definitely give it a good look!) whereas Rust will be more foreign.
I had used Rust for a few years when I worked on a couple of programs written in Go and it took me a week or two before I felt mostly comfortable with it. With Rust however it took me a few months to stop getting compiler errors every time I saved, and a few more months to internalize why the borrow checker complains. But working on the projects using Go felt like a downgrade from Rust, I gotta be honest. So many times I sat there thinking about how features from Rust would've made things so much neater... though now I feel the same with Haskell and Rust.
Comparing this to Rust however is a different ball game, where Go is straight forward and fairly easy to use, with Rust it can feel like the compiler is your enemy. Learning how the borrow checker works, why there are a whole bunch of string types, how mutability and references work when passing them around and so on is a serious undertaking. But once you get somewhat comfortable with it Rust is great. The compiler will guide you along with very helpful error messages, you can use pattern matching, traits and a advanced type system to your advantage to build very performant and easy to maintain programs.
In terms of getting "to the next level", I would highly recommend trying out Rust. Go is not a language that will challenge you the same way learning Rust will, the concepts and patterns from other languages map over fairly well to it (though the concurrency story in Go is really cool, definitely give it a good look!) whereas Rust will be more foreign.
I had used Rust for a few years when I worked on a couple of programs written in Go and it took me a week or two before I felt mostly comfortable with it. With Rust however it took me a few months to stop getting compiler errors every time I saved, and a few more months to internalize why the borrow checker complains. But working on the projects using Go felt like a downgrade from Rust, I gotta be honest. So many times I sat there thinking about how features from Rust would've made things so much neater... though now I feel the same with Haskell and Rust.
Thanks! This helps and gives some great perspective. Given your thoughts on this, would you recommend I start with Go and transition to Rust, or dive right into Rust with the goal of looking back on Go and seeing the difference after 6+ months of Rust?
I don't really think you can go wrong starting with either, I personally would obviously recommend Rust over Go since it is my language of choice and I think it will let you grow more as a developer than Go.
I've gone this path, and it ultimately depends on your goal.
If you want to broaden your skill set for your personal enjoyment, both are options, although "enjoying" learning Rust has a slightly masochistic trait ;)
I believe Rust is more of a calling, in the sense that it requires a unique motivation - it really is _so_ hard, especially coming from dynamic/high level languages - and those who want to go through this, kinda know it already. But of course, that doesn't mean that it's for an elite only.
In a professional context though, Rust is hardly a productive choice. It has a very narrow market share. You can throw the stats out of the window; they don't match reality; reality is that lots of Rust work is in crypto, and that positions at Big techs seem to be filled internally. In short: you'll find very few available and appealing positions.
The good side is that Rust is sort of in its infancy, so there are fun communities to be part of.
Go... is simply the conservatively good choice. It's easy, and it's everywhere, and it's still a good step towards systems programming (independently of it being classifiable as systems programming language or not), if that's a direction you find desirable.
If you want to broaden your skill set for your personal enjoyment, both are options, although "enjoying" learning Rust has a slightly masochistic trait ;)
I believe Rust is more of a calling, in the sense that it requires a unique motivation - it really is _so_ hard, especially coming from dynamic/high level languages - and those who want to go through this, kinda know it already. But of course, that doesn't mean that it's for an elite only.
In a professional context though, Rust is hardly a productive choice. It has a very narrow market share. You can throw the stats out of the window; they don't match reality; reality is that lots of Rust work is in crypto, and that positions at Big techs seem to be filled internally. In short: you'll find very few available and appealing positions.
The good side is that Rust is sort of in its infancy, so there are fun communities to be part of.
Go... is simply the conservatively good choice. It's easy, and it's everywhere, and it's still a good step towards systems programming (independently of it being classifiable as systems programming language or not), if that's a direction you find desirable.
> I’d like to learn whichever language will make me a “better” coder in the long term.
Since the goal is to learn rather than to get stuff done, I suspect Rust will give you far more bang for the buck.
If you're arrived at TypeScript voluntarily as an alternative to JS, Rust's type system will teach you a lot about types. You'll also be able to take advantage of a lot of what you already know.
Rust will teach you more than you thought there was to know about memory. Unless you've worked with a manual memory management language before, this will be a big eye-opener regardless of where you go with Rust in the future.
But I suspect you'll be most surprised by how approachable Rust is. It feels like a much higher-level language than its reputation might hint at. The single reason for Rust's difficult reputation is the "ownership model." If you own that and commit to figuring it out and practicing what you've learned, Rust will open up much more easily to you. That said, you can figure out a lot about Rust without ever using ownership.
Since the goal is to learn rather than to get stuff done, I suspect Rust will give you far more bang for the buck.
If you're arrived at TypeScript voluntarily as an alternative to JS, Rust's type system will teach you a lot about types. You'll also be able to take advantage of a lot of what you already know.
Rust will teach you more than you thought there was to know about memory. Unless you've worked with a manual memory management language before, this will be a big eye-opener regardless of where you go with Rust in the future.
But I suspect you'll be most surprised by how approachable Rust is. It feels like a much higher-level language than its reputation might hint at. The single reason for Rust's difficult reputation is the "ownership model." If you own that and commit to figuring it out and practicing what you've learned, Rust will open up much more easily to you. That said, you can figure out a lot about Rust without ever using ownership.
I've been learning Rust for the past few weeks and have been enjoying it a lot.
- The community is very helpful on Discord (https://discord.com/invite/rust-lang-community).
- The package ecosystem (crates.io) makes it very easy to find and import things, and they're consistently documented.
- There's a path to compiling on web via WebAssembly (https://rustwasm.github.io/wasm-pack/)
In a few weeks of learning the language, I managed to put together this visualization: https://twitter.com/admiralakk/status/1542560489091350529
But realistically, either Go or Rust will be fine. You should pick the one you're more likely to stick with and learn, even when it gets tough. I've found the community aspect to be very helpful, because then at least I know I'm not the only idiot out there.
- The community is very helpful on Discord (https://discord.com/invite/rust-lang-community).
- The package ecosystem (crates.io) makes it very easy to find and import things, and they're consistently documented.
- There's a path to compiling on web via WebAssembly (https://rustwasm.github.io/wasm-pack/)
In a few weeks of learning the language, I managed to put together this visualization: https://twitter.com/admiralakk/status/1542560489091350529
But realistically, either Go or Rust will be fine. You should pick the one you're more likely to stick with and learn, even when it gets tough. I've found the community aspect to be very helpful, because then at least I know I'm not the only idiot out there.
I think you have the right idea already, so it just depends on what you want. I believe that learning Rust has made me a better programmer because I am now explicitly thinking about ownership rules and references no matter what language I'm using. Types and memory allocation are also more explicit in Rust than in Go, adding to learning aspect. I don't think learning Go has made me a better programmer. It was just another pretty standard language. But I already knew a range of other compiled languages previously and Go wasn't sufficiently different.
Like you said, for "getting things done" that is not low-level, systems, or game programming, Go is the more reasonable choice. It's more straightforward, faster to iterate in, usually more concise, has easy concurrency primitives, and is more widely adopted in the industry.
TLDR; I'd go for Rust if you want to optimize for learning and Go otherwise.
Like you said, for "getting things done" that is not low-level, systems, or game programming, Go is the more reasonable choice. It's more straightforward, faster to iterate in, usually more concise, has easy concurrency primitives, and is more widely adopted in the industry.
TLDR; I'd go for Rust if you want to optimize for learning and Go otherwise.
If you're looking to get into the k8s space Go would be the way to... go.
Purely as a language, Go is worse than TypeScript by a lot (yes, even with generics), yet has a really well made standard library that more than makes up for it in many regards, and tooling thats similarly much better and pleasant to work with.
If you're looking to learn more about systems programming as well as a bunch of advanced PL features that make development a joy, go for Rust. Besides being an excellent language, the library ecosystem and tooling are really well made as well (great documentation culture, tools work predictably and cover both simple and complex / larger use cases e.g. monorepos, etc.)
I've decided to learn Rust. I had some small amount of hobbyist C++ development experience before, and the learning curve isn't as bad as it looks, and its definitely better than something like Haskell due to the excellent documentation resources. It took a couple of weeks, about 1h-2h per day to get past the initial "wall-like" learning curve for borrowing and ownership (its important to preserve during this period)
I've refused to get into Golang as a matter of principle for a long time. I saw the language as a step backwards that deliberately ignores a lot of things we've learned in the past few decades in the name of "simplicity". While I acknowledge that the ecosystem as a whole is powerful, I'd like a tool that doesn't deliberately limit me without giving anything in return (lack of algebraic data types means reduced safety and more bugs due to inability to make illegal states unrepresentable, for example), all while trying to paint that as some kind of benefit. However, I reserve the right to change my mind if the right opportunities present themselves (also, given that they fixed generics, once error handling is made closer to Rust/Swift I'll be hapy to give it another... go)
I think Rust has a bright future in the JS ecosystem as its already growing as both the underlying-platform-language of choice (Deno), the main compile-to-WASM language as well as the lower-level tooling language (SWC, Turborepo server, Parcel components etc). In the last space Go is also popular but I predict ultimately Rust will win because of the other factors.
Purely as a language, Go is worse than TypeScript by a lot (yes, even with generics), yet has a really well made standard library that more than makes up for it in many regards, and tooling thats similarly much better and pleasant to work with.
If you're looking to learn more about systems programming as well as a bunch of advanced PL features that make development a joy, go for Rust. Besides being an excellent language, the library ecosystem and tooling are really well made as well (great documentation culture, tools work predictably and cover both simple and complex / larger use cases e.g. monorepos, etc.)
I've decided to learn Rust. I had some small amount of hobbyist C++ development experience before, and the learning curve isn't as bad as it looks, and its definitely better than something like Haskell due to the excellent documentation resources. It took a couple of weeks, about 1h-2h per day to get past the initial "wall-like" learning curve for borrowing and ownership (its important to preserve during this period)
I've refused to get into Golang as a matter of principle for a long time. I saw the language as a step backwards that deliberately ignores a lot of things we've learned in the past few decades in the name of "simplicity". While I acknowledge that the ecosystem as a whole is powerful, I'd like a tool that doesn't deliberately limit me without giving anything in return (lack of algebraic data types means reduced safety and more bugs due to inability to make illegal states unrepresentable, for example), all while trying to paint that as some kind of benefit. However, I reserve the right to change my mind if the right opportunities present themselves (also, given that they fixed generics, once error handling is made closer to Rust/Swift I'll be hapy to give it another... go)
I think Rust has a bright future in the JS ecosystem as its already growing as both the underlying-platform-language of choice (Deno), the main compile-to-WASM language as well as the lower-level tooling language (SWC, Turborepo server, Parcel components etc). In the last space Go is also popular but I predict ultimately Rust will win because of the other factors.
Hot take: Learning languages doesn't make you a better programmer. Solving real world problems makes you a better programmer. Whether you do that in Rust, Go, or Shellscript is a lot less important. Perhaps find a book or a series of talks about a topic you've struggled with in the past, say, maintainability, and see how you could do better in that area. Or learn more about the domain of your customers so that you understand their requirements better.
For the typical developer familiar with one or more C-style languages (Java, Ruby, JavaScript, Python, C, C++, Go, shell scripts, that kind of thing) and not much more, learning Rust will make you a better programmer, because it makes various kinds of sloppiness harder or impossible and forces you to be more careful about things like shared mutability, in a way that does transfer to your style in other languages, so that you’re much less likely to perpetrate various kinds of errors, among other improvements.
Source: myself and literally every other person that I’ve talked to about the matter.
Source: myself and literally every other person that I’ve talked to about the matter.
Languages that change the way you think about expressing algorithms (e.g., Forth, Haskell, Lisp, Prolog, Smalltalk) are worth learning. Others are just reskins of languages you probably already know.
Here's a different take on the question based on my own experience. I learned Go from the online "Tour of Go"[0]. It was easy to read and learn with the interactive presentation. I came from a C/C++/Java background so the interesting things were all around concurrency (goroutines/channels), value types and struct layout, and the use of structural vs nominal interfaces. I'm glad I learned Go and use it for many small personal projects and on occasion at my day job.
I've dabbled with lots of different programming languages/paradigms to learn what's out there that I haven't been exposed to. A sweet spot of my interests is around F# or OCaml. Pony looks like an ultimate language of a sort that includes Rust and Clean. I've also wanted to have a reason to learn and use Rust. Much like I appreciate static typing, I could immediately appreciate Rust's different reference semantics to make safe and correct concurrent software with higher performance than is possible with Go.
But this is where I have to decide where to spend my time. I have a vague idea of the strong areas of Rust. I don't currently work in areas where those are prominent needs. I could justify it for any kind of low-level project I could come up with. Until I have that itch, it's on the back-burner as I don't consider learning Rust for the sake of learning Rust and its reference rules a big benefit to me. I can still spend most of my available time getting better at conceptualizing, shaping, and implementing monolithic APIs and distributed systems which isn't exactly tied to a particular language.
[0] https://go.dev/tour/welcome/1
I've dabbled with lots of different programming languages/paradigms to learn what's out there that I haven't been exposed to. A sweet spot of my interests is around F# or OCaml. Pony looks like an ultimate language of a sort that includes Rust and Clean. I've also wanted to have a reason to learn and use Rust. Much like I appreciate static typing, I could immediately appreciate Rust's different reference semantics to make safe and correct concurrent software with higher performance than is possible with Go.
But this is where I have to decide where to spend my time. I have a vague idea of the strong areas of Rust. I don't currently work in areas where those are prominent needs. I could justify it for any kind of low-level project I could come up with. Until I have that itch, it's on the back-burner as I don't consider learning Rust for the sake of learning Rust and its reference rules a big benefit to me. I can still spend most of my available time getting better at conceptualizing, shaping, and implementing monolithic APIs and distributed systems which isn't exactly tied to a particular language.
[0] https://go.dev/tour/welcome/1
Adding for context: I don’t have a degree/background in CS. I majored in Math back in college and learned Python followed by a js bootcamp. I’m now years beyond that and have developed what I’d deem is enough of an understanding of CS fundamentals to the point that I can comfortably speak about/implement most things in the leetcode/technical interview space.
My college didn’t have cs and I definitely feel like I missed out on learning about some really interesting things and now have an understanding that can only go so deep across the stack.
Based on this, let me know if you think rust is the better choice, or if you have any other thoughts as to how might be good to spend my time e.g. maybe I’m just in the wrong space entirely and should be reading a book on Postgres… I love learning new stuff, but I sometimes find that I don’t invest my time in the wisest thing at a given moment. After thinking on the replies, I am now supplementing this post with a request for whatever you think would help someone like me
My college didn’t have cs and I definitely feel like I missed out on learning about some really interesting things and now have an understanding that can only go so deep across the stack.
Based on this, let me know if you think rust is the better choice, or if you have any other thoughts as to how might be good to spend my time e.g. maybe I’m just in the wrong space entirely and should be reading a book on Postgres… I love learning new stuff, but I sometimes find that I don’t invest my time in the wisest thing at a given moment. After thinking on the replies, I am now supplementing this post with a request for whatever you think would help someone like me
My degree is in Applied Math & Computer Science, at an engineering school, but the CS aspect was rather lame and the applied math part was basically useless for computers. But I got the piece of paper, which was my main goal. So like you, I've taught myself pretty much everything I know about computers.
You mentioned reading a book on Postgres. If you don't know SQL, I'd recommend learning that, either with Postgres or maybe more simply with SQLite. Whatever you pick as a toy project, make sure it has lots of data to help you understand indexes. With small data, everything will be fast. With large data, like a few million rows, you have to become very familiar with how the database actually executes queries so you can add the correct indexes to make things run fast. And you can't just add indexes for every query, because that slows down inserts and updates; there's a trade-off there that you'll have to balance.
You mentioned reading a book on Postgres. If you don't know SQL, I'd recommend learning that, either with Postgres or maybe more simply with SQLite. Whatever you pick as a toy project, make sure it has lots of data to help you understand indexes. With small data, everything will be fast. With large data, like a few million rows, you have to become very familiar with how the database actually executes queries so you can add the correct indexes to make things run fast. And you can't just add indexes for every query, because that slows down inserts and updates; there's a trade-off there that you'll have to balance.
Speaking for myself: For someone who didn't have a software engineering background (for the last decade I was mainly doing offensive Security stuff) probably the main choice would be Python. However, at some point I've felt in love with statically typed languages: The compiler became my biggest friend and I learned about the benefits of having "contracts" (in form of interfaces, strict parameter types for methods etc.) between (software) components.
That's why I've spent the last years learning Go. It taught me how to design bigger projects and how to tackle architectural problems in an easy/comprehensive way. I didn't try Rust yet because I didn't have to. I mainly code software/tools to work in cloud environments and HTTP/gRPC technologies. Under these circumstances Golang performs quite well.
For me it's true that Go "is better for getting things done": You'll get one statically linked binary that can be executed almost everywhere (without further dependencies). I'm a big fan of serverless and I wrote simple applications that currently run in AWS Lambda and Netlify (they also used Lambda under the hood). And more recently I got into web development where Golang is again my main choice (at least for the backend part). For frontend I would rather go for VueJS/React. And that's one reason why I've started to learn TypeScript.
I don't have that much experience in TS but I guess I could easily replace Golang by TS to do simple things (HTTP requests, JSON parsing etc.), especially in a Serverless environment.
While my Golang journey was accompanied by this "Golang vs Rust" debate, I do plan to learn Rust as well. But as I've mentioned before, currently I don't have any needs to do so. My advice would be: Learn both (for backend) and some TypeScript (for frontend).
Just my 2 cents...
That's why I've spent the last years learning Go. It taught me how to design bigger projects and how to tackle architectural problems in an easy/comprehensive way. I didn't try Rust yet because I didn't have to. I mainly code software/tools to work in cloud environments and HTTP/gRPC technologies. Under these circumstances Golang performs quite well.
For me it's true that Go "is better for getting things done": You'll get one statically linked binary that can be executed almost everywhere (without further dependencies). I'm a big fan of serverless and I wrote simple applications that currently run in AWS Lambda and Netlify (they also used Lambda under the hood). And more recently I got into web development where Golang is again my main choice (at least for the backend part). For frontend I would rather go for VueJS/React. And that's one reason why I've started to learn TypeScript.
I don't have that much experience in TS but I guess I could easily replace Golang by TS to do simple things (HTTP requests, JSON parsing etc.), especially in a Serverless environment.
While my Golang journey was accompanied by this "Golang vs Rust" debate, I do plan to learn Rust as well. But as I've mentioned before, currently I don't have any needs to do so. My advice would be: Learn both (for backend) and some TypeScript (for frontend).
Just my 2 cents...
Thanks! Interesting to hear from someone who started with Go and transitioned to TS
Rust will be in the kernel shortly so it'll have longevity with that. Not that I'm saying GO won't but kernel inclusion suggest permanent support.
If your goal is to become a "better" coder, doubling down on understanding the fundamentals rather than the specifics of a given language seems like an approach to consider.
That said, others here have recommended C instead or in addition to Rust or Go; this makes sense to me.
C is actively used and remains the lingua franca of low/system level programs (for the time being.) I'd also say that its relatively simple syntax and closeness to the underlying representation have a lot going for it (at least what you'd imagine the underlying assembly representation to be - hardware and clever compilers are doing a lot.)
The C language is simple, more than either Rust or Go, and can be picked up quickly, in my view. But actually understanding and using it competently is an altogether different matter.
Additionally, an absolute wealth of books introducing OS, drivers, and system and network programming topics using C exist. Projects like Xv6, Minix, and even Linux provide for code bases to run through and explore
- Computer Systems: A Programmer's Perspective [0]
- The Linux Programming Interface [1]
- Advanced Programming in the UNIX Environment [2]
- Dive into Systems [3]
And the list goes on and on.
You'll likely never write production code or push production projects in C (one hopes), but it seems to me that it remains a very useful language to be able to work with and to understand.
[0] https://www.amazon.com/Computer-Systems-Programmers-Perspect...
[1] https://www.amazon.com/Linux-Programming-Interface-System-Ha...
[2] https://www.amazon.com/Programming-Environment-Addison-Wesle...
[3] https://diveintosystems.org
That said, others here have recommended C instead or in addition to Rust or Go; this makes sense to me.
C is actively used and remains the lingua franca of low/system level programs (for the time being.) I'd also say that its relatively simple syntax and closeness to the underlying representation have a lot going for it (at least what you'd imagine the underlying assembly representation to be - hardware and clever compilers are doing a lot.)
The C language is simple, more than either Rust or Go, and can be picked up quickly, in my view. But actually understanding and using it competently is an altogether different matter.
Additionally, an absolute wealth of books introducing OS, drivers, and system and network programming topics using C exist. Projects like Xv6, Minix, and even Linux provide for code bases to run through and explore
- Computer Systems: A Programmer's Perspective [0]
- The Linux Programming Interface [1]
- Advanced Programming in the UNIX Environment [2]
- Dive into Systems [3]
And the list goes on and on.
You'll likely never write production code or push production projects in C (one hopes), but it seems to me that it remains a very useful language to be able to work with and to understand.
[0] https://www.amazon.com/Computer-Systems-Programmers-Perspect...
[1] https://www.amazon.com/Linux-Programming-Interface-System-Ha...
[2] https://www.amazon.com/Programming-Environment-Addison-Wesle...
[3] https://diveintosystems.org
Learn both. Go takes about 10minutes to write code in, a week to figure out harder stuff. Rust takes a few weeks. Both are good to know and fun to learn
I agree with the other poster saying that learning programming languages doesn’t make you a better coder, just as learning natural languages doesn’t make you a better communicator.
It’s much more efficient to pick a flexible programming language which allows using various concepts (functional, OO, etc) and constructs and then apply it in various domains which exercise those concepts/constructs.
Coding can also be learned. Code complete (2nd) is one of the few books focusing on this area - the author calls it construction - and goes into detail about building functions, parameter passing and so on and so forth.
Another interesting book I read was Martin Reddy’s - API design for C++. You could try finding something similar for your chosen language.
Finally there’s a couple of books by Pete Goodliffe which are language-independent: Code Craft and Becoming a Better Programmer. Naming, comments, error handling - there’s tons of stuff in there.
Now onto the topic of Rust and Go - I’ve recently learned both and am about average skills-wise. Go’s easy (the book Efficient Go covers it) and has many sweet spots like network, cmdline tools, heavy concurrency services. Rust is complicated but you can see that it’s a heavy duty language that you can use almost everywhere. Neither made me a better programmer, because I was familiar with most of the concepts they provided. And the new stuff doesn’t improve ones skills, it’s just tooling.
It’s much more efficient to pick a flexible programming language which allows using various concepts (functional, OO, etc) and constructs and then apply it in various domains which exercise those concepts/constructs.
Coding can also be learned. Code complete (2nd) is one of the few books focusing on this area - the author calls it construction - and goes into detail about building functions, parameter passing and so on and so forth.
Another interesting book I read was Martin Reddy’s - API design for C++. You could try finding something similar for your chosen language.
Finally there’s a couple of books by Pete Goodliffe which are language-independent: Code Craft and Becoming a Better Programmer. Naming, comments, error handling - there’s tons of stuff in there.
Now onto the topic of Rust and Go - I’ve recently learned both and am about average skills-wise. Go’s easy (the book Efficient Go covers it) and has many sweet spots like network, cmdline tools, heavy concurrency services. Rust is complicated but you can see that it’s a heavy duty language that you can use almost everywhere. Neither made me a better programmer, because I was familiar with most of the concepts they provided. And the new stuff doesn’t improve ones skills, it’s just tooling.
Code complete has been on my list for a while and this definitely bumps it up that list! I like your recommendation about finding a book on subject area in particular. Thanks!
Disclaimer: I have no TypeScript experience. I'd say poking at both languages is useful. The choice of ecosystem can come later, according to the taste and tasks.
Rust:
- makes you a better coder indeed, Rust is pretty clear and organized about its abstractions. Sum types, honest traits, no nil values, disciplined approach to errors and generics, the right amount of niceties and syntax sugar. The idea of borrow checking (and when to avoid it) is a valuable insight into programming in itself. Straightforward RAII instead of wanton `defer`s everywhere.
- fearless concurrency (no global mutable variables, Arc, Send + Sync, ownership of objects by threads) with reliability heads and shoulders higher than everything else.
- first-class support for WebAssembly (wasm-bindgen, js-sys, wasm-pack, etc). Interfaces with other languages well (PyO3, Node bindings, C/C++ via bindgen/cbindgen).
- fine-grained, low-level control over memory allocations and layouts.
- requires quite a bit of effort and dedication to use it effectively. The standard library is extensive in volume (not functionality), takes time to learn, has its own conventions and context-dependent, non-straightforward idioms.
Golang:
- a language to get things done, with very decent and extensive ecosystem.
- a perfect choice for backend servers, microservices, everything working over the network.
- teaches about perils of freely mixing shared memory with concurrency. Goroutines are so easy to spawn, until they are not. Channels seem like a good idea, until dive into a real code base with mutexes and shared memory. Still, both goroutines and channels are solid, practical tools that work well.
- writing new code is objectively faster and easier with GC.
- compared to TypeScript, still teaches to manage memory layouts and has structs as values.
- doing pretty basic things like iterators, sum types, custom data structures, even tuples of values can be painful, but this is changing with the newly introduced generics.
- I still try to come to terms with the wild abuse of programming language theory terms in Go, where an "interface" is not just a trait, but also a set of types and behaves almost like a supertype.
Rust:
- makes you a better coder indeed, Rust is pretty clear and organized about its abstractions. Sum types, honest traits, no nil values, disciplined approach to errors and generics, the right amount of niceties and syntax sugar. The idea of borrow checking (and when to avoid it) is a valuable insight into programming in itself. Straightforward RAII instead of wanton `defer`s everywhere.
- fearless concurrency (no global mutable variables, Arc, Send + Sync, ownership of objects by threads) with reliability heads and shoulders higher than everything else.
- first-class support for WebAssembly (wasm-bindgen, js-sys, wasm-pack, etc). Interfaces with other languages well (PyO3, Node bindings, C/C++ via bindgen/cbindgen).
- fine-grained, low-level control over memory allocations and layouts.
- requires quite a bit of effort and dedication to use it effectively. The standard library is extensive in volume (not functionality), takes time to learn, has its own conventions and context-dependent, non-straightforward idioms.
Golang:
- a language to get things done, with very decent and extensive ecosystem.
- a perfect choice for backend servers, microservices, everything working over the network.
- teaches about perils of freely mixing shared memory with concurrency. Goroutines are so easy to spawn, until they are not. Channels seem like a good idea, until dive into a real code base with mutexes and shared memory. Still, both goroutines and channels are solid, practical tools that work well.
- writing new code is objectively faster and easier with GC.
- compared to TypeScript, still teaches to manage memory layouts and has structs as values.
- doing pretty basic things like iterators, sum types, custom data structures, even tuples of values can be painful, but this is changing with the newly introduced generics.
- I still try to come to terms with the wild abuse of programming language theory terms in Go, where an "interface" is not just a trait, but also a set of types and behaves almost like a supertype.
Depends on what do you mean by being a better coder. My take on what you can gain from learning each of these languages:
Go - concurrency with channels (that's a big one, gives you a good tool to think about concurrency even outside Go), appreciation of language minimalism
Rust - what it takes to have memory safety without garbage collector
Speaking of mental tools for dealing with concurrency I recommend looking at Clojure with its concurrency based on software transactional memory and immutability.
Go - concurrency with channels (that's a big one, gives you a good tool to think about concurrency even outside Go), appreciation of language minimalism
Rust - what it takes to have memory safety without garbage collector
Speaking of mental tools for dealing with concurrency I recommend looking at Clojure with its concurrency based on software transactional memory and immutability.
Good recommendations in the thread.
I would ask myself: what would I expect to be building with Go or Rust? Of course, you can build anything with Go or Rust --or any turing-complete programming language for that matter. But *I believe* Rust programmers will be working mostly on foundational software --think caches, databases, compilers... while Go developers will mostly work building microservices and related tooling, stuff a little more business oriented.
I would ask myself: what would I expect to be building with Go or Rust? Of course, you can build anything with Go or Rust --or any turing-complete programming language for that matter. But *I believe* Rust programmers will be working mostly on foundational software --think caches, databases, compilers... while Go developers will mostly work building microservices and related tooling, stuff a little more business oriented.
I recently had to look into Go for an interview and the question you just made it's on a lot of people's minds however I'd say Go and Rust have different user cases so the answer, like always, it depends.
I'm unfamiliar with Rust, so I'm mostly going to address the little I know about Go. It's a great language if you want low memory consumption, concurrency and a fairly simple codebase - the language is minimalistic and C-like so it tries to shove complexity away. I'm someone who hasn't touched anything with pointers in ages and really loved it. Docker, Kubernetes, Terraform and from what I've heard a lot of Google services are being developed in Go, think about what they have in common and if you have a similar use case or you specialize in backend and devops then GO for it.
However people are reporting that Rust is coming to the Linux kernel soon so it seems like a solid choice no matter what you pick.
I think I have a similar background to you and learning Go definitely made me a better programmer and it barely took any time.
(Self promotion ahead, skip to last paragraph) I even made an article[1] that's an introduction to Go where I talk about everything that seemed interesting to me and I follow up with a small project, it's meant for junior to mid level developers that want to start with Go or are undecided. Perhaps have a quick look (it's been well received and featured in Hashnode).
Overall I'd highly recommend learning Go, it was a breath of fresh air for me after working mostly with Node and Spring Boot. If I had to make a backend system, depending on the requirements, Go would definitely be a top choice for me.
---
[1]https://bognov.tech/introduction-to-golang-build-a-mini-twit...
I'm unfamiliar with Rust, so I'm mostly going to address the little I know about Go. It's a great language if you want low memory consumption, concurrency and a fairly simple codebase - the language is minimalistic and C-like so it tries to shove complexity away. I'm someone who hasn't touched anything with pointers in ages and really loved it. Docker, Kubernetes, Terraform and from what I've heard a lot of Google services are being developed in Go, think about what they have in common and if you have a similar use case or you specialize in backend and devops then GO for it.
However people are reporting that Rust is coming to the Linux kernel soon so it seems like a solid choice no matter what you pick.
I think I have a similar background to you and learning Go definitely made me a better programmer and it barely took any time.
(Self promotion ahead, skip to last paragraph) I even made an article[1] that's an introduction to Go where I talk about everything that seemed interesting to me and I follow up with a small project, it's meant for junior to mid level developers that want to start with Go or are undecided. Perhaps have a quick look (it's been well received and featured in Hashnode).
Overall I'd highly recommend learning Go, it was a breath of fresh air for me after working mostly with Node and Spring Boot. If I had to make a backend system, depending on the requirements, Go would definitely be a top choice for me.
---
[1]https://bognov.tech/introduction-to-golang-build-a-mini-twit...
Given where you are now I'd learn Go. Go is a language born from the cloud. It solves modern-day problems featuring several networked machines with each having several processors. It's probably going to be the most useful language to you because it allows you to build systems solutions spanning several networked machines. Go is also an easier language to come up to speed with than Rust.
I see Rust as a replacement for C/C++. It's for system programming on a single machine. Its claim to fame is having memory safety - it's a modern language. If you're wanting to build a more traditional app running on a single machine - use Rust.
I see Rust as a replacement for C/C++. It's for system programming on a single machine. Its claim to fame is having memory safety - it's a modern language. If you're wanting to build a more traditional app running on a single machine - use Rust.
I write JS 99.9% of the time.
I would definitely pick Rust as it is more different than JS.
Yes, there is a higher learning curve. But it will broaden your perception on programming languages.
As an added bonus, rust is very popular to create WASM stuff. So you can apply it to the JS world.
Happy 4th
I would definitely pick Rust as it is more different than JS.
Yes, there is a higher learning curve. But it will broaden your perception on programming languages.
As an added bonus, rust is very popular to create WASM stuff. So you can apply it to the JS world.
Happy 4th
If it's for learning choose Rust. Go has not much to teach you since it's such a basic language. Actually I would also choose Rust for getting things done. It just takes longer to master.
Why are these two languages chosen? I would suggest thinking of a niche you want to fulfill - you mentioned web servers, for that use case Go is fair, but do note that Go is a managed language much closer to JS than to Rust. There is probably not even that many new concepts in Go compared to TS (both use the otherwise rare structural typing).
If you want to instead learn about low-level programming, Rust is a great choice, but so is C for some basic concepts.
If you want to instead learn about low-level programming, Rust is a great choice, but so is C for some basic concepts.
I think if you're in the front end world and likely to do more full stack work go is perfect for this, so its likely to lead to jobs in the next year or so.
Rust I like it but worry it hasn't really taken off as I expected. C++ seems resurgent. The C++ world is vast, perhaps you'll learn more with that and the skills will be more useful. Either C++ or Rust dont get used in full stack though so it really is a different world.
Rust I like it but worry it hasn't really taken off as I expected. C++ seems resurgent. The C++ world is vast, perhaps you'll learn more with that and the skills will be more useful. Either C++ or Rust dont get used in full stack though so it really is a different world.
Something that I'm very much interested in, too!
Tangential & important/useful to this question is:
"Ask HN: Great visual or other breakdowns of PL's & their categories/sub-c's?"
https://news.ycombinator.com/item?id=31919255
Posted over 5 days ago, sadly, there was zero responses.
Should I try reposting from scratch, or 1st w&s if this bump sparks things?
Ty
Tangential & important/useful to this question is:
"Ask HN: Great visual or other breakdowns of PL's & their categories/sub-c's?"
https://news.ycombinator.com/item?id=31919255
Posted over 5 days ago, sadly, there was zero responses.
Should I try reposting from scratch, or 1st w&s if this bump sparks things?
Ty
More Rust than Go experience. Both aren't perfect to me. I fight the borrow checker too much in Rust and everyone tells me to use Arc<> which is ugly. Go has a nice GC. Rust is a richer language than Go, Go is much simplier. Rust has a much nicer build system (rustup, cargo, ...). Go is fantastically fast when compiling. Go has currently the best async execution runtime with IO parking.
> I’d like to learn whichever language will make me a “better” coder in the long term.
Install every compilers available under the sun and learn the bases of every language. Then dig deeper in each in what is idiomatic and why.
From prolog, to arc, don't limit yourself to the mainstream languages. You won't be able to eventually avoid them anyway. Some day, Java happens.
Install every compilers available under the sun and learn the bases of every language. Then dig deeper in each in what is idiomatic and why.
From prolog, to arc, don't limit yourself to the mainstream languages. You won't be able to eventually avoid them anyway. Some day, Java happens.
If you look to glue systems and add some new code at system level (not confuse it with OS level), the Golang is a better option. E.g. microservices, talk to databases, implement some distributed algorithm in your code.
Now if you plan to do number crunching, low level algorithm or scientific computing, Rust by all means. Unless you glue algos, then Python or Julia
Now if you plan to do number crunching, low level algorithm or scientific computing, Rust by all means. Unless you glue algos, then Python or Julia
Learn Crystal https://crystal-lang.org/
If you want to improve your code skills I think Rust is the best way and also you could help to the linux kernel now ^^
If you are looking to do async apps I'd recommend avoid Rust in the short term (the ecosystem about async in Rust is a mess at the moment, hopefully in a few years is in a better position and probably in the core)
If you are looking to do async apps I'd recommend avoid Rust in the short term (the ecosystem about async in Rust is a mess at the moment, hopefully in a few years is in a better position and probably in the core)
I'd go with C first. Rust would teach you everything C does and more, but C will lay the foundation in cleaner strokes. This will help you later no matter what language you decide to learn next. C is also in a way the language of the FFI, so you are very likely to need it in the future regardless.
Had a feeling a reply like this was coming. Could you help me understand a bit more about why C would be a better place to start and how it’d lead to me growing my skills in core areas vs something like Rust or C++? I hear about C++ and can’t wrap my head around the benefits of going with something like C that has less features. I recognize I’m asking what will help me grow/learn and am saying, “why use this if x has more niceties?” but hopefully you can humor me. One thing I hear a lot is that Rust is the language for the next few decades, and while I’m sure C isn’t going anywhere, I’d be very curious to hear from someone with more experience about why C would be the way to go here. I’ll admit I’m intrigued as I used to have a professor in college who was a wizard and did everything in C — especially since a game I like from 2001 has an active modding community so long as you know C/ASM.
Explicitly: I’d be curious to know what the “cleaner strokes” are.
I also have never even heard of an FFI so thanks for starting my next research binge! I always thought two langs could interact once they’re both compiled to machine code, but I’m guessing i took that for granted and that C does that heavy lifting..
Explicitly: I’d be curious to know what the “cleaner strokes” are.
I also have never even heard of an FFI so thanks for starting my next research binge! I always thought two langs could interact once they’re both compiled to machine code, but I’m guessing i took that for granted and that C does that heavy lifting..
To list something: C teaches memory management, memory addressing, stacks and heaps, some disassembly, binary interfaces. Basically, you see the layer on top of machine language. Python, Go, etc. are a layer on top of that.
Rust and C++ teach these things as well, but C keeps things minimal so you see the ideas more clearly. A lot of languages are written in C, forming a common way to think about implementation and problems, one you see glimpses of working in almost any other language as well. A lot of "why is it like this" questions have answers beginning "because in C..".
The FFI part is due to the extremely stable and simple ABI. Compiling C produces predictable and known binaries, setting a lowest common denominator among languages (for bettet or for worse). Thus knowing the capabilities and limitations of C is useful even when working with other languages.
A lot of this knowledge can be grasped quickly and you will get reminded of them for the rest of your programming life, so it's not necessary to dive deep into C to get the knowledge. C just provides the shortest and cleanest introduction, and you can quickly move forward without missing a beat really, since a lot of the stuff is so universal.
Rust and C++ teach these things as well, but C keeps things minimal so you see the ideas more clearly. A lot of languages are written in C, forming a common way to think about implementation and problems, one you see glimpses of working in almost any other language as well. A lot of "why is it like this" questions have answers beginning "because in C..".
The FFI part is due to the extremely stable and simple ABI. Compiling C produces predictable and known binaries, setting a lowest common denominator among languages (for bettet or for worse). Thus knowing the capabilities and limitations of C is useful even when working with other languages.
A lot of this knowledge can be grasped quickly and you will get reminded of them for the rest of your programming life, so it's not necessary to dive deep into C to get the knowledge. C just provides the shortest and cleanest introduction, and you can quickly move forward without missing a beat really, since a lot of the stuff is so universal.
Thanks for the additional info! Very helpful and I appreciate it greatly.
Learn go. It’s much more widely adopted with very significant open source projects written with it.
You will become productive very quickly and it will help you make better use of multi core processors.
Go just introduced generics which was holding back quite a few people from trying it. Now it’s the time.
You will become productive very quickly and it will help you make better use of multi core processors.
Go just introduced generics which was holding back quite a few people from trying it. Now it’s the time.
I personally enjoy Rust more than Go, but if you’re considering the career angle then Go has a huge advantage of more jobs.
Rust has a steep learning curve, like you said, which is one reason why it won’t be nearly as common as Go in the workplace.
Rust has a steep learning curve, like you said, which is one reason why it won’t be nearly as common as Go in the workplace.
Learn both. Go in particular is quite simple. Rust will take a bit more time.
Why no start with C? Then perhaps check C++ and Rust?
If you want to understand internals of programming languages then Go isn’t a great choice because it abstracts away so much stuff.
If you want to understand internals of programming languages then Go isn’t a great choice because it abstracts away so much stuff.
The advantage of rust is that it protects you from common errors in c.
if i had to choose between c and rust as someone who likes go, i always would choose rust.
Without any prior knowledge of C you wouldn't really understand what problems Rust solves for you. Especially when never having worked with any lang without automatic garbage collection.
A quick dive into C is a good idea for learning. It is hugely influential and basically the Latin of programming languages so any knowledge pays huge dividends down the road even if you never use it directly.
Whether you should use C was not the question. There are valid uses though even for new projects and if just for the few exotic targets that Rust doesn't yet compile to.
A quick dive into C is a good idea for learning. It is hugely influential and basically the Latin of programming languages so any knowledge pays huge dividends down the road even if you never use it directly.
Whether you should use C was not the question. There are valid uses though even for new projects and if just for the few exotic targets that Rust doesn't yet compile to.
Well, I'd much rather maintain an application written in Rust or Go, than written in C.
But for gaining understanding, I think because C is so 'raw', I think that makes it useful for developing further understanding as a programmer.
But for gaining understanding, I think because C is so 'raw', I think that makes it useful for developing further understanding as a programmer.
I think there has to be an good reason for starting an project in c, like an special platform that isn't implemented in rust. If you need to fiddle with unsafe memory you can still use unsafe in rust.
If you really want to understand how programming languages work internally, you should look at assembly language or possibly at the bytecode interpreters of some scripting languages.
C is still fairly high-level.
C is still fairly high-level.
The definition of "low level" keeps changing over time. :p
At this rate, Python will be called "low level" 50 years from now.
But to the OP: Rust is just "C for the 21st century" (despite people often calling Go that). The UX is stellar -- `cargo run` can't be beat, integrated unit testing, safety concepts learned in the last few decades are applied by default, and the docs are great[0]. I don't think there's any reason to learn C first, especially if you're coming from a "high level" background like TypeScript, other than experiencing culture shock and legacy braindeath horror.
0: https://doc.rust-lang.org/stable/book/title-page.html
At this rate, Python will be called "low level" 50 years from now.
But to the OP: Rust is just "C for the 21st century" (despite people often calling Go that). The UX is stellar -- `cargo run` can't be beat, integrated unit testing, safety concepts learned in the last few decades are applied by default, and the docs are great[0]. I don't think there's any reason to learn C first, especially if you're coming from a "high level" background like TypeScript, other than experiencing culture shock and legacy braindeath horror.
0: https://doc.rust-lang.org/stable/book/title-page.html
Yeaaaa hearing c called high level makes me wonder what word would even describe the js/ts/Python I’m familiar with…
Either or both would be fine. They're both "proper" programming languages today. golang is the F-150 pickup truck of languages, while Rust is more on the V10 Lamborghini end of the spectrum. More difficult to work with, life is more exciting.
golang has essentially no nonsense in it (due to guardianship by crusty old men at Google). No async ever happening there, thankfully.
Rust, lacking a single corporate backer, has more evolutionary churn and a bit less pure focus of vision imho (concurrency implementation changed several times, it now does have async even though there's no need for it).
golang has essentially no nonsense in it (due to guardianship by crusty old men at Google). No async ever happening there, thankfully.
Rust, lacking a single corporate backer, has more evolutionary churn and a bit less pure focus of vision imho (concurrency implementation changed several times, it now does have async even though there's no need for it).
start with go for employment opportunities then learn rust. if employment isn't a driving concern here, both are great languages.
Doing a few projects in Go will make you a better programmer in general, a it forces you to write simpler, more comprehendible code.
I think it depends on your goals.
Do you want a job in the short-term? Choose Go.
Do you want a job in the long-term? Choose Rust.
Do you want a job in the short-term? Choose Go.
Do you want a job in the long-term? Choose Rust.
But what if you already have a job?
If you already have a job and you don't want a new job neither on the short-term or long-term, you could:
- choose Go because: - it is easy to learn - it is fun - it is productive - it has good performance - it has good maintainability
Or you can:
- choose Rust if: - you have the time to learn the ins and outs - you have time to keep up with the never ending new features - you have interest in write software that is usually written in C or C++
What you need to have in mind is that both languages have benefits and trade-offs.
Go for example is easy to learn because is a small language but because of that you will need to write more code. Modern developers are usually averse to write lots of code. But write the amount of code that Go requires you to write will make you think better about what you are writing and at the end this will make you a better developer.
Rust takes time to learn and features keep bubbling up from time to time and some times development with Rust can be slow compared to other languages, but it is an excellent replacement for C or C++ if you are writing software for a supported architecture, because you will have the C/C++ performance without lots of bugs related to manual memory management.
Another thing to keep in mind is not to use Go or Rust when you should not use them. For example, you will see a lot of people using Rust for the sake of using Rust just because Rust is "memory safe", but Go is "memory safe" too; the difference is Go is garbage collected and Rust is not.
If you can afford a garbage collector in the software you are writing, don't waste your time with Rust if the software domain is one that Go excels, like networking programming.
But don't use Go for the sake of using Go as many people do, for example, trying to replace C or C++ with Go, because Go is not a replacement for C and C++.
- choose Go because: - it is easy to learn - it is fun - it is productive - it has good performance - it has good maintainability
Or you can:
- choose Rust if: - you have the time to learn the ins and outs - you have time to keep up with the never ending new features - you have interest in write software that is usually written in C or C++
What you need to have in mind is that both languages have benefits and trade-offs.
Go for example is easy to learn because is a small language but because of that you will need to write more code. Modern developers are usually averse to write lots of code. But write the amount of code that Go requires you to write will make you think better about what you are writing and at the end this will make you a better developer.
Rust takes time to learn and features keep bubbling up from time to time and some times development with Rust can be slow compared to other languages, but it is an excellent replacement for C or C++ if you are writing software for a supported architecture, because you will have the C/C++ performance without lots of bugs related to manual memory management.
Another thing to keep in mind is not to use Go or Rust when you should not use them. For example, you will see a lot of people using Rust for the sake of using Rust just because Rust is "memory safe", but Go is "memory safe" too; the difference is Go is garbage collected and Rust is not.
If you can afford a garbage collector in the software you are writing, don't waste your time with Rust if the software domain is one that Go excels, like networking programming.
But don't use Go for the sake of using Go as many people do, for example, trying to replace C or C++ with Go, because Go is not a replacement for C and C++.
for what type of application are rust and go used nowadays?
I know ruby has ruby on rails,
python has django, panda, torch, keras and tensorflow,
typescript/javascript has vue and react and express and etc.
I know ruby has ruby on rails,
python has django, panda, torch, keras and tensorflow,
typescript/javascript has vue and react and express and etc.
Try both and pick the one you like the most
Learn Scala.
This kind of question is the reason why you'll never be good a good developer
> I am a full stack TypeScript dev looking to broaden my skill set by learning a new language. I’ve been weighing Rust vs Go for a long time but can’t really decide which would be a better use of my time. I often hear that people who try one of these languages after coming from something like TypeScript feel that they really level up their abilities/understanding.
I don't know if that's a joke or just misinformation
> I am a full stack TypeScript dev looking to broaden my skill set by learning a new language. I’ve been weighing Rust vs Go for a long time but can’t really decide which would be a better use of my time. I often hear that people who try one of these languages after coming from something like TypeScript feel that they really level up their abilities/understanding.
I don't know if that's a joke or just misinformation
Hey thanks for the reply. This was really insightful and I really appreciate you taking the time! The most helpful part was definitely where you tell me I’ll never be a good dev because I ask questions I don’t already have the answer to :)
I’d like to learn whichever language will make me a “better” coder in the long term. My understanding is that Rust would be the way to go here. However, I see that the Rust learning curve is significantly higher than Go’s, and that something like setting up a server in rust will take much longer than Go. It sounds like Go is better for “getting things done” but I’m wondering if I’m leaving growth/understanding on the table by going from one garbage collected language to another.
I am interested in hearing anyone’s thoughts on this matter. Especially if you have experience going from js/ts to one of these.
Thanks and happy 4th