7 ms·

I don't get paid to write code in these languages; my enthusiasm in exploring them is limited by the amount of energy I have over the weekend. Honestly, I don't

I don't get paid to write code in these languages; my enthusiasm in exploring them is limited by the amount of energy I have over the weekend. Honestly, I don't see Rust as anything but a code-rewrite language. I find Rust to be unintuitive, and I don't think it is a language designed to be a "problem solver. So, what do I mean by a problem solver? If you have a problem and you write code by exploring different solutions, continuously improve, and write hacky stuff where the goal is to simply solve a problem. Rust is not a problem solver; it is going to fight you all the way through because of its emphasis on programmatic correctness. With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. I suppose that is how programming is supposed to be done - in a clear and structured manner. But let's admit it, nobody does that. On the other hand, Go is a language that sits between Python and Rust. Python is THE problem solver language, and Rust is an elegant and good etiquette language. Go just works as a hackable language with the benefits of a compiled language and type support. My plan with Rust vs Go for the time being: - If I need to solve a problem and can do continuous improvement on the codebase → Go - If I have the problem solved, I have the resources to do a rewrite → Rust

peterfirefly 3y ago
My first (and so far only) Rust program was an 8088 disassembler. Rust made it easy for me to try "different solutions, continuously improve, and write hacky stuff". Perhaps it's more a question of background? Rust contains many features I already know from the ML family + it formalizes the way I've already been thinking about memory since the early 90's.
- brabel 3y ago
  Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.
  - baq 3y ago
    Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.
  - peterfirefly 3y ago
    I haven't really had to use lifetime annotations yet, but again, they are just a formalization of the way I already think. I forgot that I had also written a small cycle-by-cycle emulator of a simple CPU (8-bit data bus, 16-bit addr bus, 8 16-bit GPRs + a 16-bit PC + a single condition flag + an interrupt flag, timer interrupts, conditional jumps, call, ret, iret, mov, add, terminal I/O). That was also surprisingly easy. I would like to use generators or something similar for a more realistic cycle-by-cycle emulator but I haven't gotten around to playing with that yet. Generators and various kinds of coroutines are, yet again, just formalizations of the way I have been thinking for years. Maybe other domains would be more challenging but I seriously doubt it. I do know that it will take me a couple more months before I'm really proficient in Rust -- including multi-threading -- and no longer fear macros.
  - thumbuddy 3y ago
    You probably shouldn't deal with lifetimes outside of first order use cases in 9/10 cases when a project is in its early stages. A clone or wrapper type isn't all that expensive in many applications. Just because something can be optimized doesn't mean it should be, especially early on in a project.
    - ssokolow 3y ago
      *nod* Rust's "make costs explicit" design does have a bit of a problem with encouraging premature optimization where something like Python would encourage sloppiness.
      - thumbuddy 3y ago
        I'll take obvious jank over hidden jank any day personally.
LambdaComplex 3y ago
> Rust is not a problem solver; it is going to fight you all the way through because of its emphasis on programmatic correctness. With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. You just described my reasons for switching from Rust to Go better than I ever have.
- madiele 3y ago
  Rust is great for writing stuff that needs to be stable with little downtime, for anything that needs to change a lot rust is not there yet, it has lots of sharp corners like not being able to make a factory interface that returns another interface (thogh this is coming in a few months), in general it's hard to do non-leaky abstractions in rust ATM, I do think it will get there in a few years once the few sharp corners are gone. But having made a microservice in rust it is the most stable software I ever written, you are basically paying upfront any null reference and thread safety issue I would have needed to debug. It probably did not save me time, but it definitely was a better experience to write
bibabaloo 3y ago
I think it's one of those things where you need to drink the coolaid. Once you get over the learning hump and fighting against you, you won't want to go back to languages with poorer and less strict type systems. There a lot of value in letting the compiler do it for you
- deleted 3y ago
  [deleted]
