5 ms·

The title is not a surprise, based on the previous post. The one surprise is that he seriously considered Rust. > "you'll never believe just how much a Garbage

The title is not a surprise, based on the previous post. The one surprise is that he seriously considered Rust. > "you'll never believe just how much a Garbage Collector does for you!" Of course, that's why it's hard to see someone moving from OCaml to Rust for any reason other than wanting to use Rust.

pjmlp 6y ago
As mentioned elsewhere, I believe that automatic memory management + affine types will win in what concerns masses adoption. Rust has been the catalyst to force language designers to look more seriously into affine types, but its use can only be justified in "no way GC/RC" scenarios like MISRA.
- mpweiher 6y ago
  To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.
- darksaints 6y ago
  Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult. The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables. Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system. F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others. Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison. OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices. Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists. I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.
  - vips7L 6y ago
    The state of natively compiled GC'd languages is actually pretty bad, at least ones with an ecosystem/job opportunities. You either have to run into the same problem as dark when it comes to libraries and ecosystem (ocaml, haskell, D, etc), use go and give up any nice language features, or run on a VM and deal with all the issues of packaging/weight (clr, jvm).
    - pjmlp 6y ago
      When packaged alongside the binary, VM for all purposes is just the language runtime,e.g. natively compiled Java.
      - vips7L 6y ago
        I just don't think natively compiled Java is there yet. It's not trivial to get it working and the ecosystem isn't ready for it yet. There are certain things that just work (i.e. quarkus, which I have a web service running on 13 mb of ram), but I have never been able to successfully compile to native on my own because of library dependencies. Getting things like Weld or H2 to work is pretty difficult.
        pjmlp 6y ago
        It is there since 2000. AOT compilation has been a feature of most commercial JDKs, specially the ones targeted at embedded development like PTC and Aicas.
    - aphexairlines 6y ago
      jlink potentially helps with weight.
  - hajile 6y ago
    Don't forget SML. A wonderful, simple language with great compilers and multithreading, but little tooling I'd library support.
- discardable_dan 6y ago
  Overall, I think the big win for Rust is when you need low-level, low-cost, low-memory, high-performance applications, at the cost of anything else. Rust is a great replacement for low-level C. Unfortunately, those are not the features that you care about most in a compiler. In a compiler, your priorities are ease of extension, ease of specification, and ease of transformation. The last thing you want in a compiler language is to worry about ownership when trying to implement expression-rewriting optimizations. Conversely, OCaml is excellent at these things.
throwaway894345 6y ago
That's a pretty weird takeaway considering the long and detailed post on OCaml's issues that motivated a full rewrite: https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/ > One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors. In whatever case, it appears that the author's preference was F# > Rust > OCaml. I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc). And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).
- whimsicalism 6y ago
  > OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc). I think this is unfair and OCaml has a lot going for itself. The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside. To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
  - throwaway894345 6y ago
    > The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside. No one is arguing that this is a downside. The downside is that there aren’t many people who care about making useful software, or at least there is a relative dearth of content devoted to that end. > To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler. I actually agree with this, but as much as I love a good type system, it’s gravy. I can ship software with Go because it has a decent runtime, tooling, ecosystem, learning curve, mindshare, etc even despite its simplistic type system; however, it’s much harder to do the same in OCaml. Also, there are languages like Rust with great type systems and concern about the more ruggedly practical concerns of software development.
metajack 6y ago
One reason to use Rust is speed. For example https://www.phoronix.com/scan.php?page=news_item&px=Facebook-Rust-HHVM https://www.phoronix.com/scan.php?page=news_item&px=Facebook... Of course, not all projects have this as a high order concern, but some do, and it can make sense to use Rust for those.
- sbelskie 6y ago
  I don’t think dotnet is faster than rust or anything overall, but ASP.NET Core is 6th is the techempower composite rankings and first or second I believe in the plain text benchmark. This is excluding the large amount of performance work that has gone into the soon to be released .NET 5.
  - vlang1dot0 6y ago
    dotnet and Rust are essentially neck and neck on plain text. On any benchmark that actually does work though, dotnet is nowhere to be found (less than half the performance of actix).
    - sbelskie 6y ago
      Yea, actix is definitely faster than ASP.NET Core and in many benchmarks it is 2x performance wise. My only point really was that ASP.NET core offers better performance compared to almost any other widely used web framework out there. Additionally, performance improvements have and continue to be a focus, with steady progress to show for it.
