Ash HN: Go or Rust for JavaScript developer in the next 20 years?

[nfgoto]

Time is limited.

As a back-end developer building cloud microservices / serverless, what would you invest time in mastering for the next 20 years.

Is it worth mastering both Go and Rust in the next 20 years on top of JavaScript / TypeScript ?

Also, what's your opinion on just focusing on mastering JavaScript / TypeScript with software architecture principles like domain-driven design, CQRS, etc ?

I value your real world experience with these languages.

[nonameiguess]

If you want a career with stability for the next 20 years in which your current knowledge will remain forever useful, I doubt web tech is the place to be. Even Javascript itself isn't enough, in spite of its stability for decades as a top of the Tiobe rankings juggernaut, thanks to framework churn. Mastering the core language barely helps you when there's a paradigm shift every few years in DSLs built on top of it that everyone expects you to use.

If you want backend stability, master Java. It may be boring, and I don't like it either, but it's been the dominant server-side application programming language for 25 years and has tremendous inertia and is not likely to go anywhere.

If you want to work in container runtime and orchestration technologies, then Go is probably a safe bet as it's taken such a lead as an implementation language in every container engine out there that it probably isn't going anywhere, either.

I love Rust, but it isn't currently dominant at anything unless you count "rewrite a critical service that can't afford garbage collection but still requires memory safety" as a meaningful category of software.

It sounds like you're trying to exist at the bleeding edge but still have some level of assurance that what you choose to master now will remain relevant decades from now. I don't think you can have both. If you'd have asked this question 20 years ago, you'd have been asking if you should master Perl or PHP. 10 years ago, maybe Scala or Python. Why should we think this decade will be any different from every other decade and that Go and Rust will achieve staying power when nothing else except Java did in the past?

To be clear, I think Go absolutely will keep its staying power for container engines, just as Python kept its staying power for scientific computing and systems scripting. But if you're asking specifically about cloud-based microservices, I wouldn't place a bet on anything specific at all. Master the domain itself and get good at learning new languages because they will very likely keep coming. Or master Java, because like it or not, it isn't going anywhere.

[nfgoto]

Spot on analysis.

I sure do want more stability in my career.

I have been considering Java.

I see a lot of great resources for software architecture and design patterns with Java examples.

Java for sure has the most advanced resources available for my domain and the most job opportunities especially when you know Spring Boot and the like.

[metaltyphoon]

Great analysis. If OP doesn’t want Java, go C# as an alternative.

[Arjuna]

Regarding the topic of career longevity as a software engineer:

Focus on combining your software engineering skills with delivering value in a specific, core competency.

That is to say:

Good software engineers tend to focus on being good at programming, and all of the details that venture entails (e.g., mastery of specific languages, knowledge of specific ways of operating in a given framework, IDE, or tool, etc.).

Better software engineers are capable of all of the preceding, plus the ability to apply a deeper level of problem-solving ability that has been laser-focused by their experience in the art.

Finally, superlative software engineers are capable of all of the preceding, plus the ability to leverage those skills to deliver value as a Subject Matter Expert (SME) in a specific domain.

I believe that you have to be more than just a programmer if you want to maximize your career's longevity, and its associated compensation package.

[ctvo]

Learn both. There's nothing particularly difficult about either. They have a lot of documentation, books, open source projects to learn idioms from. Rust obviously will take longer with more language features.

I also think your alternative option is outdated. There was a fad 5-10 years ago in the .NET / C# community around DDD and to a lesser extend CQRS. You read the DDD book, took bits you could use, and attempted to build better. It wasn't a silver bullet, and took tremendous teaching / culture change to get implemented. I personally never found it worthwhile in the spaces I worked in. I feel the industry has moved on, even now, let alone the future.

My advice is to be less timid around technologies. Get better at learning. Get better at the fundamentals. An immutable ledger that separates read from write is useful in a lot of distributed systems, not only as an application design pattern. An intentional common language that all refer to is a great process / culture change to improve communication. Does it have to be mapped identically in code? It depends.

[nfgoto]

Could you expound about nowadays practices regarding best software architecture practices.

Where I live (France), using DDD is highly regarded on the job market. Employers take you more seriously when you can talk about DDD principles and practices, especially as a JavaScript developer.

Any resources ?

[publicola1990]

Is reading DDD literature like the Evans book is worth the while for a developer today?

[jstx1]

Your question somehow implies that you can learn one language, maybe both if you really stretch yourself, and then that's it - you're locked in for 20 years. In reality, the effort that it takes isn't that much, you need to stay fresh on new tools anyway and so much will change in those years (you, the languages, the industry) that it's pointless to make such long term predictions and plans.

Personally, I would pick Go because there are more job opportunities with it right now. I also don't see the value proposition of Rust over Go at that level of abstraction (backend, cloud microservices). There are subjective elements to this too - I like that Go is a fairly simple get-things-done tool and is less cult-like than Rust.

