10 ms·

"We worked really hard to prove our favorite language has value" Notice the "Why we like OCaml" page could have been written for C++ https://pbs.twimg.com/med

"We worked really hard to prove our favorite language has value" Notice the "Why we like OCaml" page could have been written for C++ https://pbs.twimg.com/media/E9fNTDYWYAoxF17?format=jpg&name=large https://pbs.twimg.com/media/E9fNTDYWYAoxF17?format=jpg&name=...

paulddraper 5y ago
> "Why we like OCaml" page could have been written for C++ Okay, so they forgot the "isn't insanely complicated and abtruse" bullet point? (EDIT: I don't mean to flame on C++. But slides notwithstanding, the difference between the two is pretty obvious.)
- pjmlp 5y ago
  Bloomberg is a major ISO C++ contributor as well.
yawaramin 5y ago
‘Fast compilation speed’? Nah, lol
- fnord123 5y ago
  OCaml compile speeds are not particularly fast.
  - yawaramin 5y ago
    Compared to what?
    - fnord123 5y ago
      On par with Java but without maven startup time.
      - yawaramin 5y ago
        Admittedly I’m not citing actual numbers (but then again neither is anyone else here), but subjectively based on past experience, I highly doubt that. The OCaml compile is super parallelizable, with no forward references i.e. potential dependency cycles like in Java. My feeling is it blows Java out of the water.
      - pjmlp 5y ago
        You don't need Maven to compile Java code, additionally when using Eclipse incremental compiler, files are compiled on save.
  - dwohnitmok 5y ago
    I'm curious do you have concrete data for this? I would love to see compile times for representative codebases of various sizes across languages and how they've changed across compiler versions. From anecdotal experience I view OCaml's bytecode compile speeds to be on par with Go's (as a rule of thumb I expect about 1 second per 10k lines). Far slower than something like TCC, but quite fast among other languages.
    - fnord123 5y ago
      I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, running on identical machines. As for your view of OCaml byte code compilation speed being on par with Go seems rather unlikely or I'm misunderstanding what you mean. Go is not dealing with anywhere as near a complex type system as OCaml and generates a lot more potato machine code (usually not using -mnative so you can know you can copy a binary to arbitrary machines).
      - EduardoRFS 5y ago
        OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.
        reecko 5y ago
        > OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
        pjmlp 5y ago
        Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.
      - 5y ago
  - EduardoRFS 5y ago
    OCaml is really good at building in parallel. So even without that many files it can still compile using 32 threads. Making so that a project with 20k loc is less than a second in debug mode. And recompile time in native(debug) mode is almost 100% linking time. For bytecode you can have wild rebuild times, in the milisecond range.
    - fnord123 5y ago
      Pyre[1] is about 20k loc of ocaml[2]. $ time make -C source -j8 make: Entering directory '/home/fnord123/src/download/pyre-check/source' ../scripts/setup.sh --configure Build info: Linux x86_64 @ Mon Aug 23 2021 (development build) abort: no repository found in '/home/fnord123/src/download/pyre-check/source' (.hg not found)! Git commit: 1e4dd5a39db1631fd13a3a8df74d6e0f5d801fbc dune build @install -j auto --profile dev menhir parser/generator.{ml,mli} Warning: 31 states have shift/reduce conflicts. Warning: 5 states have reduce/reduce conflicts. Warning: 77 shift/reduce conflicts were arbitrarily resolved. Warning: 75 reduce/reduce conflicts were arbitrarily resolved. make: Leaving directory '/home/fnord123/src/download/pyre-check/source' real 0m43.700s user 4m3.030s sys 0m41.005s I must be doing something wrong. [1] https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [2] $ tokei ------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ------------------------------------------------------------------------------- Autoconf 2 235 204 3 28 C 15 242641 165361 60669 16611 C Header 10 14267 2617 11094 556 Coq 10 2391 1968 220 203 CSS 5 713 540 44 129 Dockerfile 2 71 42 11 18 HTML 2 35 30 0 5 INI 1 12 9 0 3 Java 31 2654 2080 267 307 JavaScript 7 867 752 61 54 JSON 17 939 939 0 0 Makefile 5 229 145 45 39 Markdown 47 7213 7213 0 0 OCaml 791 229096 198302 10455 20339 Python 398 61909 50119 2917 8873 Shell 5 111 59 34 18 SVG 2 2 2 0 0 TeX 4 929 642 129 158 Plain Text 5 457 457 0 0 TOML 1 2 2 0 0 TypeScript 2 130 84 20 26 ------------------------------------------------------------------------------- Total 1362 564903 431567 85969 47367 -------------------------------------------------------------------------------
  - zem 5y ago
    compared to what? it's definitely one of the fastest-compiling languages i use.
therealdrag0 5y ago
Sure. But I think it’s good that there is diversity of languages being used out there. No skin off my back for them to use OCaml so go for it!
rowanG077 5y ago
I really wouldn't call C++s type system expressive. And neither would I say it's community is small or enthusiastic. And compile times are fast in C++? What are you smoking?
- jcelerier 5y ago
  Can OCaml's type system express a type parametrized on a value, eg. like template<auto f> struct my_type{}; using t1 = my_type<123>; constexpr t1 val1; using t2 = my_type<val1>; ?
  - rowanG077 5y ago
    I haven't used ocaml but I think something is possible with GADTs. Beside the example you have given shows C++ templating prowess and not its type system. In general I wouldn't call a type system that doesn't support ADTs expressive.
    - jcelerier 5y ago
      But GADTs are expressible in the C++ type system (thanks to templates which are just the C++ implementation of the parametrizable types typesystem-level property)
  - yawaramin 5y ago
    No, but on the other hand it doesn’t monomorphize generics and make the compiles dog slow and the binaries bloated :-)
    - andrepd 5y ago
      Well, but it does make the code slower
      - yawaramin 5y ago
        I knew someone would say that :-) ‘Slower’ is super subjective. What is the actual performance requirement? And remember that the OP thread is talking about an extremely high-performance RPC system. Sure, it may not be as fast as C++, but again, what is the actual performance requirement. You don’t go around just throwing ‘Eh, not as fast as C++’ at everything you come across :-)
