5 ms·

I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Ru

I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Rust, but I rarely can afford to trade off on Go's productivity for Rust's performance and safety.

lmm 7y ago
What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.
- wyatwerp 7y ago
  Indeed! For example, it is amazing how small Poly/ML is for a type-inferred multi-threaded language.
- yawn 7y ago
  Not the grandparent, but... OCaml: multicore, standard library situation (which one?) is a mess, adoption. F#: Have to deal with null and lack of ADTs when you interact with .NET (or JS for Fable) standard lib. The tooling situation in F# has been a mess since .NET Core, especially in Linux. Treated as a 2nd class citizen by MS.
  - msvan 7y ago
    Multicore OCaml is actually making promising progress, but I agree that the standard library situation is a little bit unfortunate.
    - ynnn 7y ago
      Sadly, that's what I've been hearing for at least 5 years.
  - akra 7y ago
    I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.
- Hermitian909 7y ago
  As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what you want to hear when you're just trying to set up your first server. Documentation is, in general, bad. Most packages just give a list of function signatures. The community is small, academic, and often French.
  - xvilka 7y ago
    Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).
    - p0nce 7y ago
      You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.
      - wyatwerp 7y ago
        The reference compiler is as free-standing as OCaml's because it too has its own back-end. Its front-end is shared with the other 2 back-ends: feeds the ubiquitous LLVM in LDC, and is included as a supported front-end in GCC since version 9.1. Anyway, there is no way you'd give up ML-tradition pattern-matching; D doesn't have it.
        p0nce 7y ago
        Well engineering decision are tradeoffs, using D i've never missed pattern-matching and I have used ocaml before.
- wtetzner 7y ago
  I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project. The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at least didn't) without a lot of extra work, and it seemed like most packages were designed only for unixish OS's. There are projects where I've used Rust instead of OCaml, even though I'd have preferred to use OCaml, simply because the infrastructure is so much better and easier to use for Rust.
  - msvan 7y ago
    Esy (https://esy.sh/ https://esy.sh/) has completely solved the first problem, fwiw.
    - wtetzner 7y ago
      Thank you! I'll try it out.
    - weberc2 7y ago
      This is a huge step in making OCaml more approachable. I get the feeling that there are quite a few of these modernizations around, but you have to know about them up front in order to hit the happy path. Would be great if there was some sort of "OCaml Happy Path" repo that laid out all of the right tools to use to be successful right off the bat. Sort of on the subject, Reason would be great but last I checked it utterly neglected its native compilation story--it advertised native compilation but every time I ran into an issue the Reason community would tell me that OCaml support was broken and I should use Node. Excited for the improvements to be sure!
e12e 7y ago
> "Go with generics and enums and Cargo" Isn't that d-lang?
eikenberry 7y ago
From the looks of things you'll probably get the Go you want first. The only thing missing from the roadmap are enums and there are a few Go2 proposals for them.
- weberc2 7y ago
  Maybe, albeit I'm concerned that the Go team might ship some broken version of generics or enums that we'll be stuck with for years and years. I think that would be strictly worse than no generics or enums. I hope they think holistically about the problem.

lmm 7y ago

What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.

wyatwerp 7y ago
Indeed! For example, it is amazing how small Poly/ML is for a type-inferred multi-threaded language.
yawn 7y ago
Not the grandparent, but... OCaml: multicore, standard library situation (which one?) is a mess, adoption. F#: Have to deal with null and lack of ADTs when you interact with .NET (or JS for Fable) standard lib. The tooling situation in F# has been a mess since .NET Core, especially in Linux. Treated as a 2nd class citizen by MS.
- msvan 7y ago
  Multicore OCaml is actually making promising progress, but I agree that the standard library situation is a little bit unfortunate.
  - ynnn 7y ago
    Sadly, that's what I've been hearing for at least 5 years.
- akra 7y ago
  I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.
Hermitian909 7y ago
As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what you want to hear when you're just trying to set up your first server. Documentation is, in general, bad. Most packages just give a list of function signatures. The community is small, academic, and often French.
- xvilka 7y ago
  Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).
  - p0nce 7y ago
    You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.
    - wyatwerp 7y ago
      The reference compiler is as free-standing as OCaml's because it too has its own back-end. Its front-end is shared with the other 2 back-ends: feeds the ubiquitous LLVM in LDC, and is included as a supported front-end in GCC since version 9.1. Anyway, there is no way you'd give up ML-tradition pattern-matching; D doesn't have it.
      - p0nce 7y ago
        Well engineering decision are tradeoffs, using D i've never missed pattern-matching and I have used ocaml before.
wtetzner 7y ago
I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project. The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at least didn't) without a lot of extra work, and it seemed like most packages were designed only for unixish OS's. There are projects where I've used Rust instead of OCaml, even though I'd have preferred to use OCaml, simply because the infrastructure is so much better and easier to use for Rust.
- msvan 7y ago
  Esy (https://esy.sh/ https://esy.sh/) has completely solved the first problem, fwiw.
  - wtetzner 7y ago
    Thank you! I'll try it out.
  - weberc2 7y ago
    This is a huge step in making OCaml more approachable. I get the feeling that there are quite a few of these modernizations around, but you have to know about them up front in order to hit the happy path. Would be great if there was some sort of "OCaml Happy Path" repo that laid out all of the right tools to use to be successful right off the bat. Sort of on the subject, Reason would be great but last I checked it utterly neglected its native compilation story--it advertised native compilation but every time I ran into an issue the Reason community would tell me that OCaml support was broken and I should use Node. Excited for the improvements to be sure!

e12e 7y ago

> "Go with generics and enums and Cargo" Isn't that d-lang?

eikenberry 7y ago

From the looks of things you'll probably get the Go you want first. The only thing missing from the roadmap are enums and there are a few Go2 proposals for them.

weberc2 7y ago
Maybe, albeit I'm concerned that the Go team might ship some broken version of generics or enums that we'll be stuck with for years and years. I think that would be strictly worse than no generics or enums. I hope they think holistically about the problem.