From someone who hasn't learned/considered Go for any real project so far, would there be any benefits in going Go instead of Rust? Or learning Go instead of Rust?
The way I look at it, and I could totally be wrong, is if you go for a different language for your back-end than your front-end, it betters pay off big time. I find Go and Typescript to be in a very similar ballpark in term of productivity, but with Typescript having a huge advantage since you can reuse all the learning/tooling from the front-end.
Rust on the other hand really adds something to the table with the memory safety and zero-cost abstraction.
TL&DR: It feels like either you eat the bullet and go Rust for memory safety, or Typescript is a better choice. Of course I'm overly simplifying.
Go is a significantly simpler language than Rust, and has a garbage collector. You can learn Go in a weekend, and experiment with it in a couple more.
Rust on the other hand has a steep learning curve which will take at least a couple of months to get good at.
So if I were you, I'd start by learning Go, seeing if it fit my needs, and then learning Rust later on if I had a use case that Go wasn't a good fit for.
I’m not familiar with Rust’s tooling but i’m wondering whether the dev workflow involves explicit manual recompilation? Eg. in Haskell modern workflows are about conversing with the compiler real-time ie. make a type error and it is immediately pointed out and thus explicit recompilation is not part of it anymore. I’d be mildly surprised is something like this does not exists for Rust.
Rust is a compiled language, so you will have to recompile. Incremental compilation helps to a certain degree.
There is IDE tooling that helps with a lot of issues you may encounter, but in the end, you still have to recompile to run your code. Same applies to Go as well.
I have never find this a shortcoming of any language, but YMMV.
So is Haskell. What I'm saying is that in 2020 the dev workflow is not: code, compile, run, repeat. Thanks to modern tooling it is now a near-instant feedback loop of: code, red wiggly line(s), fix, repeat. Ie. real-time conversation with the compiler.
rust-analyzer brings this to the table, but it's a pretty recent development. The RLS existed for a while before that, and gave a basic version of this story, but it was much slower.
Languages are tools, so it depends on your problem.
Go shines when you have a lot of parallelism, and not a lot of concurrency (although sync package is fantastic). Web servers, data processing pipes, task queue consumers...
Also the language is simpler. Personally I think in it like C vs C++ or RISC vs CISC.
And last, but not least: Go have faster compilation times. Rust compilation is slow, and for some tasks that requires retrying (like learning a new language) compiling fast is very valuable.
decent points, I like TS too -- but commenting to help
w the idiom:
it's "bite the bullet" (ie, accept the pain and deiberately suffer through it now), not "eat the bullet" (commit suicide).
The way I look at it, and I could totally be wrong, is if you go for a different language for your back-end than your front-end, it betters pay off big time. I find Go and Typescript to be in a very similar ballpark in term of productivity, but with Typescript having a huge advantage since you can reuse all the learning/tooling from the front-end.
Rust on the other hand really adds something to the table with the memory safety and zero-cost abstraction.
TL&DR: It feels like either you eat the bullet and go Rust for memory safety, or Typescript is a better choice. Of course I'm overly simplifying.
Thoughts?