Ash HN: Go or Rust for JavaScript developer in the next 20 years?
45 comments
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.
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.
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.
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.
Great analysis. If OP doesn’t want Java, go C# as an alternative.
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.
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.
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.
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.
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 ?
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 ?
Is reading DDD literature like the Evans book is worth the while for a developer today?
I'd put it much lower on the list of readings.
Complex domains are still around, developers should learn them before trying to come up with solutions but they're implemented differently: As services with clear boundaries, with explicit contracts.
DDD can be applied to the boundaries of services, within API contracts so they speak a common language. The unit of encapsulation of a service makes a lot of the implementation details in the book moot.
Problems that are more relevant today are service discovery, observability, low friction of computing provisioning as organizations grow. This sounds a lot like devops concerns. It's not purely so. It's the complexity that grows when organizations expand and add functionality to their software. Its outcome, tremendous complexity, is what DDD tried to tame in 2004.
To expand on the above:
When we began switching to services as units of encapsulation, we implemented boundaries, contracts, kept business logic separate. Did we match the domain perfectly? Often not, but the API contracts between services is easier to enforce. At a high level a standard can be set on how we should speak a shared language. This is most of the benefits I took out of Evans book. It happened organically in the industry slowly.
Localized, each service is easy to reason about, test, and refactor. Great. The complexity NOW is managing and operating these services for small to medium organizations (the same ones struggled with domain modeling and design patterns to tame their monolith in a previous era).
Complex domains are still around, developers should learn them before trying to come up with solutions but they're implemented differently: As services with clear boundaries, with explicit contracts.
DDD can be applied to the boundaries of services, within API contracts so they speak a common language. The unit of encapsulation of a service makes a lot of the implementation details in the book moot.
Problems that are more relevant today are service discovery, observability, low friction of computing provisioning as organizations grow. This sounds a lot like devops concerns. It's not purely so. It's the complexity that grows when organizations expand and add functionality to their software. Its outcome, tremendous complexity, is what DDD tried to tame in 2004.
To expand on the above:
When we began switching to services as units of encapsulation, we implemented boundaries, contracts, kept business logic separate. Did we match the domain perfectly? Often not, but the API contracts between services is easier to enforce. At a high level a standard can be set on how we should speak a shared language. This is most of the benefits I took out of Evans book. It happened organically in the industry slowly.
Localized, each service is easy to reason about, test, and refactor. Great. The complexity NOW is managing and operating these services for small to medium organizations (the same ones struggled with domain modeling and design patterns to tame their monolith in a previous era).
It is, if only to learn how some people approach modelling domains. It's rarely a bad idea to see different approaches to doing stuff. That being said Evan's book is a rather dry read.
A lot around DDD, like implementations tend to have become dated. However, the principles around a well designed domain isn't. So not sure what he refers to.
Works like from Rebbeca Wirfs-Brock, I believe it was called Object Design about roles, responsibility and interaction/collaboration is like just if not more important to me.
It boils down to, understanding the motivations behind a technology and apply when needed. Design your objects and software according to state, etc.
Works like from Rebbeca Wirfs-Brock, I believe it was called Object Design about roles, responsibility and interaction/collaboration is like just if not more important to me.
It boils down to, understanding the motivations behind a technology and apply when needed. Design your objects and software according to state, etc.
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.
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.
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).
Interested, what is your job title now and what is the challenges looking for an infrastructure job with only web dev experience in your CV. How did you start doing platform/infrastructure work? Was it picking them up at work or OSS/side project?
I was working at smaller companies and I crossed over into cloud and infrastructure incrementally by necessity. So at one company, I was managing a team of developers who were all decent at web development, but the company mandated that we take a number of disparate products they'd bought from other companies, running on mostly on-location and migrate all to the cloud. Since there weren't any cloud engineers around, this work fell to me.
After getting some hands-on experience with this type of work, I found a job at a managed services company that had lots of AWS expertise, but really didn't have any good programmers working for them. Since the company wasn't really a software company, they neglected programming skills in the interview process, but then found themselves in need of more development horsepower. While there, I ended up building internal tools and APIs that smoothed over some gaps not covered by the myriad 3rd party solutions they were cobbling together, and also build APIs over some janky ad-hoc Lambda based processes they'd built.
After a year at that company, I was able to land a better gig at a company as a "senior cloud engineer". What clinched this role for me was also programming ability. It seems like a lot of "cloud" teams are composed of former operations guys that seem to hit a brick wall when they come to certain tasks, and I'm pretty good at bridging that gap, and that's how I sell myself.
After getting some hands-on experience with this type of work, I found a job at a managed services company that had lots of AWS expertise, but really didn't have any good programmers working for them. Since the company wasn't really a software company, they neglected programming skills in the interview process, but then found themselves in need of more development horsepower. While there, I ended up building internal tools and APIs that smoothed over some gaps not covered by the myriad 3rd party solutions they were cobbling together, and also build APIs over some janky ad-hoc Lambda based processes they'd built.
After a year at that company, I was able to land a better gig at a company as a "senior cloud engineer". What clinched this role for me was also programming ability. It seems like a lot of "cloud" teams are composed of former operations guys that seem to hit a brick wall when they come to certain tasks, and I'm pretty good at bridging that gap, and that's how I sell myself.
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.
The goal is to specialize in a purposely limited number of stuff that keeps its value long term.
I would plan for 3-5 years ahead depending on your interests and what you like to do, instead of trying to minimise the switching of languages or making guesses about decades in the future.
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.
I'm not excited about Go. I am excited about Rust.
Why?
Personally I think rust has some big ideas, particularly it uses borrowing instead of garbage collection. Go, on the other hand, could be seen as Java—-.
I also get the new Java vibe. Everything about the culture surrounding the code makes me _feel_ that way. I can't point to any single particular thing. Not necessarily saying it's a bad thing, especially when it comes to longevity.
Go seen as Java ? Really...?
What makes you say that ?
Mainly garbage collection. If you've got garbage collection performance is not going to be better than Java.
Goroutines, channels and all of that are cute but I see go as Java--. Opinionated approaches to concurrency go so far and then they run out of steam.
We are living in the deep multi-core age and it is quite mainstream to have 8 or more cores, Java gives you primitives that are sufficient to keep those cores almost fully utilized doing real work. To do so you have to understand what those primitives are and what their characteristics are: attempts to solve parallelism and concurrency that don't do that (like the work-stealing mechanism behind JDK 8 parallel streams) might keep 3 cores on an 8 core machine busy with real work if you're lucky. Tune up an appropriate Executor with the right thread count and and you can get 7.8 cores worth of real work barely trying...
But you have to understand what an Executor does and what your toolbox of concurrency primitive does. There is this promise that "channels solve everything" and it's just not true... I mean with channels you might always get forward progress but you won't unleash the multicore beast inside your phone, never mind desktop or server.
Goroutines, channels and all of that are cute but I see go as Java--. Opinionated approaches to concurrency go so far and then they run out of steam.
We are living in the deep multi-core age and it is quite mainstream to have 8 or more cores, Java gives you primitives that are sufficient to keep those cores almost fully utilized doing real work. To do so you have to understand what those primitives are and what their characteristics are: attempts to solve parallelism and concurrency that don't do that (like the work-stealing mechanism behind JDK 8 parallel streams) might keep 3 cores on an 8 core machine busy with real work if you're lucky. Tune up an appropriate Executor with the right thread count and and you can get 7.8 cores worth of real work barely trying...
But you have to understand what an Executor does and what your toolbox of concurrency primitive does. There is this promise that "channels solve everything" and it's just not true... I mean with channels you might always get forward progress but you won't unleash the multicore beast inside your phone, never mind desktop or server.
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)
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.
Rust is a kitchen sink language - more of a replacement for c++. It takes quite a bit longer to learn/master.
[deleted]
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.
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.
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.
people actually upvote and answer to this question? Who would knows? It's 20 years.
20 years ago php was hot tech, php!!!
20 years ago php was hot tech, php!!!
Still hot, still pretty darn useful.
PHP is just too easy to hate, because of its massive popularity.
PHP is just too easy to hate, because of its massive popularity.
nah it's hated because it's such a crap language, I'm sure they piled enough stuff on it for 20y so now it's tolerable, but that doesn't change anything. PHP was originally "Hypertext Preprocessor", not even a programming language. You don't make a programming laguage as an after-thought.
> You don't make a programming laguage as an after-thought.
Why not?
I thought programming languages was just a tool, a means to an end. If that is the case, which I believe it is, it shouldn't really matter in which way it is created.
I would pick a tool that's grown out of actual needs over some guy thinking in the basement for 20 years any day of the week. Because the first one will solve problems and the second most likely won't.
Why not?
I thought programming languages was just a tool, a means to an end. If that is the case, which I believe it is, it shouldn't really matter in which way it is created.
I would pick a tool that's grown out of actual needs over some guy thinking in the basement for 20 years any day of the week. Because the first one will solve problems and the second most likely won't.
because if you make a template engine and then oveload it with patches in order to make it behave like a general programming language, there is no way that can result in a cohesive thing that is effective for, say, financial transaction, which is something else completely different from what it was made for
And yet php pretty much power most ecommerce sites in existance. Sure maybe it isn't good enough for a banking systems, the NASA rovers, life supporting systems or similar stuff. But it certainly good enough for most web apps.
webapps are not just glorified sets of templates do you know that, there is a lot of domain logic in there, as well as concurrency, transaction etc.
Yes PHP is very popular, so is Tiktok, if anything it's an indication of stupidity.
Yes PHP is very popular, so is Tiktok, if anything it's an indication of stupidity.
Yes and php can handle that just fine. In fact, phps concurrency model is IMHO better than many others since you will basically never have memory issues.
Sure storing state must be done in some other kind of tech like redis or similar, but what the hell it is still kind of awesome and scales really easily.
Also, when there is little traffic it basically does not consume any memory which makes it possible to run a lot of sites on the same machine. This is better for the environment and the wallet.
The funniest thing of all is that many languages are imitating php with serverless.
Sure storing state must be done in some other kind of tech like redis or similar, but what the hell it is still kind of awesome and scales really easily.
Also, when there is little traffic it basically does not consume any memory which makes it possible to run a lot of sites on the same machine. This is better for the environment and the wallet.
The funniest thing of all is that many languages are imitating php with serverless.
> many languages are imitating php with serverless.
just shut up
look this is really lame, the only thing I said in my original comment was that the hot language 20 ago, which happened to be PHP, is no longer hot today.
You could argue that PHP is a good language, good luck with that I guess.
However the point remains is that no one think PHP is a language of the future that they should invest their time into. Heck even the fad *after* PHP, Ruby, which people generally have positive view of, is dying.
just shut up
look this is really lame, the only thing I said in my original comment was that the hot language 20 ago, which happened to be PHP, is no longer hot today.
You could argue that PHP is a good language, good luck with that I guess.
However the point remains is that no one think PHP is a language of the future that they should invest their time into. Heck even the fad *after* PHP, Ruby, which people generally have positive view of, is dying.
20 years ago I picked python, with just a business and political science degree...
what would be the moral of your story? Learn a toy language at the time, it would become the de facto data science pl in 20 years?
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
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.
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.
Look at all the projects killed by google. Why would they not just create another language and kill off go overnight?
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.
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.
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.
Not to mention a lot of critical components of modern infrastructure like docker, podman and kubernetes are built using go
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.