10 ms·

This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choi

by gwd 2y ago

This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choice of language or tooling than whether it's fast or slow or reliable at one instant in time -- you have to ask how you will grow and maintain things going forward. That said, obviously all languages were in that state at some point. Twenty-eight years ago you might have said the same thing about Java. Twenty-four years ago, Perl might have looked like a better choice than Python; now it's clearly the opposite. XenServer took a gamble and wrote their main control stack in OCaml in 2008; on the whole that has had some benefits, but the number of OCaml developers has not significantly grown, and it's not easy to hire people. That said, I think Rust is much more likely to follow Java's trajectory than OCaml's: My prediction is that it's only going to be easier and easier to find Rust developers.

adamc 2y ago
Twenty-four years ago, Python already looked better to me. I maintained a big Perl 5 app. Yuck. The problem wasn't that you couldn't write it, the problem was that you had to be able to read widely differing styles of Perl... and if you wanted to read library code, it was a huge pain. I quit maintaining that system in 2005, and it has barely changed since, from what I'm told. Viability of a language is certainly a consideration, but the characteristics of the language also matter. What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.
- sshine 2y ago
  > My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise. You can certainly make a case for that being inevitable in some ways: Rust can be written in many ways to address different levels of abstraction, and when you stack those, you can require the reader to know about all of them. If someone gives me a piece of Python code, it can only be hard to understand if the domain is hard (e.g physics) or it is poorly written. In that way, Rust belongs with C++ and Haskell. The abstractions that Rust will introduce over time won’t grow in all directions like with C++ and Haskell (e.g. you won’t get higher-kinded types or GADTs in the next ten years).
- pjmlp 2y ago
  In 2000, Java was still about doing dancing applets, businesses only started taking Java marketing seriously after two things happened, Hotspot became a thing, making it more appealing than C++ for cross-platform server code, versus dealing with the mess of writing portable C++ code when most compilers were a mix of C++ARM and catching up to C++98, with C++ compiler specific frameworks being heavily used. The second one was Sun's Distributed Objects Everywhere project being canceled, and the Objective-C code being reborn into the first J2EE proposal. There was nothing else like that for business software other than Smalltalk and later .NET, however most Java vendors were ex-Smalltalkers, and in 2001 .NET was a no-go for anyone that would care about supporting UNIX deployments as well. In 2001, we were moving away from scripting + write extensions into C, into Java, and only pivoted into .NET because being a MSFT partner with access to the "partner eyes only" betas from Microsft before .NET was announced, additionally there was some ideas to move away from UNIX customers. However by 2006, while at Nokia Networks, a strong UNIX shop back then, the large majority of their applications were going into the Rewrite into Java phase.
deleted 2y ago
[deleted]
devsda 2y ago
I wish and I'm sure Rust will get there some day but is there a no-brainer usecase today where it's really important to use Rust, one important enough to overlook the initial learning curve, developer scarcity and evolving ecosystem? If there's a killer open product out there where the primary supported language is Rust(Linux kernel might as well be it someday), or if a big company launches a successful product in Rust then adoption may accelerate. For now its mostly limited to cryptocurrencies, performance critical paths or rewrite of hidden core components but nothing flashy. "Nobody ever gets fired for buying IBM". Unless teams can say the same about their choice of Rust, people are going to be risk averse and prefer using safest choice as long as its good enough.
- llm_trw 2y ago
  [flagged]
  - pdimitar 2y ago
    Nobody is stealing anything, what a weird comment. And the problem with new kernels is how to reuse the huge trove of already-written drivers. Nobody is going to start rewriting everything in any language, be it Rust or any other -- does not matter. That's why the ABI and "please commit to a standard" points are so difficult and thorny in the kernel ecosystem; people want to reuse.
    - llm_trw 2y ago
      Again if it's so great fork the kernel and make it great. People will flock to you if you can manage.
- ttfkam 2y ago
  Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously. Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.
psychoslave 2y ago
I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java. For the latter it’s still kinda of "everybody can write some code that will run everywhere". The former is more like "you can have performance, consistency and correctness in a shallowly-C-like syntax", which is more likely to tease the average HN reader, but probably not the average programmer who is in to earn some descent money or as a way to start before moving up in the businesses hierarchy. And you see there are some people which enthusiast to push Rust into the Linux kernel, while I doubt that in Java projects of similar size there is that much ardor for even introducing it in some part of it, let alone propose a full rewrite.
- Seattle3503 2y ago
  > I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java. I don't think the origin lame was that it would compete for the same segment, but that it would reach the same level of ubiquity. It could do that by opening up a new non-existent segment, eg smart contracts on the block chain. Or it could take a little from multiple domains.