deaddodo 3y ago
While I hear you and grok+understand you; I think this 100% comes from your background and what problems you are trying to solve. As someone that does a ton of systems (traditional definition; e.g. embedded, OS, emudev, etc) development in my hobby time, Rust (and Zig, more often these days [for me]) is perfectly conducive to my use cases and improves my development flow; while using Go would get in the way far too often. But when I do work Go excels in (web architecture, especially), I'm not particularly keen on using Rust or Zig in it's place. While it's perfectly possible to build a Postgres-fronting, redis-cached microservice to manage users, auth, etc in Rust, it's going to be an exercise in frustration compared to something more streamlined for that task.
- berkes 3y ago
  I disagree here. Anvd also disagree with grandparent. It's fine to explore with- and write proofs of concepts in- Rust. In many ways, it's better suited than Python, Ruby, JS or PHP for this, for several reasons. I have too little production experience with go to know how it does here. The Rust type checker, and easy, built-in test framework, make refactoring easy and certain. Much more than the common "fingers crossed let's deploy" refactoring I've experienced with Ruby and Python. And way more than the Yolo methodology commonly employed in JS and PHP. And fearless refactoring is a requirement for me to experiment and explore. Because once I know what and how I want it, refactoring is needed. A good, fast testing framework helps me explore. Efficient and iterative. Rust (and Go) have much to offer here, whereas in Python, Ruby and even more so in PHP or JS, testing is an afterthought, third party, bring your own setup. In rust I can start writing a test immediately after 'cargo init experiment'. But I understand not for everyone exploration==tests. The rediculous ease of deployment of both Rust and Go compared to Python, JS, PHP and worst, Ruby, is crucial when I'm figuring out if people need what I'm building. 'cargo build --release && scp target/build/foo example.com:/use/bin' and I'm hosted and deployed. It's less work than getting a Heroku connected to GitHub. For me, releasing fast, early and often is a crucial feature when exploring. Rust (and Go) have solved this. In fact, this is my main reason to build in Rust: I'm just fed up managing complex and ever breaking runtimes, (pip-, rb-, nv) envs, complex and ever breaking CI. With rust, my initial versions just have ARCs, Box-es, unwrap()s and clone()s all over the place. It's how I circumvent the frustration, yet know the app is 'correct'. All those clones, unwraps, boxes, Arcs etc act as TODO's, bit without the "this will probably cause corrupted data, fix me!", that my TODOs in Ruby or Python came with when exploring.
toasted-subs 3y ago
Kind of funny, the experience I’ve had with go was ripping my hair out trying to get dependencies installed. Cargo was incredibly helpful and made the process painless. If I’m doing something for fun I always go to Python though. Just makes everything seem incredibly natural, and given all the fancy interpreters it can be pretty fast.
- thumbuddy 3y ago
  Isn't it just "go mod install" or something? Oh you probably tried it when golang changes where it cached packages. I feel you that was a super crappy time to learn Go.
kaba0 3y ago
Go is more verbose than Java, which you may very well consider overly verbose. The only reason it is between Python and Rust is that the two languages are two extremes of low-high level languages. Go is as expressive as C, which is a negative.
- threeseed 3y ago
  > Go is more verbose than Java In real world use ridiculously so. The lack of exceptions, Option type or ability to chain or manipulate errors means every line ends up wrapped in a 90s style "if error" check. Which ends up making code less robust than languages with more modern approaches like Rust, Scala, Swift etc.
  - xyproto 3y ago
    You can look at "if err == nil" and tell what is going on, but who knows which layer of exception handling will catch that "throws".
    - threeseed 3y ago
      In JVM languages it is easy to know what is catching what. The method type signatures clearly specify what exceptions will be thrown. And the compiler requires you to deliberately handle those exceptions. But I wouldn't consider Java to be the best approach for error handling anyway.
    - kaba0 3y ago
      Which is the only sane thing in most cases. What can you do inside the helper function of a helper function with an incorrect user data? The only sane place to handle it is n levels up, so bubbling up is the correct default. At least rust has a handy macro for it, but go’s error handling is catastrophic, not a proper sum type, nor some form of propagation… it is literally the bad errno from C burned into the language.
      - Aditya_Garg 3y ago