iso8859-1 5y ago
It would be weird for this slide to list all the things that they don't like. But that is what they'd have to do with C++, since its problem is not the features it has, but that it has every feature.
- tialaramex 5y ago
  > it has every feature. Not yet, but there is continued enthusiasm for adding more features to C++. Bjarne wants it to have lifetime tracking. Wouldn't it be nice if your C++ compiler could point out that you can't very well return this object since you've no reason to think it will exist by the time you return? Vittorio wants it to have Rust-style language version management through epochs. Herb wants it to offer slimmer exceptions instead of the bulky mess that people often opt to switch off entirely. All of them agree C++ is too big. However, before it can be slimmed down properly, they just have one more thing to add...
  - pjmlp 5y ago
    Just like C keeps getting features, C2X is around the corner. Get ready for lambdas and better generic programming support. They just keep forgetting to add safer types.
    - jstimpfle 5y ago
      As always, good trolling pjmlp. There was a proposal of a some lambda thing. From looking briefly over it, it seemed too complicated to me. I hope it doesn't get included. If you look on the Wikipedia page for C2X, there is no mention of lambda: https://en.wikipedia.org/wiki/C2x https://en.wikipedia.org/wiki/C2x . Instead, pretty much all that is listed there are small and useful cleanups of the standard: - two's complemement is required, which I assume will remove some UBs - Labels can appear before declarations and at the end of compound statements - Removal of K&R function definitions - Unnamed parameters in function definitions In fact those are some of the major complaints people are having with the language currently. As well as some very useful features that are small and self-contained - A feature for binary resource inclusion in the preprocessor (#embed) - Binary literals such as 0b10101010 - _Static_assert I don't know the process and the people well enough to say I agree with everything WG 14 does, but I'll say that's how you improve quality of life while staying humble. The changes I see here, no chance of having to fix some grand idea over decades, like with RAII which requires N new type specifiers and constructors, move semantics...
dang 5y ago
Please don't start programming language flamewars on HN. We want curious conversation here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- rvz 5y ago
  Oh dear. Looks like the grandparent comment totally ruined this whole post and created another language war that isn't need here. I really wanted to know how Bloomberg uses OCaml since they are silver sponsors of OCaml [0], but it wasn't clear how they used the language in production anywhere, until right now in this post here. But unfortunately, the opinions are mostly about X language vs Y rather than the post itself. It is ruined and that's not good at all. [0] https://ocaml-sf.org/ https://ocaml-sf.org/

paulddraper 5y ago

> "Why we like OCaml" page could have been written for C++ Okay, so they forgot the "isn't insanely complicated and abtruse" bullet point? (EDIT: I don't mean to flame on C++. But slides notwithstanding, the difference between the two is pretty obvious.)

pjmlp 5y ago
Bloomberg is a major ISO C++ contributor as well.

yawaramin 5y ago

‘Fast compilation speed’? Nah, lol

fnord123 5y ago
OCaml compile speeds are not particularly fast.
- yawaramin 5y ago
  Compared to what?
  - fnord123 5y ago
    On par with Java but without maven startup time.
    - yawaramin 5y ago
      Admittedly I’m not citing actual numbers (but then again neither is anyone else here), but subjectively based on past experience, I highly doubt that. The OCaml compile is super parallelizable, with no forward references i.e. potential dependency cycles like in Java. My feeling is it blows Java out of the water.
    - pjmlp 5y ago
      You don't need Maven to compile Java code, additionally when using Eclipse incremental compiler, files are compiled on save.
- dwohnitmok 5y ago
  I'm curious do you have concrete data for this? I would love to see compile times for representative codebases of various sizes across languages and how they've changed across compiler versions. From anecdotal experience I view OCaml's bytecode compile speeds to be on par with Go's (as a rule of thumb I expect about 1 second per 10k lines). Far slower than something like TCC, but quite fast among other languages.
  - fnord123 5y ago
    I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, running on identical machines. As for your view of OCaml byte code compilation speed being on par with Go seems rather unlikely or I'm misunderstanding what you mean. Go is not dealing with anywhere as near a complex type system as OCaml and generates a lot more potato machine code (usually not using -mnative so you can know you can copy a binary to arbitrary machines).
    - EduardoRFS 5y ago
      OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.
      - reecko 5y ago
        > OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
        pjmlp 5y ago
        Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.
    - 5y ago
- EduardoRFS 5y ago
  OCaml is really good at building in parallel. So even without that many files it can still compile using 32 threads. Making so that a project with 20k loc is less than a second in debug mode. And recompile time in native(debug) mode is almost 100% linking time. For bytecode you can have wild rebuild times, in the milisecond range.
  - fnord123 5y ago
    Pyre[1] is about 20k loc of ocaml[2]. $ time make -C source -j8 make: Entering directory '/home/fnord123/src/download/pyre-check/source' ../scripts/setup.sh --configure Build info: Linux x86_64 @ Mon Aug 23 2021 (development build) abort: no repository found in '/home/fnord123/src/download/pyre-check/source' (.hg not found)! Git commit: 1e4dd5a39db1631fd13a3a8df74d6e0f5d801fbc dune build @install -j auto --profile dev menhir parser/generator.{ml,mli} Warning: 31 states have shift/reduce conflicts. Warning: 5 states have reduce/reduce conflicts. Warning: 77 shift/reduce conflicts were arbitrarily resolved. Warning: 75 reduce/reduce conflicts were arbitrarily resolved. make: Leaving directory '/home/fnord123/src/download/pyre-check/source' real 0m43.700s user 4m3.030s sys 0m41.005s I must be doing something wrong. [1] https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [2] $ tokei ------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ------------------------------------------------------------------------------- Autoconf 2 235 204 3 28 C 15 242641 165361 60669 16611 C Header 10 14267 2617 11094 556 Coq 10 2391 1968 220 203 CSS 5 713 540 44 129 Dockerfile 2 71 42 11 18 HTML 2 35 30 0 5 INI 1 12 9 0 3 Java 31 2654 2080 267 307 JavaScript 7 867 752 61 54 JSON 17 939 939 0 0 Makefile 5 229 145 45 39 Markdown 47 7213 7213 0 0 OCaml 791 229096 198302 10455 20339 Python 398 61909 50119 2917 8873 Shell 5 111 59 34 18 SVG 2 2 2 0 0 TeX 4 929 642 129 158 Plain Text 5 457 457 0 0 TOML 1 2 2 0 0 TypeScript 2 130 84 20 26 ------------------------------------------------------------------------------- Total 1362 564903 431567 85969 47367 -------------------------------------------------------------------------------
- zem 5y ago
  compared to what? it's definitely one of the fastest-compiling languages i use.

therealdrag0 5y ago

Sure. But I think it’s good that there is diversity of languages being used out there. No skin off my back for them to use OCaml so go for it!

rowanG077 5y ago

I really wouldn't call C++s type system expressive. And neither would I say it's community is small or enthusiastic. And compile times are fast in C++? What are you smoking?

jcelerier 5y ago
Can OCaml's type system express a type parametrized on a value, eg. like template<auto f> struct my_type{}; using t1 = my_type<123>; constexpr t1 val1; using t2 = my_type<val1>; ?
- rowanG077 5y ago
  I haven't used ocaml but I think something is possible with GADTs. Beside the example you have given shows C++ templating prowess and not its type system. In general I wouldn't call a type system that doesn't support ADTs expressive.
  - jcelerier 5y ago
    But GADTs are expressible in the C++ type system (thanks to templates which are just the C++ implementation of the parametrizable types typesystem-level property)
- yawaramin 5y ago
  No, but on the other hand it doesn’t monomorphize generics and make the compiles dog slow and the binaries bloated :-)
  - andrepd 5y ago
    Well, but it does make the code slower
    - yawaramin 5y ago
      I knew someone would say that :-) ‘Slower’ is super subjective. What is the actual performance requirement? And remember that the OP thread is talking about an extremely high-performance RPC system. Sure, it may not be as fast as C++, but again, what is the actual performance requirement. You don’t go around just throwing ‘Eh, not as fast as C++’ at everything you come across :-)