- StreamBright 6y ago
  This does not mean much without the context. On the top, it is usually the libraries where most of the speed is wasted. In Java you can create HFT programms yet an average Hadoop project is 10 - 50 times slower in terms of latency for a specific operation. It is not a problem with the JVM of Java as a language as much it is a problem with code quality in user libraries.
- fulafel 6y ago

pjmlp 6y ago

As mentioned elsewhere, I believe that automatic memory management + affine types will win in what concerns masses adoption. Rust has been the catalyst to force language designers to look more seriously into affine types, but its use can only be justified in "no way GC/RC" scenarios like MISRA.

mpweiher 6y ago
To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.
darksaints 6y ago
Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult. The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables. Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system. F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others. Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison. OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices. Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists. I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.
- vips7L 6y ago
  The state of natively compiled GC'd languages is actually pretty bad, at least ones with an ecosystem/job opportunities. You either have to run into the same problem as dark when it comes to libraries and ecosystem (ocaml, haskell, D, etc), use go and give up any nice language features, or run on a VM and deal with all the issues of packaging/weight (clr, jvm).
  - pjmlp 6y ago
    When packaged alongside the binary, VM for all purposes is just the language runtime,e.g. natively compiled Java.
    - vips7L 6y ago
      I just don't think natively compiled Java is there yet. It's not trivial to get it working and the ecosystem isn't ready for it yet. There are certain things that just work (i.e. quarkus, which I have a web service running on 13 mb of ram), but I have never been able to successfully compile to native on my own because of library dependencies. Getting things like Weld or H2 to work is pretty difficult.
      - pjmlp 6y ago
        It is there since 2000. AOT compilation has been a feature of most commercial JDKs, specially the ones targeted at embedded development like PTC and Aicas.
  - aphexairlines 6y ago
    jlink potentially helps with weight.
- hajile 6y ago
  Don't forget SML. A wonderful, simple language with great compilers and multithreading, but little tooling I'd library support.
discardable_dan 6y ago
Overall, I think the big win for Rust is when you need low-level, low-cost, low-memory, high-performance applications, at the cost of anything else. Rust is a great replacement for low-level C. Unfortunately, those are not the features that you care about most in a compiler. In a compiler, your priorities are ease of extension, ease of specification, and ease of transformation. The last thing you want in a compiler language is to worry about ownership when trying to implement expression-rewriting optimizations. Conversely, OCaml is excellent at these things.

throwaway894345 6y ago

That's a pretty weird takeaway considering the long and detailed post on OCaml's issues that motivated a full rewrite: https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/ > One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors. In whatever case, it appears that the author's preference was F# > Rust > OCaml. I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc). And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).

whimsicalism 6y ago
> OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc). I think this is unfair and OCaml has a lot going for itself. The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside. To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
- throwaway894345 6y ago
  > The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside. No one is arguing that this is a downside. The downside is that there aren’t many people who care about making useful software, or at least there is a relative dearth of content devoted to that end. > To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler. I actually agree with this, but as much as I love a good type system, it’s gravy. I can ship software with Go because it has a decent runtime, tooling, ecosystem, learning curve, mindshare, etc even despite its simplistic type system; however, it’s much harder to do the same in OCaml. Also, there are languages like Rust with great type systems and concern about the more ruggedly practical concerns of software development.

metajack 6y ago

One reason to use Rust is speed. For example https://www.phoronix.com/scan.php?page=news_item&px=Facebook-Rust-HHVM https://www.phoronix.com/scan.php?page=news_item&px=Facebook... Of course, not all projects have this as a high order concern, but some do, and it can make sense to use Rust for those.

sbelskie 6y ago
I don’t think dotnet is faster than rust or anything overall, but ASP.NET Core is 6th is the techempower composite rankings and first or second I believe in the plain text benchmark. This is excluding the large amount of performance work that has gone into the soon to be released .NET 5.
- vlang1dot0 6y ago
  dotnet and Rust are essentially neck and neck on plain text. On any benchmark that actually does work though, dotnet is nowhere to be found (less than half the performance of actix).
  - sbelskie 6y ago
    Yea, actix is definitely faster than ASP.NET Core and in many benchmarks it is 2x performance wise. My only point really was that ASP.NET core offers better performance compared to almost any other widely used web framework out there. Additionally, performance improvements have and continue to be a focus, with steady progress to show for it.
StreamBright 6y ago
This does not mean much without the context. On the top, it is usually the libraries where most of the speed is wasted. In Java you can create HFT programms yet an average Hadoop project is 10 - 50 times slower in terms of latency for a specific operation. It is not a problem with the JVM of Java as a language as much it is a problem with code quality in user libraries.
fulafel 6y ago