satvikpendem 3y ago
Not really. I use unwrap and clone everywhere and I can do everything as if Rust were then a garbage collected language, and I can then test out different solutions, hack my way through, just as I would in Go or Python. Then once I have a good solution, even if I don't optimize it, it is leagues faster than Python and even faster than Go. If I do decide to optimize it, then, it's fast, really fast. IMO those who say Rust isn't suitable for hacking seem to try to conform to best practices right away when really, dealing with lifetimes and excessive clones should be part of the optimization step, not the ideation and experimentation steps. Rust is as high level as you want it to be. Hell, I write web backends and sometimes even frontends in just Rust and I never worry about memory until I want to optimize, if I even want to optimize.
- hannofcart 3y ago
  > Not really. I use unwrap and clone everywhere and I can do everything as if Rust were then a garbage collected language, and I can then test out different solutions, hack my way through, just as I would in Go or Python. This part of the comment deserves to be highlighted and mentioned more. I think this exactly the way to "hack something together quickly" in rust. After that, incorporating correctness seems to be as simple as grepping with each unwrap and "dealing with it". With the above approach, Rust is a great prototyping language as well.
  - bryanlarsen 3y ago
    The thing about clone and to a lesser extent unwrap is that 90% of the time, just leaving in the clone is fine. It might be suboptimal, but if it's not in the main loop, who cares? With unwrap, replacing the unwrap with an expect signals you've accepted that an unwrap is ok in that piece of code. I'd like a similar convention for clone.
    - kaba0 3y ago
      If that’s the case, then Scala and similar should also enter the question. That is at least an expressive language compared to Go, and if you don’t need rust’s performance it may be a good tradeoff.
forrestthewoods 3y ago
My experience is the opposite. Refactoring Python code is all but impossible. Dynamic types and runtime errors is nightmare fuel for a refactor. Rust code lets be confident that when I make changes as I explore the problem/solution space that my program will actually work.
dannersy 3y ago
Like someone else has said, I hear and understand what you're saying but I could not disagree more. I write Rust professionally and what you hate about Rust is opposite to why I love it so much. Especially in larger projects, I have never in all my career had an easier time hacking and iterating. I'm infinitely more confident in writing a ton of lines that will work once I compile. In Python and Go, I could end up chasing silly bugs and waste time debugging and tracing to find that I made a typo or ran into a language quirk that gave me an unexpected nil pointer. That situation is almost non-existent in Rust, it's just me and the problem. Rust is honest and upfront about its quirks and will yell at you about it before you have a hard to find bug in production. Those last two sentences aren't 100% true. Advanced Rust can be tough and you absolutely will fight with it. But to be perfectly honest, this gets rare over time and usually it comes from a lack of understanding. When you finally do understand, it's another tool to add to your belt that makes you a better programmer.
- thumbuddy 3y ago
  Hard agree here. Once people understand rust, not read some bullet points on a blog they start to understand how useful even the tooling is. Only thing I'll add is. 8 times out of 10 if you are reaching for advanced rust, you are over engineering. Most software projects don't require it and when they do, you should always question whether there's a simpler more maintainable way or make a other design decision. There is no award for least lines of code, or most utilized compiler. Software is social. That's Go's biggest strength over Rust and Scala. Good luck getting job security in that language. It takes a few years to really know what I'm saying but in my opinion it's the difference between a senior engineer and a non senior.
littlestymaar 3y ago
> With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. I suppose that is how programming is supposed to be done - in a clear and structured manner. But let's admit it, nobody does that. And that's absolutely not how you do it in Rust either. Once you've internalized the Rules of the language, you can definitely grok your solution in Rust the same way you'd do in Python, the biggest difference being that Rust will help you a lot more when refactoring your code to the next iteration, so you'd be more efficient over a few days of work in Rust than in Python. The big caveat being that you need to actually learn the language first instead of pretending you're a polyglot developer and you can write code in any language without having to spend time learning it, but maybe you'd argue that nobody does that either…
alpaca128 3y ago
I get why you think that, but I can assure you Rust is perfectly fine for experimentation with enough familiarity. It cannot match Python in the short term, but it doesn't take much hacking with Python until I wish I had started with a more maintainable language. It is really easy to introduce bugs in Python code that would be caught instantly by a compiler and the debugging time adds up quickly.
- wendyshu 3y ago
  Can you give an example?
