5 ms·

All true but it’s not as productive as a GC language from the ML family. If you don’t need the performance / latency guarantees I’m not sure it’s worth it.

flooow 3y ago
The way I have seen it explained before: Rust is not the perfect applications language, but there actually aren't any good mainstream applications languages out there, so Rust is perhaps the best we've got. What I want: * Powerful, strict typesystem (typeclasses, sum types, type-inference, closures) * Constrained mutation, no 'spooky action at a distance' * Safe multithreading * Fast * Memory-safe * Native binaries * Large, deep ecosystem * Great tooling * Jobs Rust comes closer than most.
- kaba0 3y ago
  Funnily enough, Haskell also fulfills all the listed qualities.
  - codethief 3y ago
    How many jobs are out there where they expect you to know Haskell?
    - pjmlp 3y ago
      More than for Rust, given its age.
      - flooow 3y ago
        Not sure that this is true now, but willing to bet my career that this won't be true in 3 years.
        pjmlp 3y ago
        Depends on how much people feel like writing userspace code with the usability of a language designed for kernel, drivers and GPPGU programming. https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
  - flooow 3y ago
    That is not a coincidence :) I like Haskell a lot but at this point I am willing to bet that I will never be paid to write it. It fells like community of 'people like me' have collectively decided that Rust, not Haskell, is their best bet for a better life, and I'm fine with that.
- pharmakom 3y ago
  Rust is awesome but the ecosystem and job market are tiny.
bo-tato 3y ago
> a GC language from the ML family. What other option is there? I thought the same and wanted a higher-level GC'd language than rust, and played some with Ocaml, Haskell and F#. In theory they should be more productive and I'm sure are for things like compilers and parsers where they have top-quality libraries, but for most things I got the impression that even if I took the time to learn well one of those languages, the quality of libraries and documentation and tooling is so far ahead in rust that it more than makes up for the productivity hit of rust making you concern yourself more with low-level details
- jacquesm 3y ago
  Erlang / Elixir.
  - bo-tato 3y ago
    I tried elixir and enjoyed it. I'm don't have strong feelings either way on static vs dynamic typing, I think the current craze for static typing is a lot because of people's experience with javascript vs typescript. With elixir I of course had runtime type errors but trivial ones that show up on the first run, I don't think I had any hard to find bugs or bugs that surface later that ML typing would've caught. I'd absolutely pick it over rust for web backends, but I do very little of that, I'm mostly writing cli utilities on unix. I've been experimenting with common lisp lately and it's a lot of fun, as fast to prototype with as python (when it has the libraries you need), performance around the level of java or go, great development environment if you use emacs, instant startup time for cli utilities unlike beam or jvm. I think if it was made easier to make and cross-compile fully staticly linked binaries, and it get's something like maturin for python or rustler for elixir to have easier access to bigger ecosystem when needed it'd be great for my uses but at the moment I can't use it for much
    - ssokolow 3y ago
      In my case, it's because I've been burned by Python's maintainability issues in ways MyPy isn't sufficient to fix. It's not just Rust's type system, but: 1. Unlike with Haskell, the Rust compatibility promise has set the tone for how the ecosystem approaches API breakage. 2. Go-like "statically link everything into a single binary" compilation means that "just keep using the old build until things are fixed" is a valid answer to "an upgrade broke the buld process". 3. Rust's type system enables design patterns like the typestate pattern, for encoding as many invariants in the type system for proving at compile time as possible. 4. Rust's design prioritizes removing the need for global reasoning about program behaviour. Same reason I recently spent $10 on a used copy of the O'Reilly lex & yacc book to learn the warts of LR parsing. I plan to write my parsers via something like LALRPOP or grmtools instead of using nom (parser combinators) or pest (PEG parsing), which are currently more popular in the Rust world. (As with borrow-checking errors, shift/reduce and reduce/reduce conflicts aren't the bug, they're the feature. I read an article about how LR parsing allows the most detection of ambiguities in the grammar at compile time. Cry in the dojo, laugh on the battlefield.) I'd rather pay up-front to avoid the stress of having a Sword of Damocles hanging over my head and feeling satisfied with Rust takes FAR less time than either burning out trying to replicate its type system in unit tests or playing bug whac-a-mole over the lifetime of the project.

