7 ms·

let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (c

let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) ) - OCaml vs Clojure: vastly superior typing system. (=> less bugs) - OCaml vs Kotlin: no JVM needed. - OCaml vs C++: more safety. once it compiles it will not segv. - OCaml vs Go: vastly superior typing system. (=> less bugs) - OCaml vs Python: vastly superior type system, way better performance. The biggest risk of doing OCaml (or Haskell or Rust) for extended periods of time is that you will be unable to hide your feeling of superiority towards (fe) a python developer.

frizlab 4y ago
What about Swift?
- KurtMueller 4y ago
  For now, a good language if you want to develop apps for the mac ecosystem.
- Zababa 4y ago
  On the server, less ecosystem than OCaml. Long compile times. A big part of its "market share" is taken by Rust instead.
0des 4y ago
water8 4y ago
OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.
- akhmatova 4y ago
  It's not getting things done that matters. It's feeling superior to others that matters.
  - shikoba 4y ago
    Hey, it's not a feeling. It's a fact.
    - hutzlibu 4y ago
      It is certainly a fact, that you feel superior. I would like to confirm that fact, by comparing productive output..
      - wiseowise 4y ago
        Define "productive output".
        hutzlibu 4y ago
        Producing code, that primarily solves the real world problem (not aesthetic ones).
        yawaramin 4y ago
        What kind of code? People who want to solve real-world problems treat programming languages like tools in their toolbox. In the past week at work I wrote Scala, HTML, JavaScript, YAML, and Terraform. I also remove tons of code from my production systems whenever I get the chance as it solves a real-world problem for me (maintainability of the code base). 'Producing code' to measure 'superiority' is about as useful a metric as counting lines of code to measure productivity.
  - ladis_washerum 4y ago
- yawaramin 4y ago
  If Jane Street can teach OCaml to traders, I can teach it to developers. That's not a concern for anyone other than a sweatshop.
  - akhmatova 4y ago
    If Jane Street can teach OCaml to traders, I can teach it to developers. You can if they are motivated to learn. Unless you are offering Jane Street levels of compensation; and in return, the candidate is willing to believe, or pretend to believe that company's shtick about OCaml being so categorically superior as a general-purpose development language so as to leave all the others in the dust -- most likely they won't be.
    - yawaramin 4y ago
      Or if, you know, they were hired to work on a project where they get paid a salary. That seems to incentivize most devs.
      - akhmatova 4y ago
        Not "a salary", but a Jane Street salary and resume cred. Otherwise you just won't find that many takers.
        yawaramin 4y ago
        I can assure you I will and in fact have found plenty of takers for my job postings with a niche language. You just need to word the postings appropriately and be willing to teach people what they don't know.
        akhmatova 4y ago
        You just need to word the postings appropriately and be willing to teach people what they don't know. OK, I'll grant that if you have that "magic skill" then you can in fact recruit developers for niche languages. Most companies don't, as we know, and frankly it's amazing to me how incoherent their communications are throughout their so-called hiring process.
- AlexanderNull 4y ago
  Good luck finding high quality cheap developers in any language really. Very few good developers are language specific so unless your HM is an idiot and actively screens out candidates without 10 years of previous experience in the specific framework you're using it won't be a limitation. If you want quality developers you need to offer either 1) lots of money, 2) amazing benefits, 3) interesting problems to work on. For many, an interesting language can provide an edge. I chose my current company because I would be working on Scala here as opposed to Java with the other offers I had. The quality of life improvement of the Scala position was enough to take it over the prospect of writing AbstractFactoryBeanImpl for the next few years.
- wiseowise 4y ago
  > Good luck finding developers that will write quality code and not cost a fortune each. You pick one regardless of language. Not sure what's your point here.
throwamon 4y ago
> vastly superior typing system. (=> less bugs) I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature, not a bug, and it's a result of a fundamental difference in some beliefs about how to write correct software. From this I wonder how misrepresentative your other comparisons are as well. But don't get me wrong, OCaml is probably my "favorite language I've never actually used" (I've never "actually used" Clojure in "real projects" either).
- toolslive 4y ago
  Take any open source python project on github (or others) look at the list of issues and count the number of 'NoneType' has no attribute ... instances. All these could have been avoided by a decent type system. I rest my case ;)