thumbuddy 3y ago
If you spent more time with rust your opinion of it would change. It's strength has nothing to do with rewriting software. It's easy to maintain, and pretty fast to write. I prefer go for cloud integrations because they tend to have the best implementations and most solid APIs. That's about it though. Python is a good bash replacement, but I don't like writing large projects in it. It's hard to maintain and the errors that come from production are never straightforward. Good for some medium scale mathy compute projects though. C++ is where I write most math code after prototyping it elsewhere(R or Python) Rust for me is the answer to most things except, it's ecosystem is a bit weak, and it's a bit of a clout chaser language(not as bad as others though)
bryanlarsen 3y ago
IME, Rust is the best language for doing major refactors of your code. You can make a major change, and if it compiles you can be relatively confident that you didn't miss a side effect of your change. So it's an excellent language for continuous improvement.

peterfirefly 3y ago

My first (and so far only) Rust program was an 8088 disassembler. Rust made it easy for me to try "different solutions, continuously improve, and write hacky stuff". Perhaps it's more a question of background? Rust contains many features I already know from the ML family + it formalizes the way I've already been thinking about memory since the early 90's.

brabel 3y ago
Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.
- baq 3y ago
  Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.
- peterfirefly 3y ago
  I haven't really had to use lifetime annotations yet, but again, they are just a formalization of the way I already think. I forgot that I had also written a small cycle-by-cycle emulator of a simple CPU (8-bit data bus, 16-bit addr bus, 8 16-bit GPRs + a 16-bit PC + a single condition flag + an interrupt flag, timer interrupts, conditional jumps, call, ret, iret, mov, add, terminal I/O). That was also surprisingly easy. I would like to use generators or something similar for a more realistic cycle-by-cycle emulator but I haven't gotten around to playing with that yet. Generators and various kinds of coroutines are, yet again, just formalizations of the way I have been thinking for years. Maybe other domains would be more challenging but I seriously doubt it. I do know that it will take me a couple more months before I'm really proficient in Rust -- including multi-threading -- and no longer fear macros.
- thumbuddy 3y ago
  You probably shouldn't deal with lifetimes outside of first order use cases in 9/10 cases when a project is in its early stages. A clone or wrapper type isn't all that expensive in many applications. Just because something can be optimized doesn't mean it should be, especially early on in a project.
  - ssokolow 3y ago
    *nod* Rust's "make costs explicit" design does have a bit of a problem with encouraging premature optimization where something like Python would encourage sloppiness.
    - thumbuddy 3y ago
      I'll take obvious jank over hidden jank any day personally.

LambdaComplex 3y ago

> Rust is not a problem solver; it is going to fight you all the way through because of its emphasis on programmatic correctness. With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. You just described my reasons for switching from Rust to Go better than I ever have.

madiele 3y ago
Rust is great for writing stuff that needs to be stable with little downtime, for anything that needs to change a lot rust is not there yet, it has lots of sharp corners like not being able to make a factory interface that returns another interface (thogh this is coming in a few months), in general it's hard to do non-leaky abstractions in rust ATM, I do think it will get there in a few years once the few sharp corners are gone. But having made a microservice in rust it is the most stable software I ever written, you are basically paying upfront any null reference and thread safety issue I would have needed to debug. It probably did not save me time, but it definitely was a better experience to write

bibabaloo 3y ago

I think it's one of those things where you need to drink the coolaid. Once you get over the learning hump and fighting against you, you won't want to go back to languages with poorer and less strict type systems. There a lot of value in letting the compiler do it for you

deleted 3y ago
[deleted]

deaddodo 3y ago

While I hear you and grok+understand you; I think this 100% comes from your background and what problems you are trying to solve. As someone that does a ton of systems (traditional definition; e.g. embedded, OS, emudev, etc) development in my hobby time, Rust (and Zig, more often these days [for me]) is perfectly conducive to my use cases and improves my development flow; while using Go would get in the way far too often. But when I do work Go excels in (web architecture, especially), I'm not particularly keen on using Rust or Zig in it's place. While it's perfectly possible to build a Postgres-fronting, redis-cached microservice to manage users, auth, etc in Rust, it's going to be an exercise in frustration compared to something more streamlined for that task.

