4 ms·

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 sh

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.

rejectedandsad 5y ago
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?
- KMag 5y ago
  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.
  - KMag 5y ago
    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. [0] https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf https://researcher.watson.ibm.com/researcher/files/us-bacon/...
- smasher164 5y ago
  I think this might be for social reasons instead of technical. 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 :(
- yawaramin 5y ago
  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.
zem 5y ago
purescript can compile to go: https://github.com/andyarvanitis/purescript-native https://github.com/andyarvanitis/purescript-native

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.

rejectedandsad 5y ago

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?

KMag 5y ago
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.
- KMag 5y ago
  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. [0] https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf https://researcher.watson.ibm.com/researcher/files/us-bacon/...
smasher164 5y ago
I think this might be for social reasons instead of technical. 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 :(
yawaramin 5y ago
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.

zem 5y ago

purescript can compile to go: https://github.com/andyarvanitis/purescript-native https://github.com/andyarvanitis/purescript-native