- pyrale 2y ago
  > descent money When you want a decent paycheck, but instead get a descent into computing madness.
  - psychoslave 2y ago
    haha, nice catch, thanks for the smile. :)
sshine 2y ago
> Rust is much more likely to follow Java's trajectory than OCaml's I'd rather compare Rust to Haskell and Kubernetes. Haskell: - Dozens of handfuls of experts open to remote work. - Lots of aspiring juniors who see no way to enter the market. - Most employers are R&D-heavy academic consulting environments. Kubernetes: - Wildly hyped and cherished among people who don't have the complexity to warrant the purchase. - Eventually criticised for being overly complex and suitable only at a certain size and setup. > it's only going to be easier and easier to find Rust developers. I imagine it's never been easier to find Haskell developers and Kubernetes developers, either. Yet, one's wish to code Haskell professionally does not necessarily align with one's market value. It seems like there's a lot more open for Kubernetes, so Rust could go that way. Unlike Haskell, Rust seems to gain industry acceptance.
- pdimitar 2y ago
  Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling. Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created. So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way". Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.
  - sshine 2y ago
    > Rust has stellar tooling I came for the job opportunities. I stayed for the tooling. > Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program I had a similar experience trying to make Haskell's LSP work in test files. After ten years of using Haskell for academic and hobby projects, I still couldn't make the red squigglies go away in test files. With Rust I struggle similarly when dealing with cross-compilation and a complex set of feature flags on Nix. But at least this is not "Hello World!" failing.
acomjean 2y ago
I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. The python scripts of the same vintage have to be reworked because python versions and importantly supporting libraries have changed. This is mainly because Perl hasn’t changed, with the failure of perl6 to launch. But it’s an interesting comparison. I’ll agree Rust will be like like Java.
- adamc 2y ago
  I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though. Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.
  - tadfisher 2y ago
    The real comparison is between Rust and C++, even though folks seem to be pushing Rust for web services and internal tooling. And modern C++ is an absolute monster in terms of complexity, often just dancing around problems that Rust solves pretty elegantly with ownership and lifetimes.
    - pjmlp 2y ago
      However that comparision misses that C++ is reaching 50's, while Rust still isn't allowed to drink.
      - phi-go 2y ago
        What's your point? Doesn't it only matter where things are now, not how long it took to get there? Or is this about more people knowing C++?
- 2y ago
netdevnet 2y ago
The kind of people that recklessly move from shiny language to the newest shiny language in town are the same kind of people that believe that you could kick out a dev writing systems in Java and stick a dev whose experience has only been Haskell and O'Caml and have the new dev hit the ground running
- sshine 2y ago
  I’ve been that guy, and I certainly believe in myself. ;-) I don’t think it’s reckless to have e.g. Haskell or OCaml as your go-to language for a decade, and switch it out with Rust.
pyrale 2y ago
> you have to ask how you will grow and maintain things going forward. The typical answer is "The jobs market will provide". The issue with that method is that you end up competing with everyone and, usually, your company is not the top employer. OTOH, some companies decide to use technology and invest in knowing the community, by hosting events or meetups, by frequently sending their devs to conferences on company time, etc. Usually, the people hired are above average, and are also able to train juniors if the market dries up. These companies typically are the safest in terms of ability to maintain their stack, but have to account for the fact that alienating their existing devs becomes a big risk. The real harm comes for companies that choose niche tooling but believe the market will provide.
- gwd 2y ago
  Right -- you can choose a niche technology, as long as you're willing to commit to the additional costs of doing more training, being involved in the community, and so on. Those additional costs (and/or the risk of not doing so) need to be factored into the decision to use a technology.
stonemetal12 2y ago
If a company chooses non standard tools then they are doing it with the knowledge that they will have to train new hires in it. Random employee using non standard tools without the company making the decision to pivot to embracing it, aka training existing\new employees in that tool, is just making stuff that your company will have to throw away and redo. So XenServer embracing OCaml is nothing like Random Gamdev writing some scripts in Rust without the team deciding to embrace the change.
AnimalMuppet 2y ago
But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers. Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java. Rust may get there. But don't use Java's success to predict Rust's trajectory.
- Keyframe 2y ago
  Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.
  - tcmart14 2y ago
    Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.
    - pjmlp 2y ago
      Apparently there was something to it, otherwise we wouldn't have every other day a WebAssembly startup being upvoted.