berkes 3y ago
I disagree here. Anvd also disagree with grandparent. It's fine to explore with- and write proofs of concepts in- Rust. In many ways, it's better suited than Python, Ruby, JS or PHP for this, for several reasons. I have too little production experience with go to know how it does here. The Rust type checker, and easy, built-in test framework, make refactoring easy and certain. Much more than the common "fingers crossed let's deploy" refactoring I've experienced with Ruby and Python. And way more than the Yolo methodology commonly employed in JS and PHP. And fearless refactoring is a requirement for me to experiment and explore. Because once I know what and how I want it, refactoring is needed. A good, fast testing framework helps me explore. Efficient and iterative. Rust (and Go) have much to offer here, whereas in Python, Ruby and even more so in PHP or JS, testing is an afterthought, third party, bring your own setup. In rust I can start writing a test immediately after 'cargo init experiment'. But I understand not for everyone exploration==tests. The rediculous ease of deployment of both Rust and Go compared to Python, JS, PHP and worst, Ruby, is crucial when I'm figuring out if people need what I'm building. 'cargo build --release && scp target/build/foo example.com:/use/bin' and I'm hosted and deployed. It's less work than getting a Heroku connected to GitHub. For me, releasing fast, early and often is a crucial feature when exploring. Rust (and Go) have solved this. In fact, this is my main reason to build in Rust: I'm just fed up managing complex and ever breaking runtimes, (pip-, rb-, nv) envs, complex and ever breaking CI. With rust, my initial versions just have ARCs, Box-es, unwrap()s and clone()s all over the place. It's how I circumvent the frustration, yet know the app is 'correct'. All those clones, unwraps, boxes, Arcs etc act as TODO's, bit without the "this will probably cause corrupted data, fix me!", that my TODOs in Ruby or Python came with when exploring.

toasted-subs 3y ago

Kind of funny, the experience I’ve had with go was ripping my hair out trying to get dependencies installed. Cargo was incredibly helpful and made the process painless. If I’m doing something for fun I always go to Python though. Just makes everything seem incredibly natural, and given all the fancy interpreters it can be pretty fast.

thumbuddy 3y ago
Isn't it just "go mod install" or something? Oh you probably tried it when golang changes where it cached packages. I feel you that was a super crappy time to learn Go.

kaba0 3y ago

Go is more verbose than Java, which you may very well consider overly verbose. The only reason it is between Python and Rust is that the two languages are two extremes of low-high level languages. Go is as expressive as C, which is a negative.

threeseed 3y ago
> Go is more verbose than Java In real world use ridiculously so. The lack of exceptions, Option type or ability to chain or manipulate errors means every line ends up wrapped in a 90s style "if error" check. Which ends up making code less robust than languages with more modern approaches like Rust, Scala, Swift etc.
- xyproto 3y ago
  You can look at "if err == nil" and tell what is going on, but who knows which layer of exception handling will catch that "throws".
  - threeseed 3y ago
    In JVM languages it is easy to know what is catching what. The method type signatures clearly specify what exceptions will be thrown. And the compiler requires you to deliberately handle those exceptions. But I wouldn't consider Java to be the best approach for error handling anyway.
  - kaba0 3y ago
    Which is the only sane thing in most cases. What can you do inside the helper function of a helper function with an incorrect user data? The only sane place to handle it is n levels up, so bubbling up is the correct default. At least rust has a handy macro for it, but go’s error handling is catastrophic, not a proper sum type, nor some form of propagation… it is literally the bad errno from C burned into the language.
    - Aditya_Garg 3y ago

satvikpendem 3y ago

Not really. I use unwrap and clone everywhere and I can do everything as if Rust were then a garbage collected language, and I can then test out different solutions, hack my way through, just as I would in Go or Python. Then once I have a good solution, even if I don't optimize it, it is leagues faster than Python and even faster than Go. If I do decide to optimize it, then, it's fast, really fast. IMO those who say Rust isn't suitable for hacking seem to try to conform to best practices right away when really, dealing with lifetimes and excessive clones should be part of the optimization step, not the ideation and experimentation steps. Rust is as high level as you want it to be. Hell, I write web backends and sometimes even frontends in just Rust and I never worry about memory until I want to optimize, if I even want to optimize.

