6 ms·

Man, if developing programming languages was this easy, we should have done it years ago!

by zyxzkz 10y ago

lmm 10y ago
We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.
- PeCaN 10y ago
  They were all garbage collected, which is a dealbreaker for some applications. Rust aims to fit that niche (though if the Rust Evangelism Strike Force is to be believed, Rust fits every niche). Substructural type systems akin to Rust's affine types have been relegated to research for a while.
- kod 10y ago
  Pretty sure F# adoption dwarfs rust.
  - bluejekyll 10y ago
    Purely out of my own curiosity, do you know how popular F# is on non-windows platforms?
  - geodel 10y ago
    Right. Though I checked in Google trends and found Rust to F# interest went from 1/40 to 2/3 in 5 years or so. I think Rust will become more popular in next 2 years.
- munin 10y ago
  Memory management? Every ML implementation I know about uses GC, which is frequently just too slow. Along with many other reasons (http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html)
  - dbaupp 10y ago
    In the context of this discussion, a lot of those reasons are... idiosyncratic, and/or apply to Rust too.
- e12e 10y ago
  Also: Ada.
  - SkyMarshal 10y ago
    This is the real comparison, the only other systems language besides Rust that provides both safety and manual memory management. Ada does it via Access Types: https://en.wikibooks.org/wiki/Ada_Programming/Types/access#What.27s_an_Access_Type.3F https://en.wikibooks.org/wiki/Ada_Programming/Types/access#W...
- throwaway91111 10y ago
  Memory management generally make them unviable for systems coding languages.
  - pjmlp 10y ago
    There is more to systems coding than writing OSes, compilers and linkers for example. There having a GC is perfectly fine.
- jeffdavis 10y ago
  It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance. If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a and get the entire Haskell runtime, starting threads and doing GC and sending and catching signals. I tried implementing a handler in postgresql so that you could write user-defined functions in Haskell. I made little progress, even with help on IRC and elsewhere. Any non-trivial function would need to define its own types and use some libraries, but it was far from clear how to do that and the best advice I got was to dig into ghci and try to use some ideas from that. I started down that path, ran into runtime issues, and that was the last straw and I ran out of steam. And that was only to get the most basic functionality: call into haskell to do some computation and return.
  - Ericson2314 10y ago
    Honestly for most programmers, no GC is a red herring.
    - nostrademons 10y ago
      That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market. Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still beholden to backwards-compatibility, which makes it unable to adopt several of Rust's more interesting features.)
      - tom_mellior 10y ago
        > Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage. Honestly, if Rust is to become popular, it needs (a) to get rid of this elitist "we are awesome systems programmers" mindset, and (b) a good, optional way to use a GC where it makes sense, with good support for migrating away from it (i.e., by giving you a list of "I cannot determine the lifetime of this object, so it will be allocated on the GC heap" diagnostics on request). Good cases can be made for having a no-GC mode, but having it exclusively is just premature optimization.

Man, if developing programming languages was this easy, we should have done it years ago!

by zyxzkz 10y ago

Man, if developing programming languages was this easy, we should have done it years ago!

lmm 10y ago

We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.

PeCaN 10y ago
They were all garbage collected, which is a dealbreaker for some applications. Rust aims to fit that niche (though if the Rust Evangelism Strike Force is to be believed, Rust fits every niche). Substructural type systems akin to Rust's affine types have been relegated to research for a while.
kod 10y ago
Pretty sure F# adoption dwarfs rust.
- bluejekyll 10y ago
  Purely out of my own curiosity, do you know how popular F# is on non-windows platforms?
- geodel 10y ago
  Right. Though I checked in Google trends and found Rust to F# interest went from 1/40 to 2/3 in 5 years or so. I think Rust will become more popular in next 2 years.
munin 10y ago
Memory management? Every ML implementation I know about uses GC, which is frequently just too slow. Along with many other reasons (http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html)
- dbaupp 10y ago
  In the context of this discussion, a lot of those reasons are... idiosyncratic, and/or apply to Rust too.
e12e 10y ago
Also: Ada.
- SkyMarshal 10y ago
  This is the real comparison, the only other systems language besides Rust that provides both safety and manual memory management. Ada does it via Access Types: https://en.wikibooks.org/wiki/Ada_Programming/Types/access#What.27s_an_Access_Type.3F https://en.wikibooks.org/wiki/Ada_Programming/Types/access#W...
throwaway91111 10y ago
Memory management generally make them unviable for systems coding languages.
- pjmlp 10y ago
  There is more to systems coding than writing OSes, compilers and linkers for example. There having a GC is perfectly fine.
jeffdavis 10y ago
It's about the runtime. I think that's probably the most important reason, even more so than memory management or performance. If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a and get the entire Haskell runtime, starting threads and doing GC and sending and catching signals. I tried implementing a handler in postgresql so that you could write user-defined functions in Haskell. I made little progress, even with help on IRC and elsewhere. Any non-trivial function would need to define its own types and use some libraries, but it was far from clear how to do that and the best advice I got was to dig into ghci and try to use some ideas from that. I started down that path, ran into runtime issues, and that was the last straw and I ran out of steam. And that was only to get the most basic functionality: call into haskell to do some computation and return.
- Ericson2314 10y ago
  Honestly for most programmers, no GC is a red herring.
  - nostrademons 10y ago
    That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market. Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still beholden to backwards-compatibility, which makes it unable to adopt several of Rust's more interesting features.)
    - tom_mellior 10y ago
      > Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage. Honestly, if Rust is to become popular, it needs (a) to get rid of this elitist "we are awesome systems programmers" mindset, and (b) a good, optional way to use a GC where it makes sense, with good support for migrating away from it (i.e., by giving you a list of "I cannot determine the lifetime of this object, so it will be allocated on the GC heap" diagnostics on request). Good cases can be made for having a no-GC mode, but having it exclusively is just premature optimization.