geodel 2y ago
> I think Rust is much more likely to follow Java's trajectory than OCaml's: This looks like pipe dream of those Rust devs who usually claim that Rust borrow checker is easiest thing since heating HotPocket in microwave.

by gwd 2y ago

adamc 2y ago

Twenty-four years ago, Python already looked better to me. I maintained a big Perl 5 app. Yuck. The problem wasn't that you couldn't write it, the problem was that you had to be able to read widely differing styles of Perl... and if you wanted to read library code, it was a huge pain. I quit maintaining that system in 2005, and it has barely changed since, from what I'm told. Viability of a language is certainly a consideration, but the characteristics of the language also matter. What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.

sshine 2y ago
> My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise. You can certainly make a case for that being inevitable in some ways: Rust can be written in many ways to address different levels of abstraction, and when you stack those, you can require the reader to know about all of them. If someone gives me a piece of Python code, it can only be hard to understand if the domain is hard (e.g physics) or it is poorly written. In that way, Rust belongs with C++ and Haskell. The abstractions that Rust will introduce over time won’t grow in all directions like with C++ and Haskell (e.g. you won’t get higher-kinded types or GADTs in the next ten years).
pjmlp 2y ago
In 2000, Java was still about doing dancing applets, businesses only started taking Java marketing seriously after two things happened, Hotspot became a thing, making it more appealing than C++ for cross-platform server code, versus dealing with the mess of writing portable C++ code when most compilers were a mix of C++ARM and catching up to C++98, with C++ compiler specific frameworks being heavily used. The second one was Sun's Distributed Objects Everywhere project being canceled, and the Objective-C code being reborn into the first J2EE proposal. There was nothing else like that for business software other than Smalltalk and later .NET, however most Java vendors were ex-Smalltalkers, and in 2001 .NET was a no-go for anyone that would care about supporting UNIX deployments as well. In 2001, we were moving away from scripting + write extensions into C, into Java, and only pivoted into .NET because being a MSFT partner with access to the "partner eyes only" betas from Microsft before .NET was announced, additionally there was some ideas to move away from UNIX customers. However by 2006, while at Nokia Networks, a strong UNIX shop back then, the large majority of their applications were going into the Rewrite into Java phase.

deleted 2y ago

[deleted]

devsda 2y ago

I wish and I'm sure Rust will get there some day but is there a no-brainer usecase today where it's really important to use Rust, one important enough to overlook the initial learning curve, developer scarcity and evolving ecosystem? If there's a killer open product out there where the primary supported language is Rust(Linux kernel might as well be it someday), or if a big company launches a successful product in Rust then adoption may accelerate. For now its mostly limited to cryptocurrencies, performance critical paths or rewrite of hidden core components but nothing flashy. "Nobody ever gets fired for buying IBM". Unless teams can say the same about their choice of Rust, people are going to be risk averse and prefer using safest choice as long as its good enough.

llm_trw 2y ago
[flagged]
- pdimitar 2y ago
  Nobody is stealing anything, what a weird comment. And the problem with new kernels is how to reuse the huge trove of already-written drivers. Nobody is going to start rewriting everything in any language, be it Rust or any other -- does not matter. That's why the ABI and "please commit to a standard" points are so difficult and thorny in the kernel ecosystem; people want to reuse.
  - llm_trw 2y ago
    Again if it's so great fork the kernel and make it great. People will flock to you if you can manage.
ttfkam 2y ago
Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously. Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.

psychoslave 2y ago

I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java. For the latter it’s still kinda of "everybody can write some code that will run everywhere". The former is more like "you can have performance, consistency and correctness in a shallowly-C-like syntax", which is more likely to tease the average HN reader, but probably not the average programmer who is in to earn some descent money or as a way to start before moving up in the businesses hierarchy. And you see there are some people which enthusiast to push Rust into the Linux kernel, while I doubt that in Java projects of similar size there is that much ardor for even introducing it in some part of it, let alone propose a full rewrite.

Seattle3503 2y ago
> I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java. I don't think the origin lame was that it would compete for the same segment, but that it would reach the same level of ubiquity. It could do that by opening up a new non-existent segment, eg smart contracts on the block chain. Or it could take a little from multiple domains.
pyrale 2y ago
> descent money When you want a decent paycheck, but instead get a descent into computing madness.
- psychoslave 2y ago
  haha, nice catch, thanks for the smile. :)