hannofcart 3y ago
> Not really. I use unwrap and clone everywhere and I can do everything as if Rust were then a garbage collected language, and I can then test out different solutions, hack my way through, just as I would in Go or Python. This part of the comment deserves to be highlighted and mentioned more. I think this exactly the way to "hack something together quickly" in rust. After that, incorporating correctness seems to be as simple as grepping with each unwrap and "dealing with it". With the above approach, Rust is a great prototyping language as well.
- bryanlarsen 3y ago
  The thing about clone and to a lesser extent unwrap is that 90% of the time, just leaving in the clone is fine. It might be suboptimal, but if it's not in the main loop, who cares? With unwrap, replacing the unwrap with an expect signals you've accepted that an unwrap is ok in that piece of code. I'd like a similar convention for clone.
  - kaba0 3y ago
    If that’s the case, then Scala and similar should also enter the question. That is at least an expressive language compared to Go, and if you don’t need rust’s performance it may be a good tradeoff.

forrestthewoods 3y ago

My experience is the opposite. Refactoring Python code is all but impossible. Dynamic types and runtime errors is nightmare fuel for a refactor. Rust code lets be confident that when I make changes as I explore the problem/solution space that my program will actually work.

dannersy 3y ago

Like someone else has said, I hear and understand what you're saying but I could not disagree more. I write Rust professionally and what you hate about Rust is opposite to why I love it so much. Especially in larger projects, I have never in all my career had an easier time hacking and iterating. I'm infinitely more confident in writing a ton of lines that will work once I compile. In Python and Go, I could end up chasing silly bugs and waste time debugging and tracing to find that I made a typo or ran into a language quirk that gave me an unexpected nil pointer. That situation is almost non-existent in Rust, it's just me and the problem. Rust is honest and upfront about its quirks and will yell at you about it before you have a hard to find bug in production. Those last two sentences aren't 100% true. Advanced Rust can be tough and you absolutely will fight with it. But to be perfectly honest, this gets rare over time and usually it comes from a lack of understanding. When you finally do understand, it's another tool to add to your belt that makes you a better programmer.

thumbuddy 3y ago
Hard agree here. Once people understand rust, not read some bullet points on a blog they start to understand how useful even the tooling is. Only thing I'll add is. 8 times out of 10 if you are reaching for advanced rust, you are over engineering. Most software projects don't require it and when they do, you should always question whether there's a simpler more maintainable way or make a other design decision. There is no award for least lines of code, or most utilized compiler. Software is social. That's Go's biggest strength over Rust and Scala. Good luck getting job security in that language. It takes a few years to really know what I'm saying but in my opinion it's the difference between a senior engineer and a non senior.

littlestymaar 3y ago

> With Rust, you have to have the solution first, consider the language-specific caveats, and write something in such a way that you don't go back and have to improve it. I suppose that is how programming is supposed to be done - in a clear and structured manner. But let's admit it, nobody does that. And that's absolutely not how you do it in Rust either. Once you've internalized the Rules of the language, you can definitely grok your solution in Rust the same way you'd do in Python, the biggest difference being that Rust will help you a lot more when refactoring your code to the next iteration, so you'd be more efficient over a few days of work in Rust than in Python. The big caveat being that you need to actually learn the language first instead of pretending you're a polyglot developer and you can write code in any language without having to spend time learning it, but maybe you'd argue that nobody does that either…

alpaca128 3y ago

I get why you think that, but I can assure you Rust is perfectly fine for experimentation with enough familiarity. It cannot match Python in the short term, but it doesn't take much hacking with Python until I wish I had started with a more maintainable language. It is really easy to introduce bugs in Python code that would be caught instantly by a compiler and the debugging time adds up quickly.

wendyshu 3y ago
Can you give an example?

thumbuddy 3y ago

If you spent more time with rust your opinion of it would change. It's strength has nothing to do with rewriting software. It's easy to maintain, and pretty fast to write. I prefer go for cloud integrations because they tend to have the best implementations and most solid APIs. That's about it though. Python is a good bash replacement, but I don't like writing large projects in it. It's hard to maintain and the errors that come from production are never straightforward. Good for some medium scale mathy compute projects though. C++ is where I write most math code after prototyping it elsewhere(R or Python) Rust for me is the answer to most things except, it's ecosystem is a bit weak, and it's a bit of a clout chaser language(not as bad as others though)

bryanlarsen 3y ago

IME, Rust is the best language for doing major refactors of your code. You can make a major change, and if it compiles you can be relatively confident that you didn't miss a side effect of your change. So it's an excellent language for continuous improvement.