- tgflynn 4y ago
  I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.
  - camgunz 4y ago
    This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dynamic-typing-a-literature-review https://github.com/hwayne/awesome-cold-showers#static-vs-dyn.... I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.
    - laserlight 4y ago
      I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.
contificate 4y ago
I think the languages you selected in your final remark sum it up for me. If one is truly taken by functional programming, much of their mental model starts to revolve around algebraic (inductively defined) data types and structural recursion (aided by pattern matching) over them - such that mentally reducing the set of candidate languages really does become an implicit process of questioning: "does X have ergonomic, statically-typed, discriminated sums?". Lots of mainstream languages simply fail this test and make it feel like intellectual poverty or that there's extreme, turgid, boilerplate required for a weak imitation of the features (see the idiomatic class-hierarchy encoding of ADTs in large projects - such as LLVM - in C++, for example). It's absolutely no surprise that more mainstream languages are picking up a match-like construct and lighter encodings of discriminated sums. So, it really comes to what else you wish to be burdened with when compiling an OCaml-like mental model to X in your head: Tagged unions a-la C? Class hierarchies for ADTs in C++? The travesties of std::variant? Monad transformers in Haskell? Lazy evaluation? No static typing at all? Caring about memory management and ownership? Box and Arc-ing recursive components of ADTs? Writing your own arena allocator? Compiling to the JVM? Spotty TCO support? OCaml is just a nice, fairly simple (at its core, at least), language that captures the essence of the ML family, compiles to native (and bytecode and, transitively, JavaScript), has great tooling (opam, dune, ocamllex, memhir, etc.), great libraries (official LLVM bindings, for example), and a great community. Lots of OCamlers are well aware of other potential languages that somewhat suit their style of programming, they just don't want to be burdened by the other stuff.
- deleted 4y ago
  [deleted]
twh270 4y ago
Not sure what you mean by "- OCaml vs Kotlin: no JVM needed." as Kotlin has support for native and JavaScript compilation, and WASM via native.
- thayne 4y ago
  Maybe it's changed in the year or so since I looked at kotlin, but my impression when I did look at it was support for anything other than the JVM was definitely second class
- toolslive 4y ago
  so it's either a JVM or either no libraries?
- pjmlp 4y ago
  Kotlin has a crude support for native, and they had to reboot the implementation as they got clever and went with a memory model incompatible with JVM and JS GCs, thus making code portability an headache.
- wiseowise 4y ago
  Did you even try it? It still requires Java, Gradle and Kotlin compiler to work. Also, good luck making it work without using Intellij.
Akronymus 4y ago
What about ocaml vs f#?

frizlab 4y ago

What about Swift?

KurtMueller 4y ago
For now, a good language if you want to develop apps for the mac ecosystem.
Zababa 4y ago
On the server, less ecosystem than OCaml. Long compile times. A big part of its "market share" is taken by Rust instead.

0des 4y ago

water8 4y ago

OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.

akhmatova 4y ago
It's not getting things done that matters. It's feeling superior to others that matters.
- shikoba 4y ago
  Hey, it's not a feeling. It's a fact.
  - hutzlibu 4y ago
    It is certainly a fact, that you feel superior. I would like to confirm that fact, by comparing productive output..
    - wiseowise 4y ago
      Define "productive output".
      - hutzlibu 4y ago
        Producing code, that primarily solves the real world problem (not aesthetic ones).
        yawaramin 4y ago
        What kind of code? People who want to solve real-world problems treat programming languages like tools in their toolbox. In the past week at work I wrote Scala, HTML, JavaScript, YAML, and Terraform. I also remove tons of code from my production systems whenever I get the chance as it solves a real-world problem for me (maintainability of the code base). 'Producing code' to measure 'superiority' is about as useful a metric as counting lines of code to measure productivity.
- ladis_washerum 4y ago
yawaramin 4y ago
If Jane Street can teach OCaml to traders, I can teach it to developers. That's not a concern for anyone other than a sweatshop.
- akhmatova 4y ago
  If Jane Street can teach OCaml to traders, I can teach it to developers. You can if they are motivated to learn. Unless you are offering Jane Street levels of compensation; and in return, the candidate is willing to believe, or pretend to believe that company's shtick about OCaml being so categorically superior as a general-purpose development language so as to leave all the others in the dust -- most likely they won't be.
  - yawaramin 4y ago
    Or if, you know, they were hired to work on a project where they get paid a salary. That seems to incentivize most devs.
    - akhmatova 4y ago
      Not "a salary", but a Jane Street salary and resume cred. Otherwise you just won't find that many takers.
      - yawaramin 4y ago
        I can assure you I will and in fact have found plenty of takers for my job postings with a niche language. You just need to word the postings appropriately and be willing to teach people what they don't know.
        akhmatova 4y ago
        You just need to word the postings appropriately and be willing to teach people what they don't know. OK, I'll grant that if you have that "magic skill" then you can in fact recruit developers for niche languages. Most companies don't, as we know, and frankly it's amazing to me how incoherent their communications are throughout their so-called hiring process.
