3 ms·

The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side s

by Zababa 5y ago

The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side software. But dune is way harder to use than Cargo and you can often miss libraries. Here's an example of Dark moving away from OCaml to F# https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/, which doesn't have as much this problem because you can use C# stuff. Scala also doesn't suffer as much from it, part of it because it was really popular at some point, and part of it because you can use Java anyways. I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too. I've been thinking for some time that something like Go but based on a ML would fill this "garbage collected Rust" niche quite well. Maybe something built over Rust itself to leverage all the ecosystem? You could write all of the glue code in this language, have access to a large ecosystem of libraries and have an option for high performance code. This would also complement Rust nicely: I know that OCaml has a really fast compiler, which would be a breath of fresh air for the community.

nicoburns 5y ago
I think you're talking about Swift. Alas it doesn't seem to have caught on outside of the Apple ecosystem, so library support isn't great there either. I do agree that language built on top of the Rust ecosystem (kind of like how PHP exposes a lot of C libraries) could make a lot of sense.
- Zababa 5y ago
  I don't think I am talking about Swift. The compilation is slow because of LLVM and you still have to handle cyclic references because of ref counting. As you said too, library support isn't great. I don't know how exactly is the dev experience too, at least outside of XCode. Last time I played a bit with it, adding the language server to VSCode was a bit of a pain. Still, I think Swift is a step in the right direction. I've heard good things about Nim too for this niche but never tried it. I think it'll suffer from the same problem of not being able to leverage an existing ecosystem though.
  - kinjba11 5y ago
    Nim compiles to C (through C?), so at least leveraging the C/C++ ecosystem is straightforward/first class. It is certainly difficult to justify breaking away from the huge established multiple decade ecosystems and standard libraries seen with the JVM/.NET/Python platforms for instance. https://nim-lang.org/docs/backends.html#interfacing https://nim-lang.org/docs/backends.html#interfacing
    - Zababa 5y ago
      OCaml is also pretty good at leveraging the C ecosystem, but that's not what people are looking for in a "garbage collected Rust". If they want something close to C they'll just use Rust. What they're looking for is something easier to write that still looks like Rust and having all the developer experience that Rust has. For this, the Nim ecosystem is way too small and can't leverage an existing platform. The same do apply to OCaml and Swift so it's not a Nim specific problem, it's just that Nim doesn't bring much compared to OCaml.
      - kinjba11 5y ago
        For what it's worth, OCaml is a great under-appreciated language forever dented by ugly (in my opinion) syntax and oddities like different operators for floats and ints. There's a good reason the folks behind the Reason ML fork changed things up. Swift is another great language - forever dented by being tied hand and foot to the Apple holy garden and Objective-C legacy and runtime with memory-related keywords such as 'weak' and 'unowned'. Nim (and perhaps D) are the closest in my mind to the "garbage collected Rust" in that they are not only garbage collected, but they are procedural-oriented, can write highly generic code and macros, and come with near-C performance. Given the "Pythonic Rust" title, another edge Nim has is its semantic whitespace, very Python-esque syntax.
- sitkack 5y ago
  There are/were many less staunch languages that interoperated with Rust in a clean way. * https://gluon-lang.org/ * https://github.com/PistonDevelopers/dyon Rust is waiting for that interior language so that everyone doesn't need to subscribe to the same complexity budget.
  - Zababa 5y ago
    I've looked a bit at Gluon before and it was a bit too much like Haskell for what I imagined. I don't think using monads for IO is a good idea if you want to keep the Rust approach of pragmatism first. I don't know anything about dyon but a quick look tells me it's more meant for game development.
pjmlp 5y ago
> I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too. F# on Visual Studio + .NET ecosystem (which includes C++/CLI, C# and first class support for COM/UWP) is worse than Rust?!?
- Zababa 5y ago
  How many of those things work well on Linux/MacOS? Rust, Cargo, rust-analyzer, VSCode work on every major plateform. You also have access to the .NET ecosystem but it's not as easy as the Rust ecosystem since most of the packages are C#, not F#, and idiomatic C# and idiomatic F# are quite different. In terms of resources too, F# is quite poor compared to Rust. Edit: another thing, compiling to native is not really a first class citizen on .NET. That makes it a bit worse to distribute tools compared to Rust, Go or OCaml. Scala also suffer from this.
  - pjmlp 5y ago
    F# can just use C#, that is the magic of CLR. VScode F# plugin and Rider also have much more resources into them. Then 20 years of production code to chose from.
    - Zababa 5y ago
      You can use C# from F#, of course, but then you can run into issues with nulls and things like that. There's a reason every programming language has their own implementation of JSON/XML parsing, HTTP and things like that: offering an idiomatic API is important. Last time I use the VSCode F# plugin (around a year ago), the experience was strictly worse than rust-analyzer. The compiler errors are also not as good. I've never used Rider so I can't comment on that. You're right about the 20 years of production code for C#. NuGet lists 241418 packages compared to crates.io 61579 crates, and there's a good chance most of them are more mature than the Rust alternatives. However that's C#, not F#, and I doubt F# represents more than 10% of the packages. That's still better than doing it yourself if there's no package or writing bindings to C though. I still think F# and Scala are solid choices if you want a functional language today, but it's not the "garbage collected Rust" ideal I wish we had.

