[HN Gopher] OCaml at Bloomberg
___________________________________________________________________
OCaml at Bloomberg
Author : yawaramin
Score : 108 points
Date : 2021-08-23 16:43 UTC (6 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| frozenport wrote:
| "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=...
| iso8859-1 wrote:
| 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 wrote:
| > 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...
| yawaramin wrote:
| 'Fast compilation speed'? Nah, lol
| fnord123 wrote:
| OCaml compile speeds are not particularly fast.
| zem wrote:
| compared to what? it's definitely one of the fastest-
| compiling languages i use.
| EduardoRFS wrote:
| 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 wrote:
| 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 [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 ------------------------------
| -------------------------------------------------
| Jtsummers wrote:
| > Pyre[1] is about 20k loc of ocaml[2].
|
| Reading your table, there are 198302 lines of OCaml code.
| That's about 10x larger than the 20k you claim. The 20339
| in that row is the count of blank lines. I doubt they
| matter much here.
| fnord123 wrote:
| Argh I misread the number of digits.
| yawaramin wrote:
| Compared to what?
| fnord123 wrote:
| On par with Java but without maven startup time.
| yawaramin wrote:
| 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.
| dwohnitmok wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dwohnitmok wrote:
| Hindley-Milner typechecking in practice is quite fast (as
| evidenced by ocamlc and Elm's compiler) and easily on par
| or faster than Go's typechecker (my rule of thumb for Elm
| code is usually 1 second per 100k lines).
|
| In general HM-based type systems are both conceptually
| quite simple and can have quite fast implementations.
| What makes them seem "complex" is that languages with HM-
| based type systems also tend to make it hard to "go
| around" the type system and enforce much more rigid
| discipline around how your code can be written.
| therealdrag0 wrote:
| 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 wrote:
| 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?
| [deleted]
| jcelerier wrote:
| 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>; ?
| yawaramin wrote:
| No, but on the other hand it doesn't monomorphize generics
| and make the compiles dog slow and the binaries bloated :-)
| andrepd wrote:
| Well, but it does make the code slower
| yawaramin wrote:
| 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 :-)
| rowanG077 wrote:
| How is slower subjective? Performance of two pieces of
| code can be objectively measured. There is nothing
| subjective about it.
| yawaramin wrote:
| Who cares? What use is measuring the objective
| performance difference between two solutions if _no one
| cares_ about the difference? That's why I'm talking about
| the _actual performance requirement._
| rowanG077 wrote:
| That's an incredible arrogant and close minded way to
| think about software. There are plenty of domains where
| every extra % of performance matters. Video games, HFT,
| robotics etc.
| krapht wrote:
| This is a pretty obnoxious way to tell me you don't work
| on real-time systems without explicitly saying you don't
| work on real-time systems.
| jolux wrote:
| I feel like if your concern is real-time systems, you
| should probably say you don't think it's suitable for
| real-time systems, instead of talking about performance
| differences that no one really disagrees but which don't
| matter in practice for most applications anyways.
| yawaramin wrote:
| I didn't realize we were exclusively talking about real-
| time systems? Do you think people you argue with on HN
| are so dumb that they would go around claiming high-level
| GC languages are suitable for real-time systems?
| detaro wrote:
| Asking about the _actual requirement_ sounds very much
| like what you do in real-time systems, vs just being
| happy with "faster"?
| paulddraper wrote:
| No, the type system parameterizes on types.
| adamwk wrote:
| People are downvoting but the GP's point does not really
| have anything to do with type systems. I think this
| example is closer to macro expansion than a typesystem.
| stonemetal12 wrote:
| Not exactly types, but with functors you can parameterize
| modules on values. As far as I can tell it ends up being
| very similar.
| rowanG077 wrote:
| 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.
| dang wrote:
| Please don't start programming language flamewars on HN. We
| want curious conversation here.
|
| https://news.ycombinator.com/newsguidelines.html
| paulddraper wrote:
| > "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.)
___________________________________________________________________
(page generated 2021-08-23 23:01 UTC)