flooow 3y ago

The way I have seen it explained before: Rust is not the perfect applications language, but there actually aren't any good mainstream applications languages out there, so Rust is perhaps the best we've got. What I want: * Powerful, strict typesystem (typeclasses, sum types, type-inference, closures) * Constrained mutation, no 'spooky action at a distance' * Safe multithreading * Fast * Memory-safe * Native binaries * Large, deep ecosystem * Great tooling * Jobs Rust comes closer than most.

kaba0 3y ago
Funnily enough, Haskell also fulfills all the listed qualities.
- codethief 3y ago
  How many jobs are out there where they expect you to know Haskell?
  - pjmlp 3y ago
    More than for Rust, given its age.
    - flooow 3y ago
      Not sure that this is true now, but willing to bet my career that this won't be true in 3 years.
      - pjmlp 3y ago
        Depends on how much people feel like writing userspace code with the usability of a language designed for kernel, drivers and GPPGU programming. https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
- flooow 3y ago
  That is not a coincidence :) I like Haskell a lot but at this point I am willing to bet that I will never be paid to write it. It fells like community of 'people like me' have collectively decided that Rust, not Haskell, is their best bet for a better life, and I'm fine with that.
pharmakom 3y ago
Rust is awesome but the ecosystem and job market are tiny.

bo-tato 3y ago

> a GC language from the ML family. What other option is there? I thought the same and wanted a higher-level GC'd language than rust, and played some with Ocaml, Haskell and F#. In theory they should be more productive and I'm sure are for things like compilers and parsers where they have top-quality libraries, but for most things I got the impression that even if I took the time to learn well one of those languages, the quality of libraries and documentation and tooling is so far ahead in rust that it more than makes up for the productivity hit of rust making you concern yourself more with low-level details

jacquesm 3y ago
Erlang / Elixir.
- bo-tato 3y ago
  I tried elixir and enjoyed it. I'm don't have strong feelings either way on static vs dynamic typing, I think the current craze for static typing is a lot because of people's experience with javascript vs typescript. With elixir I of course had runtime type errors but trivial ones that show up on the first run, I don't think I had any hard to find bugs or bugs that surface later that ML typing would've caught. I'd absolutely pick it over rust for web backends, but I do very little of that, I'm mostly writing cli utilities on unix. I've been experimenting with common lisp lately and it's a lot of fun, as fast to prototype with as python (when it has the libraries you need), performance around the level of java or go, great development environment if you use emacs, instant startup time for cli utilities unlike beam or jvm. I think if it was made easier to make and cross-compile fully staticly linked binaries, and it get's something like maturin for python or rustler for elixir to have easier access to bigger ecosystem when needed it'd be great for my uses but at the moment I can't use it for much
  - ssokolow 3y ago
    In my case, it's because I've been burned by Python's maintainability issues in ways MyPy isn't sufficient to fix. It's not just Rust's type system, but: 1. Unlike with Haskell, the Rust compatibility promise has set the tone for how the ecosystem approaches API breakage. 2. Go-like "statically link everything into a single binary" compilation means that "just keep using the old build until things are fixed" is a valid answer to "an upgrade broke the buld process". 3. Rust's type system enables design patterns like the typestate pattern, for encoding as many invariants in the type system for proving at compile time as possible. 4. Rust's design prioritizes removing the need for global reasoning about program behaviour. Same reason I recently spent $10 on a used copy of the O'Reilly lex & yacc book to learn the warts of LR parsing. I plan to write my parsers via something like LALRPOP or grmtools instead of using nom (parser combinators) or pest (PEG parsing), which are currently more popular in the Rust world. (As with borrow-checking errors, shift/reduce and reduce/reduce conflicts aren't the bug, they're the feature. I read an article about how LR parsing allows the most detection of ambiguities in the grammar at compile time. Cry in the dojo, laugh on the battlefield.) I'd rather pay up-front to avoid the stress of having a Sword of Damocles hanging over my head and feeling satisfied with Rust takes FAR less time than either burning out trying to replicate its type system in unit tests or playing bug whac-a-mole over the lifetime of the project.