5 ms·

I think the JVM would also be a good choice once Loom lands. I've seen that right now the Java architects are trying to unify the ALGOL flavored Java with ML in

I think the JVM would also be a good choice once Loom lands. I've seen that right now the Java architects are trying to unify the ALGOL flavored Java with ML in the sense of algebraic data structures, pattern matching, local type inference. As you said, OCaml does not have a big community, library ecosystem. It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me.

nextaccountic 5y ago
Does Java have sum types yet?
- Zababa 5y ago
  It does, through sealed classes.
Zababa 5y ago
That's a good option too, though in that case the tradeoff is that compiling to a single binary is a bit harder than in the other languages. Someone mentionned Scala too, which is even "higher level" than OCaml, but I think Scala has the issue of future/async (monadic) concurrency, and is even harder to compile to native. There are lots of options in that space, which is great! > It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me. Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code.
- astrange 5y ago
  No amount of $ spent on JITs and garbage collection can solve the problem that Java was designed with no respect for memory use. It just doesn’t have the features (such as but not limited to value types) that let you save memory. They’re adding value types of course, but I haven’t looked at how exactly they’ll work.
  - pjmlp 5y ago
    Until Valhalla arrives, Unsafe package and JNI are options as well. Or is it ok to use cgo to work around Go's shortcomings, but not JNI for Java's?
    - astrange 5y ago
      Sure it's fine, but isn't that not writing in Java? I don't remember how good the Java interfaces look though, eg if you worked around no constant data by defining your arrays in C and passing them back, would they be bounds checked arrays?
      - pjmlp 5y ago
        Just like CGO is not Go, yet not a reason to throw everything away. If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO.
        astrange 5y ago
        > If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO. I'm talking about defining a 'const int[]' in C and having it appear as an 'int[]' in Java. I think that's even less likely to happen if you define a const std::vector. Actually I've never even seen someone define constant data in C++ using a vector, but this fits my experience of C++ developers telling me I'm stupid when I do the only thing I've ever seen anyone actually write.
        pjmlp 5y ago
        What can I say, you hang around the wrong people.
  - erik_seaberg 5y ago
    Go is better at keeping values on the stack. Java has better throughput when collecting objects that escaped to the heap. Java also tries to optimize out method dispatch, so we can use it freely where Go might tend to avoid it.
- kaba0 5y ago
  > Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code. Go doesn’t need a good GC as much because it can rely on value types sometimes. But for general enough workloads a superior GC can triumph. Also, Java is memory hungry only in that doing GC when it is not absolutely needed is useless work. The JVM is actually quite power efficient due to trading off memory for better throughput — so especially in server environments with huge (up to multi-TB) memory which the JVM is free to use, it can be ridiculously fast. So no, java is not slower than equivalent Go program though correctly comparing languages is nigh impossible.

nextaccountic 5y ago

Does Java have sum types yet?

Zababa 5y ago
It does, through sealed classes.

Zababa 5y ago

That's a good option too, though in that case the tradeoff is that compiling to a single binary is a bit harder than in the other languages. Someone mentionned Scala too, which is even "higher level" than OCaml, but I think Scala has the issue of future/async (monadic) concurrency, and is even harder to compile to native. There are lots of options in that space, which is great! > It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me. Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code.

astrange 5y ago
No amount of $ spent on JITs and garbage collection can solve the problem that Java was designed with no respect for memory use. It just doesn’t have the features (such as but not limited to value types) that let you save memory. They’re adding value types of course, but I haven’t looked at how exactly they’ll work.
- pjmlp 5y ago
  Until Valhalla arrives, Unsafe package and JNI are options as well. Or is it ok to use cgo to work around Go's shortcomings, but not JNI for Java's?
  - astrange 5y ago
    Sure it's fine, but isn't that not writing in Java? I don't remember how good the Java interfaces look though, eg if you worked around no constant data by defining your arrays in C and passing them back, would they be bounds checked arrays?
    - pjmlp 5y ago
      Just like CGO is not Go, yet not a reason to throw everything away. If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO.
      - astrange 5y ago
        > If one is dumb enough to use C style arrays instead of C++ bounded checked ones, yes that is a problem, again just like C arrays defined in CGO. I'm talking about defining a 'const int[]' in C and having it appear as an 'int[]' in Java. I think that's even less likely to happen if you define a const std::vector. Actually I've never even seen someone define constant data in C++ using a vector, but this fits my experience of C++ developers telling me I'm stupid when I do the only thing I've ever seen anyone actually write.
        pjmlp 5y ago
        What can I say, you hang around the wrong people.
- erik_seaberg 5y ago
  Go is better at keeping values on the stack. Java has better throughput when collecting objects that escaped to the heap. Java also tries to optimize out method dispatch, so we can use it freely where Go might tend to avoid it.
kaba0 5y ago
> Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code. Go doesn’t need a good GC as much because it can rely on value types sometimes. But for general enough workloads a superior GC can triumph. Also, Java is memory hungry only in that doing GC when it is not absolutely needed is useless work. The JVM is actually quite power efficient due to trading off memory for better throughput — so especially in server environments with huge (up to multi-TB) memory which the JVM is free to use, it can be ridiculously fast. So no, java is not slower than equivalent Go program though correctly comparing languages is nigh impossible.