3 ms·

> 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 ex

by 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.
  - pdimitar 2y ago
    Well to be fair to Rust, Nix can drive anyone crazy. I tried that one too and figured they sniffed way too much of their own drugs, if you pardon the expression. In the meantime I learned `just` in 10 minutes. Sure, not the same usage patterns, I get that of course, and I love the idea of Nix but they could have went about it very differently with a much better UX / DX... and they refused. Side topic though, sorry for the digression. Main point was that if you use Rust normally without any weird and not fully accounted for wrappers then everything works fine. I just fired Neovim in a personal project I haven't touched in a year -- 20-30 seconds of LSP compiling stuff and I saw my project-wide compiler warnings immediately after.
- rixed 2y ago
  I do have one ear for that argument that "everything ought to be simpler". But what I've observed over and over is that many systems tends to become more complex as the result of people wanting to make them more newbie friendly. That's certainly true of the last 10 years of Ocaml tooling evolution.
  - pdimitar 2y ago
    I guess you could argue both ways and it depends on your starting point. I did not mean to say "make it newbie friendly", I meant "I want adding a dependency to my project to be a 10 seconds job, not a week-long endeavor". If we both start from that point then I think we might find a common ground.
    - rixed 2y ago
      Yes it does very much depend on your starting point. For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install" This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.
      - pdimitar 2y ago
        Yep, it's about your background. I moved away from makefiles long ago and I don't regret it, for a multitude of reasons that are well explained in many places. `cargo add ...` is great and I wish every language offered a tool like that.
        rixed 2y ago
        Even when i use cargo or go or node, make is still needed to build everything that's not just code.

by sshine 2y ago

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.
- pdimitar 2y ago
  Well to be fair to Rust, Nix can drive anyone crazy. I tried that one too and figured they sniffed way too much of their own drugs, if you pardon the expression. In the meantime I learned `just` in 10 minutes. Sure, not the same usage patterns, I get that of course, and I love the idea of Nix but they could have went about it very differently with a much better UX / DX... and they refused. Side topic though, sorry for the digression. Main point was that if you use Rust normally without any weird and not fully accounted for wrappers then everything works fine. I just fired Neovim in a personal project I haven't touched in a year -- 20-30 seconds of LSP compiling stuff and I saw my project-wide compiler warnings immediately after.
rixed 2y ago
I do have one ear for that argument that "everything ought to be simpler". But what I've observed over and over is that many systems tends to become more complex as the result of people wanting to make them more newbie friendly. That's certainly true of the last 10 years of Ocaml tooling evolution.
- pdimitar 2y ago
  I guess you could argue both ways and it depends on your starting point. I did not mean to say "make it newbie friendly", I meant "I want adding a dependency to my project to be a 10 seconds job, not a week-long endeavor". If we both start from that point then I think we might find a common ground.
  - rixed 2y ago
    Yes it does very much depend on your starting point. For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install" This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.
    - pdimitar 2y ago
      Yep, it's about your background. I moved away from makefiles long ago and I don't regret it, for a multitude of reasons that are well explained in many places. `cargo add ...` is great and I wish every language offered a tool like that.
      - rixed 2y ago
        Even when i use cargo or go or node, make is still needed to build everything that's not just code.