What parts of web development do you want to get involved in? And should your choice of language lead to more job opportunities?
Go is still pretty hyped and popular because it is very easy to learn and easy to get results with. Its concurrency model is far easier to understand than traditional thread-based ones and the ecosystem exploded some time ago, with so many great libs and frameworks nowadays.
I/O in Go is async by default without you mostly noting it, because the runtime takes care of it for you.
I've been programming for nearly 20 years now (with only a fraction of it being professionally) so the following may not apply to you, but it took me only one day to learn Go and write my first piece of software in it, without it failing horribly at runtime.
The only issue I ran into was its exotic handling of dependencies ($GOPATH, etc.), which got better with the introduction of gomodules and still improves, that gave me a hard time.
The number of jobs listed for Go is pretty decent currently (please note: highly depending on where you live).
Rust on the other hand is difficult to learn but very easy to use once you actually understand it and successfully fought the compiler and borrow checker until you became very close friends (but this will take you way more time than learning Go).
I believe that it took me two weeks before I was able to write simple programs without the compiler complaining too much. But boy, once something in Rust compiles, you can be pretty sure that it'll just work!
What differentiates Rust from Go is that there's no runtime (which takes care of certain things for you). Thus you have way more control over the actual outcome of what you do.
Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn, which comes in very handy, given, that you have to learn a lot of other concepts like borrowing, etc., you did not have to bother with while using memory managed languages.
Rust comes with Cargo, which, in contrast to Go's $GOPATH / gomodule system, is like heaven on earth. It makes handling of dependencies, building, etc. so easy and so much fun and doesn't get in your way.
Depending on where you live, the number of job postings that do not directly relate to blockchain may be far less than those for Go and this may limit your opportunities.
There's nothing one of these languages can achieve that the other doesn't, so no drawbacks there with either of them. Both can be used for pretty much anything. You can write REST-APIs with both, you could implement a new database, both compile to WASM, pretty much anything you could imagine.
That's only the tip of the iceberg but perhaps it helps you a little to decide.
I'd suggest:
Try out both, write a simple program, and then see what you have more fun with.
Forgot to mention one big thing and that is rust has no garbage collector like Go does. Not that it's bad just worth noting. Also I think wasmer is awesome either way you go; and checkout neon/yew/actix for rust or Gin for go and decide what you like. Rust gives you a lot more control but requires you to make more decisions and code. Try both go with what you like. Rust jobs will be there in the future. There are plenty of Go jobs now.
Omitted that on purpose. You are very right but the compiler takes care of allocating memory for you. And in 90% of use cases you will never need more than that, although Rust allows for manual memory management for those 10% of use cases you pretend to really know what you are doing. :-)
"Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn"
... then I really need to disagree! I have minimal experience with Rust (and Go), but having worked through most of the docs/tutorial, and subsequently having like a week (yes just a week) hands-on experience with a real-world codebase, what jumped out for me was this:
Rust has quite a strong Functional Programming (FP) feel to it - it often reminded me of Haskell which I dabbled in for a while; lots of emphasis on map/filter/reduce type of things, and declaring (abstract) data types.
This leads to Rust code tending to be much more "declarative" than Go code (which tends to be very much imperative, generic map/filter/reduce kind of code isn't even possible really for lack of a generic type system).
So, while I only have 'experience' with both Go and Rust on a "tutorial" and glorified "hello world" level, conceptually I was much more impressed with Rust as a programming language.
My feeling was that Go is very much "dumbed down" - especially the lack of generics sticks out like a sore thumb, because this forces you to write for loops ad infinitum ... the code you write tends to be very imperative. In that regard it sort of feels like a step back. Rust (at least that's my opinion) is a lot more elegant as a programming language.
On the other hand:
the Go compiler is insanely fast! Rust's compiler is s-l-o-w ...
Rust misses the biggest asset of Go which is the easy async/concurrency model
Employability: the number of Go jobs is probably an order of magnitude larger than the number of Rust jobs
On the other hand, the way Go manages its dependencies (with GOPATH and so on, and with its prescription of how you need to physically organize your files/directories) is indeed a bit "weird", but it didn't bother me really - if you stick to the conventions then it just works (again however, Rust's module system, while more complex, is a lot more elegant).
So, conceptually I'm much more impressed with Rust, but I acknowledge that Go might be more practical for "real world" purposes.
Now if Rust would acquire Go's concurrency features (Goroutines) and Go would get generic types, then the competition between the two would become really interesting!
These are only two examples, specifically tailored to your point of Rust's FP-style.
What I just want to showcase is: It's not that much new. If you got the concept somewhere else, you'll get it within Rust.
The same could be made up for variable declaration, and nearly everything else.
It's just a similar style. :-)
On Go being dumbed down:
Yes, absolutely.
IIRC, one reason for Rob Pike, Ken Thompson and Robert Griesemer to design Go the way it is, is, that Google faces some unique challenges.
They had to invest an enormous amount of money to get their C++ infrastructure right and they have to onboard a lot of new engineers very often. Concurrency, of course, is very difficult and so they wanted to create something very easy to understand and write working Software with. They also wanted to fight the enormous build times Google's C++ projects sometimes have.
Their intention was to create a language with the minimal feature set needed to accomplish a task at Google scale by negating the drawbacks they previously faced.
Rust's compiler gets faster and faster with every release, but for all the checks and safety features it comes with, there need to be some drawbacks.
It may not be that fancy as a go func... and then using channels and so on, but we're getting closer. :-)
Edit regarding the job situation:
I think we will have to give it a little more time. Let the ecosystem mature more and I'm, pretty sure that, as the community grows, job opportunities will also arise.
Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
What parts of web development do you want to get involved in? And should your choice of language lead to more job opportunities?
Go is still pretty hyped and popular because it is very easy to learn and easy to get results with. Its concurrency model is far easier to understand than traditional thread-based ones and the ecosystem exploded some time ago, with so many great libs and frameworks nowadays.
I/O in Go is async by default without you mostly noting it, because the runtime takes care of it for you.
I've been programming for nearly 20 years now (with only a fraction of it being professionally) so the following may not apply to you, but it took me only one day to learn Go and write my first piece of software in it, without it failing horribly at runtime.
The only issue I ran into was its exotic handling of dependencies ($GOPATH, etc.), which got better with the introduction of gomodules and still improves, that gave me a hard time.
The number of jobs listed for Go is pretty decent currently (please note: highly depending on where you live).
Rust on the other hand is difficult to learn but very easy to use once you actually understand it and successfully fought the compiler and borrow checker until you became very close friends (but this will take you way more time than learning Go).
I believe that it took me two weeks before I was able to write simple programs without the compiler complaining too much. But boy, once something in Rust compiles, you can be pretty sure that it'll just work!
What differentiates Rust from Go is that there's no runtime (which takes care of certain things for you). Thus you have way more control over the actual outcome of what you do.
Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn, which comes in very handy, given, that you have to learn a lot of other concepts like borrowing, etc., you did not have to bother with while using memory managed languages.
Rust comes with Cargo, which, in contrast to Go's $GOPATH / gomodule system, is like heaven on earth. It makes handling of dependencies, building, etc. so easy and so much fun and doesn't get in your way.
Depending on where you live, the number of job postings that do not directly relate to blockchain may be far less than those for Go and this may limit your opportunities.
There's nothing one of these languages can achieve that the other doesn't, so no drawbacks there with either of them. Both can be used for pretty much anything. You can write REST-APIs with both, you could implement a new database, both compile to WASM, pretty much anything you could imagine.
That's only the tip of the iceberg but perhaps it helps you a little to decide.
I'd suggest:
Try out both, write a simple program, and then see what you have more fun with.
Thank you so much, it was very clarifying post for me😊
I am not focused on finding a job. I want to learn for hobby and combine with my knowledge of front end.
It's really good to know that! I noted all of your highlights :)
I'm aware that learning curves with both Rust and Go. I will try both with sample project. Guess best way to decide it!
Great! Glad I could be of help. If there's anything you need more help with, drop me a message!
Yay! Thank you🤓
Forgot to mention one big thing and that is rust has no garbage collector like Go does. Not that it's bad just worth noting. Also I think wasmer is awesome either way you go; and checkout neon/yew/actix for rust or Gin for go and decide what you like. Rust gives you a lot more control but requires you to make more decisions and code. Try both go with what you like. Rust jobs will be there in the future. There are plenty of Go jobs now.
Omitted that on purpose. You are very right but the compiler takes care of allocating memory for you. And in 90% of use cases you will never need more than that, although Rust allows for manual memory management for those 10% of use cases you pretend to really know what you are doing. :-)
I only tried Rust a bit, but I love how (as you said) the compiler complains about anything.
It is harder to write bad code this way. I like this, especially because I use weak-typed languages (Python and Javascript) daily... :)
I agree. Most of my errors are through variable typing mistakes.
Good points, however when you say:
"Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn"
... then I really need to disagree! I have minimal experience with Rust (and Go), but having worked through most of the docs/tutorial, and subsequently having like a week (yes just a week) hands-on experience with a real-world codebase, what jumped out for me was this:
Rust has quite a strong Functional Programming (FP) feel to it - it often reminded me of Haskell which I dabbled in for a while; lots of emphasis on map/filter/reduce type of things, and declaring (abstract) data types.
This leads to Rust code tending to be much more "declarative" than Go code (which tends to be very much imperative, generic map/filter/reduce kind of code isn't even possible really for lack of a generic type system).
So, while I only have 'experience' with both Go and Rust on a "tutorial" and glorified "hello world" level, conceptually I was much more impressed with Rust as a programming language.
My feeling was that Go is very much "dumbed down" - especially the lack of generics sticks out like a sore thumb, because this forces you to write for loops ad infinitum ... the code you write tends to be very imperative. In that regard it sort of feels like a step back. Rust (at least that's my opinion) is a lot more elegant as a programming language.
On the other hand:
the Go compiler is insanely fast! Rust's compiler is s-l-o-w ...
Rust misses the biggest asset of Go which is the easy async/concurrency model
Employability: the number of Go jobs is probably an order of magnitude larger than the number of Rust jobs
On the other hand, the way Go manages its dependencies (with GOPATH and so on, and with its prescription of how you need to physically organize your files/directories) is indeed a bit "weird", but it didn't bother me really - if you stick to the conventions then it just works (again however, Rust's module system, while more complex, is a lot more elegant).
So, conceptually I'm much more impressed with Rust, but I acknowledge that Go might be more practical for "real world" purposes.
Now if Rust would acquire Go's concurrency features (Goroutines) and Go would get generic types, then the competition between the two would become really interesting!
Thank you really much for your reply!
Yes you are right, Rust has a heavy emphasis on FP-style.
But consider this two examples:
JS:
Java:
These are only two examples, specifically tailored to your point of Rust's FP-style.
What I just want to showcase is: It's not that much new. If you got the concept somewhere else, you'll get it within Rust.
The same could be made up for variable declaration, and nearly everything else.
It's just a similar style. :-)
On Go being dumbed down:
Yes, absolutely.
IIRC, one reason for Rob Pike, Ken Thompson and Robert Griesemer to design Go the way it is, is, that Google faces some unique challenges.
They had to invest an enormous amount of money to get their C++ infrastructure right and they have to onboard a lot of new engineers very often. Concurrency, of course, is very difficult and so they wanted to create something very easy to understand and write working Software with. They also wanted to fight the enormous build times Google's C++ projects sometimes have.
Their intention was to create a language with the minimal feature set needed to accomplish a task at Google scale by negating the drawbacks they previously faced.
Rust's compiler gets faster and faster with every release, but for all the checks and safety features it comes with, there need to be some drawbacks.
What do you think about the following?
It may not be that fancy as a
go func...and then using channels and so on, but we're getting closer. :-)Edit regarding the job situation:
I think we will have to give it a little more time. Let the ecosystem mature more and I'm, pretty sure that, as the community grows, job opportunities will also arise.
Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
How would you implement Go's "channels" in Rust?
Yea, our opinions seem to match there. :-)
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
Right, I see, yes that's what Rust doesn't have, Go's runtime ... so that means it would be hard to implement it in exactly the same way.
Some "history" on Reddit (reddit.com/r/rust/comments/a6f85e/...
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Yes, exactly. :-)
One more thing I actually forgot about and which may actually help and is more native than using something like Rx: Rust channels
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
Yep, no green threads for Rust. Those channels are indeed thread backed. :-)