I love ML based languages, but it's definitely hard to get excited about new features when even just installing ocaml on windows starts with reading a chart of what tradeoffs you're going to have to make.
Is installing OCaml on a Linux VM with shared folders really installing "on windows", that like saying that windows app are installed "on a Mac" when they need Parallels to run
Well I guess this is an indication of what it would take to get elisp to have real multi-processing. It will be interesting to follow this process to see how the workflow pans out, and should be of major interest as a case study. Making such invasive and extensive changes across a large codebase and countless 3rd party libraries is a daunting coordination problem for open source projects.
I would love to see a Concurrent ML variant that compiles down to Go as the target language. Get the advantages of a great type system, while standing on the shoulders of Go's compiler and runtime.
I 100% agree, and I’m surprised more folks haven’t built languages to compile to Go for this reason. The language spec and constructs seem straightforward enough, is there any reason I’m missing?
There are some design tradeoffs in garbage collector design, particularly for moving/compacting collectors. If programs in your language tend to create lots of objects and rarely mutate them, then you'd want to make tradeoffs that push complexity/expense into the write barrier implementation.
IIRC, the .NET GC team were surprised at how poorly their GC performed in the first attempts to implement Haskell for .NET.
Another tradeoff for a classic 3-color tracing concurrent or incremental garbage collector is what the write barrier does when adding a reference to a maybe garbage (white) object from an already traced (black) object. The color invariant is that traced objects may never have references to garbage. In order to maintain the invariant, either the white object needs to be marked grey or the black object needs to be marked grey. If further modifications of the black object this cycle are unlikely, then the correct thing to do is to push the GC cycle forward by marking the white object grey. If further mutations of the black object are likely, the right thing to do is to defer potentially wasted work by marking the black object grey. Some garbage collectors make this decision on a per-type basis. For instance, IIRC LuaJIT's GC will mark black Tables grey if adding a white reference, and for other types, the GC will mark the white object grey. Languages that discourage mutation would tend to be tuned to mark white objects grey, and languages that tend to encourage mutation would tend to be tuned to mark black objects grey.
There's also the fact that all abstractions are leaky. If the semantic difference between your language and Go are small, then if you target Go, you can be relatively confident that the Go compiler has spent its finite complexity budget wisely for your language. If your source language semantics are very different from Go, then the Go compiler may skip some optimizations that would really help your programs, and may spend a lot of time in analysis that's unlikely to speed up your programs much.
I should also point out that Bacon-Rajan-style concurrent reference counting with cycle detection[0] can in some cases dramatically out-perform tracing GCs as found in Oracle's JVM, .NET, and most JavaScript engines.
The cost of tracing GC is proportional to the rate of object creation times the number of live objects. The cost of reference counting is proportional to the rate of reference destruction (with batching optimizations to reduce the cost of a small number of objects having lots of references created and destroyed.) If your programs create a lot of long-lived objects that rarely have their reference counts change, then cycle-detecting reference counting can be a big win.
One reason is that 'crossover languages'–i.e. languages that are hosted on a platform they don't control–invariably face many challenges, e.g. look at F# on .NET. They also face leaky abstraction, documentation, tooling etc. issues.
Tean years ago I moved to Silicon Valley from London to work at a hardware company. I realized pretty quikly that I wanted to do software not hardware. Algebraic datatypes, static typing, ..., were also more natural to me than OO and classes. So I 'learned' OCaml in a week, applied to a software dev job at a startup and got hired (I got extremaly lucky obviously). My secret love was Haskell and I later joined companies using Haskell in production. I then transitioned to engineering management.
Long story short - my experience has been that OCaml (and Haskell) are often better phased out as the maturity of the team grows. I hope that one day I that will change - but as of today I would not advise a startup to bet on functional languages like OCaml. Happy to elaborate as to why if there is some interest.
I'm looking forward to hearing from people who disagree; and more importantly, have built successful products in OCaml.
Agreed, have used both OCaml and Haskell in production and have founded startups using them. For startups we discovered you're in a much stronger position using languages with big ecosystems and communities - we're using Python and Django now, but would happily use Java or .NET in the future.
27 comments
[ 1.8 ms ] story [ 72.2 ms ] threadhttps://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc
Unfortunately, it has the same problem, but for Linux instead; dot net core is not the same as dot net.
Now there is https://fdopen.github.io/opam-repository-mingw/installation/
Basically you just need Cygwin and you are good. It worked for me when I last tried it.
With a caveat. If you depend on some cygwin libs for your ocaml program you need them on the other machine too.
Maybe you can copy them over as well. Or not. Not a win dev, sorry.
Well I guess this is an indication of what it would take to get elisp to have real multi-processing. It will be interesting to follow this process to see how the workflow pans out, and should be of major interest as a case study. Making such invasive and extensive changes across a large codebase and countless 3rd party libraries is a daunting coordination problem for open source projects.
IIRC, the .NET GC team were surprised at how poorly their GC performed in the first attempts to implement Haskell for .NET.
Another tradeoff for a classic 3-color tracing concurrent or incremental garbage collector is what the write barrier does when adding a reference to a maybe garbage (white) object from an already traced (black) object. The color invariant is that traced objects may never have references to garbage. In order to maintain the invariant, either the white object needs to be marked grey or the black object needs to be marked grey. If further modifications of the black object this cycle are unlikely, then the correct thing to do is to push the GC cycle forward by marking the white object grey. If further mutations of the black object are likely, the right thing to do is to defer potentially wasted work by marking the black object grey. Some garbage collectors make this decision on a per-type basis. For instance, IIRC LuaJIT's GC will mark black Tables grey if adding a white reference, and for other types, the GC will mark the white object grey. Languages that discourage mutation would tend to be tuned to mark white objects grey, and languages that tend to encourage mutation would tend to be tuned to mark black objects grey.
There's also the fact that all abstractions are leaky. If the semantic difference between your language and Go are small, then if you target Go, you can be relatively confident that the Go compiler has spent its finite complexity budget wisely for your language. If your source language semantics are very different from Go, then the Go compiler may skip some optimizations that would really help your programs, and may spend a lot of time in analysis that's unlikely to speed up your programs much.
The cost of tracing GC is proportional to the rate of object creation times the number of live objects. The cost of reference counting is proportional to the rate of reference destruction (with batching optimizations to reduce the cost of a small number of objects having lots of references created and destroyed.) If your programs create a lot of long-lived objects that rarely have their reference counts change, then cycle-detecting reference counting can be a big win.
[0] https://researcher.watson.ibm.com/researcher/files/us-bacon/...
You'd need an overlap of
1. An appreciation of ML and its extensions.
2. A relatively deep understanding of Go's semantics, performance hacks w/ GC, type system quirks, etc.
3. Belief that this would be useful.
4. Knowledge of compilers.
5. Time on your hands. This is a blocker for me :(
Long story short - my experience has been that OCaml (and Haskell) are often better phased out as the maturity of the team grows. I hope that one day I that will change - but as of today I would not advise a startup to bet on functional languages like OCaml. Happy to elaborate as to why if there is some interest.
I'm looking forward to hearing from people who disagree; and more importantly, have built successful products in OCaml.
Please do.
Still using OCaml for side projects tho!
Please elaborate because that is quite the leap.