iso8859-1 5y ago

It would be weird for this slide to list all the things that they don't like. But that is what they'd have to do with C++, since its problem is not the features it has, but that it has every feature.

tialaramex 5y ago
> it has every feature. Not yet, but there is continued enthusiasm for adding more features to C++. Bjarne wants it to have lifetime tracking. Wouldn't it be nice if your C++ compiler could point out that you can't very well return this object since you've no reason to think it will exist by the time you return? Vittorio wants it to have Rust-style language version management through epochs. Herb wants it to offer slimmer exceptions instead of the bulky mess that people often opt to switch off entirely. All of them agree C++ is too big. However, before it can be slimmed down properly, they just have one more thing to add...
- pjmlp 5y ago
  Just like C keeps getting features, C2X is around the corner. Get ready for lambdas and better generic programming support. They just keep forgetting to add safer types.
  - jstimpfle 5y ago
    As always, good trolling pjmlp. There was a proposal of a some lambda thing. From looking briefly over it, it seemed too complicated to me. I hope it doesn't get included. If you look on the Wikipedia page for C2X, there is no mention of lambda: https://en.wikipedia.org/wiki/C2x https://en.wikipedia.org/wiki/C2x . Instead, pretty much all that is listed there are small and useful cleanups of the standard: - two's complemement is required, which I assume will remove some UBs - Labels can appear before declarations and at the end of compound statements - Removal of K&R function definitions - Unnamed parameters in function definitions In fact those are some of the major complaints people are having with the language currently. As well as some very useful features that are small and self-contained - A feature for binary resource inclusion in the preprocessor (#embed) - Binary literals such as 0b10101010 - _Static_assert I don't know the process and the people well enough to say I agree with everything WG 14 does, but I'll say that's how you improve quality of life while staying humble. The changes I see here, no chance of having to fix some grand idea over decades, like with RAII which requires N new type specifiers and constructors, move semantics...

dang 5y ago

Please don't start programming language flamewars on HN. We want curious conversation here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

rvz 5y ago
Oh dear. Looks like the grandparent comment totally ruined this whole post and created another language war that isn't need here. I really wanted to know how Bloomberg uses OCaml since they are silver sponsors of OCaml [0], but it wasn't clear how they used the language in production anywhere, until right now in this post here. But unfortunately, the opinions are mostly about X language vs Y rather than the post itself. It is ruined and that's not good at all. [0] https://ocaml-sf.org/ https://ocaml-sf.org/