AlexanderNull 4y ago
Good luck finding high quality cheap developers in any language really. Very few good developers are language specific so unless your HM is an idiot and actively screens out candidates without 10 years of previous experience in the specific framework you're using it won't be a limitation. If you want quality developers you need to offer either 1) lots of money, 2) amazing benefits, 3) interesting problems to work on. For many, an interesting language can provide an edge. I chose my current company because I would be working on Scala here as opposed to Java with the other offers I had. The quality of life improvement of the Scala position was enough to take it over the prospect of writing AbstractFactoryBeanImpl for the next few years.
wiseowise 4y ago
> Good luck finding developers that will write quality code and not cost a fortune each. You pick one regardless of language. Not sure what's your point here.

throwamon 4y ago

> vastly superior typing system. (=> less bugs) I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature, not a bug, and it's a result of a fundamental difference in some beliefs about how to write correct software. From this I wonder how misrepresentative your other comparisons are as well. But don't get me wrong, OCaml is probably my "favorite language I've never actually used" (I've never "actually used" Clojure in "real projects" either).

toolslive 4y ago
Take any open source python project on github (or others) look at the list of issues and count the number of 'NoneType' has no attribute ... instances. All these could have been avoided by a decent type system. I rest my case ;)
tgflynn 4y ago
I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.
- camgunz 4y ago
  This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dynamic-typing-a-literature-review https://github.com/hwayne/awesome-cold-showers#static-vs-dyn.... I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.
  - laserlight 4y ago
    I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.

contificate 4y ago

I think the languages you selected in your final remark sum it up for me. If one is truly taken by functional programming, much of their mental model starts to revolve around algebraic (inductively defined) data types and structural recursion (aided by pattern matching) over them - such that mentally reducing the set of candidate languages really does become an implicit process of questioning: "does X have ergonomic, statically-typed, discriminated sums?". Lots of mainstream languages simply fail this test and make it feel like intellectual poverty or that there's extreme, turgid, boilerplate required for a weak imitation of the features (see the idiomatic class-hierarchy encoding of ADTs in large projects - such as LLVM - in C++, for example). It's absolutely no surprise that more mainstream languages are picking up a match-like construct and lighter encodings of discriminated sums. So, it really comes to what else you wish to be burdened with when compiling an OCaml-like mental model to X in your head: Tagged unions a-la C? Class hierarchies for ADTs in C++? The travesties of std::variant? Monad transformers in Haskell? Lazy evaluation? No static typing at all? Caring about memory management and ownership? Box and Arc-ing recursive components of ADTs? Writing your own arena allocator? Compiling to the JVM? Spotty TCO support? OCaml is just a nice, fairly simple (at its core, at least), language that captures the essence of the ML family, compiles to native (and bytecode and, transitively, JavaScript), has great tooling (opam, dune, ocamllex, memhir, etc.), great libraries (official LLVM bindings, for example), and a great community. Lots of OCamlers are well aware of other potential languages that somewhat suit their style of programming, they just don't want to be burdened by the other stuff.

deleted 4y ago
[deleted]

twh270 4y ago

Not sure what you mean by "- OCaml vs Kotlin: no JVM needed." as Kotlin has support for native and JavaScript compilation, and WASM via native.

thayne 4y ago
Maybe it's changed in the year or so since I looked at kotlin, but my impression when I did look at it was support for anything other than the JVM was definitely second class
toolslive 4y ago
so it's either a JVM or either no libraries?
pjmlp 4y ago
Kotlin has a crude support for native, and they had to reboot the implementation as they got clever and went with a memory model incompatible with JVM and JS GCs, thus making code portability an headache.
wiseowise 4y ago
Did you even try it? It still requires Java, Gradle and Kotlin compiler to work. Also, good luck making it work without using Intellij.

Akronymus 4y ago

What about ocaml vs f#?