6 ms·

Hurray! My wish for Ocaml is that it could somehow be popular enough to have more… casual users, let’s say. I enjoy playing with it more than any other languag

Hurray! My wish for Ocaml is that it could somehow be popular enough to have more… casual users, let’s say. I enjoy playing with it more than any other language I’ve run into, but everyone else falls so deeply into it that I don’t generally follow their discussions very well. (Maybe I’ll fall in deep myself in time, but it remains to be seen.)

ModernMech 5y ago
I don't know if you've seen this language yet and I haven't used it, but Grain seems to take a lot of inspiration from Reason. Seems like they are trying to target a more casual audience. https://grain-lang.org https://grain-lang.org
Ericson2314 5y ago
Someone needs to get OCaml running on the Go runtime, so it can be an F# for that ecosystem.
- yawaramin 5y ago
  With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime? Imho there's no point. Especially now that OCaml Multicore is on the way. A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like.
  - Ericson2314 5y ago
    > With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime? Huh? The point is Go might be a lousy language, but I can't think of anything OCaml needs to do that the Go runtime cannot do. This wouldn't be leaky and the FFI could be quite good. > Especially now that OCaml Multicore is on the way. As I wrote in the other reply, this would be a naked ploy for new users, and flexing the language isn't wedded to a single run time. Multicore OCaml isn't just a runtime change, but also demonstration of the new effects indicating that the language can do parallelism without bad concurrency problems. All that language-side work carries over to the other runtime: you get to show off Goroutines done more safely!
    - c-cube 5y ago
      Does Go's runtime do generational collection? No. Does it support tailcalls? I have no idea but I doubt so. Without these there cannot be any chance for OCaml-on-go; more blockers would probably come to mind quite quickly.
      - Ericson2314 5y ago
        The GC would be shitty, yes. I doubt the runtime itself really cares about tailcails. There could be tiny calling convention issue, you can share the runtime while using a different calling convention, I assume. People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.
        deleted 5y ago
        [deleted]
        nu11ptr 5y ago
        Not sure about now with multicore, but pretty sure OCaml had a "bump" memory allocator previously. These are just a little bit slower than stack allocation as they just involve a pointer increment and is important in functional languages since they allocate a LOT. Go's memory allocator is pretty fast (I played with making a bump allocator for it and it was only 4-5x faster, so very fast), but the slowdown would be noticeable. Also, Go uses a "mark and sweep" style collector (which is the reason it can't use a bump allocator - those require moving on collection, which Go can't do) which just isn't designed for the amount of garbage that FP languages generate. It might work, but it would be quite a bit slower.
        ptman 5y ago
        Go uses a simple non-generational collector because it avoids generating garbage on the heap by doing escape analysis and allocating on stack. I get the ocaml does a lot of recursion, being functional. But could stack allocation also work for ocaml when using growable stacks?
  - lindig 5y ago
    > A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like. OCaml's package management and build system is not complicated for consumers and builds are very fast. What do you feel is complicated about opam and dune? What is complicated (but got better) is submitting packages into the official package repository. However, this ensures that packages have correctly versioned dependencies, which is good for consumers. Go does not rely on a central package repository and this makes it easier to use by essentially just pointing to GitHub. OCaml and Go differ in the way they try to use updated dependencies for a build. OCaml by default is aggressive whereas Go prefers stability.
- whimsicalism 5y ago
  What's the motivation? OCaml is roughly as performant as Go.
  - Ericson2314 5y ago
    Pure naked grab at more users. I don't mean to imply there any anything better about Go's runtime at all.
    - yawaramin 5y ago
      In any case, if a large number of users is what you're after, you'd target Java ( http://www.ocamljava.org/ http://www.ocamljava.org/ ) or JavaScript ( https://rescript-lang.org/ https://rescript-lang.org/ , http://ocsigen.org/js_of_ocaml/latest/manual/overview http://ocsigen.org/js_of_ocaml/latest/manual/overview ).
      - Ericson2314 5y ago
        Yes, those are fine ones to do too.
    - edwintorok 5y ago
      In that case interoperability with Go libraries might be better: just running on the same runtime wouldn't bring many advantages (other than having a single GC instead of 2) without being able to easily call libraries written in another language. (Although TBH I'd run them as 2 separate processes and have them communicate via some form of RPC, OCaml would just need good integration with <insert-favourite-GO-rpc> protocol)
      - Ericson2314 5y ago
        RPC is dramatically less powerful than than FFI. No sharing of state is a serious limitation.
        pjmlp 5y ago
- ernst_klim 5y ago
  This is a very bad idea considering Go runtime is optimized for way less allocations due to 1) how good Go in stack allocation is and 2) how mutable everything is. OCaml on the other hand has an extremely well optimized runtime for lots of small heap allocations (typical in FP), and produces good asm code for functional patterns.
- amaranth 5y ago
  With F# or TypeScript or similar things you can compile down to a common bytecode or to the base language and use the result. Unless you were writing an OCaml to Go transpiler you'd need to ship a copy of the Go source code alongside a new OCaml compiler and still have to build a new build system and ecosystem and such. You couldn't just bolt this on to an existing Go installation or something.