But I don't think that it takes that much effort to switch languages, especially if you stay in the same problem domain. And I don't think that choosing a language is that big of a deal if you're already choosing between two good options.

[potta_coffee]

Anecdotally, I invested in Go and in IAC tools (Terraform etc). I've been building infrastructure, pipelines, as well as cloud-related tools for developers, and this niche has worked out for me really well. By that I mean, I doubled my income after a year of focus in this direction, after spending years doing more traditional web development (Python / Flask / Javascript / React / etc).

[nfgoto]

I just don't want to keep switching languages every two years.

The goal is to specialize in a purposely limited number of stuff that keeps its value long term.

[fulafel]

Rust isn't going to become a mainstream apps language, it's too complex and the memory management without GC is too hard compared to application languages.

[BoHerfIIIJrEsq]

I'm not excited about Go. I am excited about Rust.

[darthrupert]

Why?

[neophyt3]

May be both Golang is very small language compared to Rust Both have different paradigm. Its easy to learn go, docs are great for both, but reading tests of go std libraries is best which I found lacking in rust(or maybe I am yet to dig more into it)

[tomohawk]

If your time is limited, golang is the way to go. It is a language that is designed to scale with people. You'll find you can read and understand any go code. Also, it builds incredibly fast and is not a huge step away from dynamic languages.

Rust is a kitchen sink language - more of a replacement for c++. It takes quite a bit longer to learn/master.

[swman]

Focus on the problem at hand. Know a wide variety of tools and use the right one for the job.

At a senior+ level it shouldn’t be that hard to pick up new tools to add to your tool box.

I think both are personally good bets for the next 20 years.

[aaronchall]

Both or not is a false dichotomy. I would say, start with rust, which seems to have the most interesting ideas, then every once in a while, reassess.

[nsonha]

people actually upvote and answer to this question? Who would knows? It's 20 years.

20 years ago php was hot tech, php!!!

[dormento]

Still hot, still pretty darn useful.

PHP is just too easy to hate, because of its massive popularity.

[aaronchall]

20 years ago I picked python, with just a business and political science degree...

[rewq4321]

Currently Rust has way better tooling for integration with JS, but Go may catch up when the wasm-gc proposal gets standardized: https://github.com/WebAssembly/gc

[karmakaze]

Take what I say with more than a grain of salt as I don't have any experience working at an all-JS/TS shop. The backend capabilities and frameworks for js/ts has certainly improved but working as a sr dev at a monotech-stack company wouldn't be my first choice. I understand why it's done as it's hard to find good candidates in many areas and there are more dev with experience in js than anything else.

For that reason alone, if you want to master being a backend dev, I would suggest that you learn something else. It's more likely you'd be working with people with deep backend experience to learn from, and you distinguish yourself from the many js/ts/fullstack-backend devs. Of course, still grow and apply new principles to your js/ts work. It is possible that with number of companies that use a js/ts stack that some of them will be well known as having a concentration of great engineers. I can't guess how many or when that would be, so I'd bet on what's known today.

The reason to learn something else isn't only for your future career, learning different styles ecosystems makes you a better dev in you current one. The common aspects that people consider are: (1) dynamic vs static typed, (2) degrees of 'compiled', (3) garbage-collected, 'flavoured' (Rust), ref-counted, explicit memory management, (4) single-thread, fibres, multithreaded, or actors kinds of concurrency, (5) lisp, FP, or procedurally structured.

So of those, js/ts covers a bit of (1) and (2). Using finer-grained memory management is about low-level performance and there are very few places that's a big factor. It can be interesting but rarely applicable in most day jobs. I would definitely explore using an FP style with lots of filter/map, higher order function composition and using static types to represent logical states. Best done in a language with type inference but could be done to some degree in TS. Lisp is always interesting, but it wasn't for me--I couldn't imagine enjoying working with another person's (or a large team's) codebase.

[Edit: I also recommend building some front ends to consume your backends and be able to build-out hobby projects--it's hard to get good at designing APIs if you never feel the pain using the ones you make. I tend to use either Vue for web, or Flutter/Dart for mobile.]

As for Go or Rust in 20 years? That's a long time and if I had to bet I'd bet on Go getting better rather than Rust becoming fully mainstream. OTOH, I can see Rust owning actual low-level systems programming and Go being replaced by languages with fewer warts. I would still recommend learning Go now as it is a cognitive reset showing how simple things can, and ought to be--if perhaps a bit verbose at the moment without generics. It's not my favorite language but still a top pick for smaller projects.

[gccs]

Look at all the projects killed by google. Why would they not just create another language and kill off go overnight?

[nfgoto]

I must admit that this has crossed my mind.

I don't see the drive to promote Go by the people who created it.

It feels like, "we tried it...meh".

I might be wrong.

[ctvo]

Because Go is used by every large tech company in the world. If Google stopped investing in it, others would step in to move it forward.