4 ms·

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of cours

I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

hardwaresofton 6y ago
I don't think any ML languages are going to be able to qualify for best language for fast development. They are a paradigm shift for too many developers, which means you're going to pay a price getting up to speed. Compilation time is generally not the bounding factor for development speed these days. Theoretically, compile time is zero for scripting languages so that's at least one point against weighing compile time heavily. I think the key benefit of OCaml and other ML langauges over Rust right now is actually higher kinded types, dependent types, and things in that realm of abstraction -- which you're probably not going to be using unless they're built into some library you're making use of, so the benefit is kinda moot there. Feels like the best power/weight for abstractions in codebases is the typeclass (or Traits in rust), most of the stuff above that is not great for fast development unless it's already in place. And if we're talking about ML languages, I'm firmly in the Haskell camp because I think it has a better ecosystem (more than any research language should), an incredibly good runtime system (they've got the best native+green thread implementation I've ever seen), and fantastic abstractions for working with shared memory (when you need that). The whole "if it compiles, it works" is generally true. No need for a holy war, but if OCaml is in the race for fast development (which means that ML is in the race), then I'd pick Haskell over it to start on ecosystem/adoption, production readiness and features -- if you can manage to keep your developers from climbing the ladder of research-level abstraction.
bbkane 6y ago
I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.
- yawaramin 6y ago
  I encourage you to try it out to understand why the fuss.
throwaway894345 6y ago
I really wanted to like OCaml for the reasons you mentioned, but the ecosystem seems to be a mess with several “standard libraries”, mediocre tooling, and a dearth of libraries. Moreover, the language is still working to get its parallelism story out the door and Windows support is either lacking or non-existent (I forget which). The documentation is also rather poor, to the extent that I would often try to infer the OCaml solution from F# documentation. Moreover, when I’ve asked (polite, good faith) questions about how to do something in any online OCaml community, I was met with defensiveness and hostility (apparently if you have problems that Jane Street doesn’t have, you’re building software wrong). Lastly I just can’t get my head around the syntax and style guidelines; I also tried Reason, but it introduced other problems (typically related to build tooling and integration with the rest of the ocaml ecosystem) which may or may not have been worked out in the intervening years. OCaml has a lot of features that other languages lack, but they aren’t enough to make up for the table stakes features that it lacks.
- yawaramin 6y ago
  Libraries, documentation, tooling--all fixable and all being worked on. Without mega-corp support, of course, so it will take more time. But even today it's absolutely usable for many scenarios. Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Nevertheless, it's coming with OCaml 5--this year. Windows--support has gotten better over the last few years but still being worked on. Hostility--don't know what to tell you about that one--it's not my everyday experience. Sounds like a one-off. Syntax and style guidelines--they are the way they are for a reason (no pun intended), and after a while when you understand the reason for each quirk, it just falls into place. Table stakes features--many other languages out there, but IMHO the really table stakes features are being able to actually model your domain properly in a language. Which IMHO very few languages outside of OCaml get right. E.g. here's someone trying to propose abstract data types for Go without much luck: https://github.com/golang/go/issues/43123 https://github.com/golang/go/issues/43123
  - dragonwriter 6y ago
    > Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Ruby 3.0, released last month, has experimental parallel support via limited sharing “Ractors”.

hardwaresofton 6y ago

I don't think any ML languages are going to be able to qualify for best language for fast development. They are a paradigm shift for too many developers, which means you're going to pay a price getting up to speed. Compilation time is generally not the bounding factor for development speed these days. Theoretically, compile time is zero for scripting languages so that's at least one point against weighing compile time heavily. I think the key benefit of OCaml and other ML langauges over Rust right now is actually higher kinded types, dependent types, and things in that realm of abstraction -- which you're probably not going to be using unless they're built into some library you're making use of, so the benefit is kinda moot there. Feels like the best power/weight for abstractions in codebases is the typeclass (or Traits in rust), most of the stuff above that is not great for fast development unless it's already in place. And if we're talking about ML languages, I'm firmly in the Haskell camp because I think it has a better ecosystem (more than any research language should), an incredibly good runtime system (they've got the best native+green thread implementation I've ever seen), and fantastic abstractions for working with shared memory (when you need that). The whole "if it compiles, it works" is generally true. No need for a holy war, but if OCaml is in the race for fast development (which means that ML is in the race), then I'd pick Haskell over it to start on ecosystem/adoption, production readiness and features -- if you can manage to keep your developers from climbing the ladder of research-level abstraction.

bbkane 6y ago

I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.

yawaramin 6y ago
I encourage you to try it out to understand why the fuss.

throwaway894345 6y ago

I really wanted to like OCaml for the reasons you mentioned, but the ecosystem seems to be a mess with several “standard libraries”, mediocre tooling, and a dearth of libraries. Moreover, the language is still working to get its parallelism story out the door and Windows support is either lacking or non-existent (I forget which). The documentation is also rather poor, to the extent that I would often try to infer the OCaml solution from F# documentation. Moreover, when I’ve asked (polite, good faith) questions about how to do something in any online OCaml community, I was met with defensiveness and hostility (apparently if you have problems that Jane Street doesn’t have, you’re building software wrong). Lastly I just can’t get my head around the syntax and style guidelines; I also tried Reason, but it introduced other problems (typically related to build tooling and integration with the rest of the ocaml ecosystem) which may or may not have been worked out in the intervening years. OCaml has a lot of features that other languages lack, but they aren’t enough to make up for the table stakes features that it lacks.

yawaramin 6y ago
Libraries, documentation, tooling--all fixable and all being worked on. Without mega-corp support, of course, so it will take more time. But even today it's absolutely usable for many scenarios. Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Nevertheless, it's coming with OCaml 5--this year. Windows--support has gotten better over the last few years but still being worked on. Hostility--don't know what to tell you about that one--it's not my everyday experience. Sounds like a one-off. Syntax and style guidelines--they are the way they are for a reason (no pun intended), and after a while when you understand the reason for each quirk, it just falls into place. Table stakes features--many other languages out there, but IMHO the really table stakes features are being able to actually model your domain properly in a language. Which IMHO very few languages outside of OCaml get right. E.g. here's someone trying to propose abstract data types for Go without much luck: https://github.com/golang/go/issues/43123 https://github.com/golang/go/issues/43123
- dragonwriter 6y ago
  > Multicore--Node, Ruby, Python etc. all seem to be doing fine without it. Ruby 3.0, released last month, has experimental parallel support via limited sharing “Ractors”.