sshine 2y ago

> Rust is much more likely to follow Java's trajectory than OCaml's I'd rather compare Rust to Haskell and Kubernetes. Haskell: - Dozens of handfuls of experts open to remote work. - Lots of aspiring juniors who see no way to enter the market. - Most employers are R&D-heavy academic consulting environments. Kubernetes: - Wildly hyped and cherished among people who don't have the complexity to warrant the purchase. - Eventually criticised for being overly complex and suitable only at a certain size and setup. > it's only going to be easier and easier to find Rust developers. I imagine it's never been easier to find Haskell developers and Kubernetes developers, either. Yet, one's wish to code Haskell professionally does not necessarily align with one's market value. It seems like there's a lot more open for Kubernetes, so Rust could go that way. Unlike Haskell, Rust seems to gain industry acceptance.

pdimitar 2y ago
Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling. Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created. So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way". Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.
- sshine 2y ago
  > Rust has stellar tooling I came for the job opportunities. I stayed for the tooling. > Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program I had a similar experience trying to make Haskell's LSP work in test files. After ten years of using Haskell for academic and hobby projects, I still couldn't make the red squigglies go away in test files. With Rust I struggle similarly when dealing with cross-compilation and a complex set of feature flags on Nix. But at least this is not "Hello World!" failing.

acomjean 2y ago

I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. The python scripts of the same vintage have to be reworked because python versions and importantly supporting libraries have changed. This is mainly because Perl hasn’t changed, with the failure of perl6 to launch. But it’s an interesting comparison. I’ll agree Rust will be like like Java.

adamc 2y ago
I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though. Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.
- tadfisher 2y ago
  The real comparison is between Rust and C++, even though folks seem to be pushing Rust for web services and internal tooling. And modern C++ is an absolute monster in terms of complexity, often just dancing around problems that Rust solves pretty elegantly with ownership and lifetimes.
  - pjmlp 2y ago
    However that comparision misses that C++ is reaching 50's, while Rust still isn't allowed to drink.
    - phi-go 2y ago
      What's your point? Doesn't it only matter where things are now, not how long it took to get there? Or is this about more people knowing C++?
2y ago

netdevnet 2y ago

The kind of people that recklessly move from shiny language to the newest shiny language in town are the same kind of people that believe that you could kick out a dev writing systems in Java and stick a dev whose experience has only been Haskell and O'Caml and have the new dev hit the ground running

sshine 2y ago
I’ve been that guy, and I certainly believe in myself. ;-) I don’t think it’s reckless to have e.g. Haskell or OCaml as your go-to language for a decade, and switch it out with Rust.

pyrale 2y ago

> you have to ask how you will grow and maintain things going forward. The typical answer is "The jobs market will provide". The issue with that method is that you end up competing with everyone and, usually, your company is not the top employer. OTOH, some companies decide to use technology and invest in knowing the community, by hosting events or meetups, by frequently sending their devs to conferences on company time, etc. Usually, the people hired are above average, and are also able to train juniors if the market dries up. These companies typically are the safest in terms of ability to maintain their stack, but have to account for the fact that alienating their existing devs becomes a big risk. The real harm comes for companies that choose niche tooling but believe the market will provide.

gwd 2y ago
Right -- you can choose a niche technology, as long as you're willing to commit to the additional costs of doing more training, being involved in the community, and so on. Those additional costs (and/or the risk of not doing so) need to be factored into the decision to use a technology.

stonemetal12 2y ago

If a company chooses non standard tools then they are doing it with the knowledge that they will have to train new hires in it. Random employee using non standard tools without the company making the decision to pivot to embracing it, aka training existing\new employees in that tool, is just making stuff that your company will have to throw away and redo. So XenServer embracing OCaml is nothing like Random Gamdev writing some scripts in Rust without the team deciding to embrace the change.

AnimalMuppet 2y ago

But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers. Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java. Rust may get there. But don't use Java's success to predict Rust's trajectory.

Keyframe 2y ago
Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.
- tcmart14 2y ago
  Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.
  - pjmlp 2y ago
    Apparently there was something to it, otherwise we wouldn't have every other day a WebAssembly startup being upvoted.

geodel 2y ago

> I think Rust is much more likely to follow Java's trajectory than OCaml's: This looks like pipe dream of those Rust devs who usually claim that Rust borrow checker is easiest thing since heating HotPocket in microwave.