- frej 5y ago
  Which feature is prevalent in the go runtime that you must have? Or is it the ecosystem that is larger in go?

ModernMech 5y ago

I don't know if you've seen this language yet and I haven't used it, but Grain seems to take a lot of inspiration from Reason. Seems like they are trying to target a more casual audience. https://grain-lang.org https://grain-lang.org

Ericson2314 5y ago

Someone needs to get OCaml running on the Go runtime, so it can be an F# for that ecosystem.

yawaramin 5y ago
With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime? Imho there's no point. Especially now that OCaml Multicore is on the way. A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like.
- Ericson2314 5y ago
  > With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime? Huh? The point is Go might be a lousy language, but I can't think of anything OCaml needs to do that the Go runtime cannot do. This wouldn't be leaky and the FFI could be quite good. > Especially now that OCaml Multicore is on the way. As I wrote in the other reply, this would be a naked ploy for new users, and flexing the language isn't wedded to a single run time. Multicore OCaml isn't just a runtime change, but also demonstration of the new effects indicating that the language can do parallelism without bad concurrency problems. All that language-side work carries over to the other runtime: you get to show off Goroutines done more safely!
  - c-cube 5y ago
    Does Go's runtime do generational collection? No. Does it support tailcalls? I have no idea but I doubt so. Without these there cannot be any chance for OCaml-on-go; more blockers would probably come to mind quite quickly.
    - Ericson2314 5y ago
      The GC would be shitty, yes. I doubt the runtime itself really cares about tailcails. There could be tiny calling convention issue, you can share the runtime while using a different calling convention, I assume. People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.
      - deleted 5y ago
        [deleted]
      - nu11ptr 5y ago
        Not sure about now with multicore, but pretty sure OCaml had a "bump" memory allocator previously. These are just a little bit slower than stack allocation as they just involve a pointer increment and is important in functional languages since they allocate a LOT. Go's memory allocator is pretty fast (I played with making a bump allocator for it and it was only 4-5x faster, so very fast), but the slowdown would be noticeable. Also, Go uses a "mark and sweep" style collector (which is the reason it can't use a bump allocator - those require moving on collection, which Go can't do) which just isn't designed for the amount of garbage that FP languages generate. It might work, but it would be quite a bit slower.
        ptman 5y ago
        Go uses a simple non-generational collector because it avoids generating garbage on the heap by doing escape analysis and allocating on stack. I get the ocaml does a lot of recursion, being functional. But could stack allocation also work for ocaml when using growable stacks?
- lindig 5y ago
  > A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like. OCaml's package management and build system is not complicated for consumers and builds are very fast. What do you feel is complicated about opam and dune? What is complicated (but got better) is submitting packages into the official package repository. However, this ensures that packages have correctly versioned dependencies, which is good for consumers. Go does not rely on a central package repository and this makes it easier to use by essentially just pointing to GitHub. OCaml and Go differ in the way they try to use updated dependencies for a build. OCaml by default is aggressive whereas Go prefers stability.
whimsicalism 5y ago
What's the motivation? OCaml is roughly as performant as Go.
- Ericson2314 5y ago
  Pure naked grab at more users. I don't mean to imply there any anything better about Go's runtime at all.
  - yawaramin 5y ago
    In any case, if a large number of users is what you're after, you'd target Java ( http://www.ocamljava.org/ http://www.ocamljava.org/ ) or JavaScript ( https://rescript-lang.org/ https://rescript-lang.org/ , http://ocsigen.org/js_of_ocaml/latest/manual/overview http://ocsigen.org/js_of_ocaml/latest/manual/overview ).
    - Ericson2314 5y ago
      Yes, those are fine ones to do too.
  - edwintorok 5y ago
    In that case interoperability with Go libraries might be better: just running on the same runtime wouldn't bring many advantages (other than having a single GC instead of 2) without being able to easily call libraries written in another language. (Although TBH I'd run them as 2 separate processes and have them communicate via some form of RPC, OCaml would just need good integration with <insert-favourite-GO-rpc> protocol)
    - Ericson2314 5y ago
      RPC is dramatically less powerful than than FFI. No sharing of state is a serious limitation.
      - pjmlp 5y ago
ernst_klim 5y ago
This is a very bad idea considering Go runtime is optimized for way less allocations due to 1) how good Go in stack allocation is and 2) how mutable everything is. OCaml on the other hand has an extremely well optimized runtime for lots of small heap allocations (typical in FP), and produces good asm code for functional patterns.
amaranth 5y ago
With F# or TypeScript or similar things you can compile down to a common bytecode or to the base language and use the result. Unless you were writing an OCaml to Go transpiler you'd need to ship a copy of the Go source code alongside a new OCaml compiler and still have to build a new build system and ecosystem and such. You couldn't just bolt this on to an existing Go installation or something.
frej 5y ago
Which feature is prevalent in the go runtime that you must have? Or is it the ecosystem that is larger in go?