by Zababa 5y ago

nicoburns 5y ago

I think you're talking about Swift. Alas it doesn't seem to have caught on outside of the Apple ecosystem, so library support isn't great there either. I do agree that language built on top of the Rust ecosystem (kind of like how PHP exposes a lot of C libraries) could make a lot of sense.

Zababa 5y ago
I don't think I am talking about Swift. The compilation is slow because of LLVM and you still have to handle cyclic references because of ref counting. As you said too, library support isn't great. I don't know how exactly is the dev experience too, at least outside of XCode. Last time I played a bit with it, adding the language server to VSCode was a bit of a pain. Still, I think Swift is a step in the right direction. I've heard good things about Nim too for this niche but never tried it. I think it'll suffer from the same problem of not being able to leverage an existing ecosystem though.
- kinjba11 5y ago
  Nim compiles to C (through C?), so at least leveraging the C/C++ ecosystem is straightforward/first class. It is certainly difficult to justify breaking away from the huge established multiple decade ecosystems and standard libraries seen with the JVM/.NET/Python platforms for instance. https://nim-lang.org/docs/backends.html#interfacing https://nim-lang.org/docs/backends.html#interfacing
  - Zababa 5y ago
    OCaml is also pretty good at leveraging the C ecosystem, but that's not what people are looking for in a "garbage collected Rust". If they want something close to C they'll just use Rust. What they're looking for is something easier to write that still looks like Rust and having all the developer experience that Rust has. For this, the Nim ecosystem is way too small and can't leverage an existing platform. The same do apply to OCaml and Swift so it's not a Nim specific problem, it's just that Nim doesn't bring much compared to OCaml.
    - kinjba11 5y ago
      For what it's worth, OCaml is a great under-appreciated language forever dented by ugly (in my opinion) syntax and oddities like different operators for floats and ints. There's a good reason the folks behind the Reason ML fork changed things up. Swift is another great language - forever dented by being tied hand and foot to the Apple holy garden and Objective-C legacy and runtime with memory-related keywords such as 'weak' and 'unowned'. Nim (and perhaps D) are the closest in my mind to the "garbage collected Rust" in that they are not only garbage collected, but they are procedural-oriented, can write highly generic code and macros, and come with near-C performance. Given the "Pythonic Rust" title, another edge Nim has is its semantic whitespace, very Python-esque syntax.
sitkack 5y ago
There are/were many less staunch languages that interoperated with Rust in a clean way. * https://gluon-lang.org/ * https://github.com/PistonDevelopers/dyon Rust is waiting for that interior language so that everyone doesn't need to subscribe to the same complexity budget.
- Zababa 5y ago
  I've looked a bit at Gluon before and it was a bit too much like Haskell for what I imagined. I don't think using monads for IO is a good idea if you want to keep the Rust approach of pragmatism first. I don't know anything about dyon but a quick look tells me it's more meant for game development.

pjmlp 5y ago

> I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too. F# on Visual Studio + .NET ecosystem (which includes C++/CLI, C# and first class support for COM/UWP) is worse than Rust?!?

Zababa 5y ago
How many of those things work well on Linux/MacOS? Rust, Cargo, rust-analyzer, VSCode work on every major plateform. You also have access to the .NET ecosystem but it's not as easy as the Rust ecosystem since most of the packages are C#, not F#, and idiomatic C# and idiomatic F# are quite different. In terms of resources too, F# is quite poor compared to Rust. Edit: another thing, compiling to native is not really a first class citizen on .NET. That makes it a bit worse to distribute tools compared to Rust, Go or OCaml. Scala also suffer from this.
- pjmlp 5y ago
  F# can just use C#, that is the magic of CLR. VScode F# plugin and Rider also have much more resources into them. Then 20 years of production code to chose from.
  - Zababa 5y ago
    You can use C# from F#, of course, but then you can run into issues with nulls and things like that. There's a reason every programming language has their own implementation of JSON/XML parsing, HTTP and things like that: offering an idiomatic API is important. Last time I use the VSCode F# plugin (around a year ago), the experience was strictly worse than rust-analyzer. The compiler errors are also not as good. I've never used Rider so I can't comment on that. You're right about the 20 years of production code for C#. NuGet lists 241418 packages compared to crates.io 61579 crates, and there's a good chance most of them are more mature than the Rust alternatives. However that's C#, not F#, and I doubt F# represents more than 10% of the packages. That's still better than doing it yourself if there's no package or writing bindings to C though. I still think F# and Scala are solid choices if you want a functional language today, but it's not the "garbage collected Rust" ideal I wish we had.