I’m in a weird spot where I like both equally, but for slightly different reasons.
When I have a dumb idea (they’re all dumb), depending on what its core features are, I’ll prototype it in Go, TypeScript, or Python. Inevitably I’ll want to or I will actually rebuild it with rust once it’s relatively stable.
It’s like Go, TypeScript, and Python are pencil and rust is ink.
Go is my favourite for strictly back end prototyping, but I don’t love it for processing data. That’s where Python shines. Then sometimes I’ll use a full stack framework like Next or Remix and build a backend there, but transfer it (or important parts of it) to rust eventually.
My favourite deployment is a totally static site with a rust backend. But it’s equally easy with Go, and the initial development with Go is always way faster for me. It’s just the long term maintenance story that I don’t love with Go.
Also, I prefer Rust’s type system quite a bit. It could just be intuitive to me. I do find several teams I’ve worked with on Go projects have not actually understood the Go type system, and they’ve run into pain as a result very regularly.
"I’m in a weird spot where I like both equally, but for slightly different reasons."
It's not weird. Weird is "I have a language I use for everything. Quick scripts! Network servers! My shell! Games! Batch processing CSV records from random FTP servers! Everything! Any implication that my language is not the best choice for all these things must be met with maximum hostility!" is the weird thing. Popular, but weird.
A professional programmer should have at a bare minimum a static language, a dynamic scripting language, basic shell familiarity (be it Unix or Powershell, I'm OS agnostic here, but you should be able to use whatever it is), and probably at least some basic SQL of some sort. And as your career advances, it'll only grow from there.
If you violate general Go programming standards and write code that panics rather than erroring, because a lot of time in shell scripts "bail out loudly the instant anything goes wrong" actually is the error handling you want (that's all "set -e" is in shell in the end, after all), Go is still not a great shell language, but it's tolerable if you have advanced usages. Being able to use all the io.Reader & io.Writer based code can help you do certain very advanced things relatively nicely.
But you need to be doing something seriously funky for it to be worth it and cross into the positive in the cost/benefits analysis. I actually have a service that does this, doing some fairly sophisticated stuff with git repos and what is in them. But it's certainly not something I reach for because Go am best languages for all task.
not needing to learn and master another lang for scripting looks like significant pros to me. I am actually using java for my scripting because of that, which is stranger choice than golang.
If for no other reason than you will encounter code in dynamic scripting languages in your job, statistically speaking.
In my own experience, people who only know one or the other often end up with gaping holes in their skillset. One I see a lot even yea verily here on HN is people who only work with dynamic scripting languages do not realize just how slow their languages are, and pour vast amounts of ultimately wasted effort into speeding their scripting language up when the answer is to stop using them. On the flip side, people who know only a static language, and it's often only one static language, tend to have serious tunnel vision in general about software engineering; I would almost say it's like they don't so much know how to "program" as to drive their IDE in that one language. These people are often the worst about whatever the dogma is in their particular language and will end up driving themselves mindlessly off a cliff, even in their "native" language, when solving problems their dogma doesn't work well for. Example: The thing we've almost all seen with Java codebases that have patterns freaking everywhere, but where they aren't actually doing anything; the factoryfactory that only ever constructs one type of thing in the end, the template code pattern that has only one thing in the code that uses it, etc.
Having at least that much diversity in your language toolkit helps you escape the sort of thing Dijkstra was talking about with how BASIC was ruining people. The effect he was really observing is that in general, if you only have one language, and especially if you spend too much time in that one language before branching out, you tend to start mistaking the details of your language for the foundational reality of computing, and that causes all sorts of "difficult to characterize well in an HN post" problems for you. In Dijkstra's day, that happened to be BASIC, but today there are many languages that can cause that problem. Perhaps Javascript is the leader, not because of any specific characteristic of the language itself but because it is relatively easy to be a "web programmer" and never end up branched out into anything else. I see the negative effects of this from a bunch of people who think that the JS solution is the only solution, and can't even process the idea that if another language does it some other way, there may in fact be reasons for that and it may be a better solution in some ways. I wish that were sarcasm, but it really isn't, it's experience from helping people online.
I'm similar, but I think I'm going to replace Python and Go with Lisp and leave Go for CLI utilities that don't require heavy text parsing and concurrent but not CPU-bound (distributed) apps. Rust for low level or latency/performance sensitive things, which is most of what I do these days.
Comments
I’m in a weird spot where I like both equally, but for slightly different reasons.
When I have a dumb idea (they’re all dumb), depending on what its core features are, I’ll prototype it in Go, TypeScript, or Python. Inevitably I’ll want to or I will actually rebuild it with rust once it’s relatively stable.
It’s like Go, TypeScript, and Python are pencil and rust is ink.
Go is my favourite for strictly back end prototyping, but I don’t love it for processing data. That’s where Python shines. Then sometimes I’ll use a full stack framework like Next or Remix and build a backend there, but transfer it (or important parts of it) to rust eventually.
My favourite deployment is a totally static site with a rust backend. But it’s equally easy with Go, and the initial development with Go is always way faster for me. It’s just the long term maintenance story that I don’t love with Go.
Also, I prefer Rust’s type system quite a bit. It could just be intuitive to me. I do find several teams I’ve worked with on Go projects have not actually understood the Go type system, and they’ve run into pain as a result very regularly.
"I’m in a weird spot where I like both equally, but for slightly different reasons."
It's not weird. Weird is "I have a language I use for everything. Quick scripts! Network servers! My shell! Games! Batch processing CSV records from random FTP servers! Everything! Any implication that my language is not the best choice for all these things must be met with maximum hostility!" is the weird thing. Popular, but weird.
A professional programmer should have at a bare minimum a static language, a dynamic scripting language, basic shell familiarity (be it Unix or Powershell, I'm OS agnostic here, but you should be able to use whatever it is), and probably at least some basic SQL of some sort. And as your career advances, it'll only grow from there.
Time to rewrite my shell scripts in rust.
I'm mostly joking but there might be a couple cases where that makes sense for me...
go maybe better candidate, since more batteries included.
If you violate general Go programming standards and write code that panics rather than erroring, because a lot of time in shell scripts "bail out loudly the instant anything goes wrong" actually is the error handling you want (that's all "set -e" is in shell in the end, after all), Go is still not a great shell language, but it's tolerable if you have advanced usages. Being able to use all the io.Reader & io.Writer based code can help you do certain very advanced things relatively nicely.
But you need to be doing something seriously funky for it to be worth it and cross into the positive in the cost/benefits analysis. I actually have a service that does this, doing some fairly sophisticated stuff with git repos and what is in them. But it's certainly not something I reach for because Go am best languages for all task.
It's absolutely idiomatic to use panic in main. In fact, that's basically the only place it's allowed in "Go programming standards."
not needing to learn and master another lang for scripting looks like significant pros to me. I am actually using java for my scripting because of that, which is stranger choice than golang.
why this is necessary?
If for no other reason than you will encounter code in dynamic scripting languages in your job, statistically speaking.
In my own experience, people who only know one or the other often end up with gaping holes in their skillset. One I see a lot even yea verily here on HN is people who only work with dynamic scripting languages do not realize just how slow their languages are, and pour vast amounts of ultimately wasted effort into speeding their scripting language up when the answer is to stop using them. On the flip side, people who know only a static language, and it's often only one static language, tend to have serious tunnel vision in general about software engineering; I would almost say it's like they don't so much know how to "program" as to drive their IDE in that one language. These people are often the worst about whatever the dogma is in their particular language and will end up driving themselves mindlessly off a cliff, even in their "native" language, when solving problems their dogma doesn't work well for. Example: The thing we've almost all seen with Java codebases that have patterns freaking everywhere, but where they aren't actually doing anything; the factoryfactory that only ever constructs one type of thing in the end, the template code pattern that has only one thing in the code that uses it, etc.
Having at least that much diversity in your language toolkit helps you escape the sort of thing Dijkstra was talking about with how BASIC was ruining people. The effect he was really observing is that in general, if you only have one language, and especially if you spend too much time in that one language before branching out, you tend to start mistaking the details of your language for the foundational reality of computing, and that causes all sorts of "difficult to characterize well in an HN post" problems for you. In Dijkstra's day, that happened to be BASIC, but today there are many languages that can cause that problem. Perhaps Javascript is the leader, not because of any specific characteristic of the language itself but because it is relatively easy to be a "web programmer" and never end up branched out into anything else. I see the negative effects of this from a bunch of people who think that the JS solution is the only solution, and can't even process the idea that if another language does it some other way, there may in fact be reasons for that and it may be a better solution in some ways. I wish that were sarcasm, but it really isn't, it's experience from helping people online.
I'm similar, but I think I'm going to replace Python and Go with Lisp and leave Go for CLI utilities that don't require heavy text parsing and concurrent but not CPU-bound (distributed) apps. Rust for low level or latency/performance sensitive things, which is most of what I do these days.
I love this analogy