3 ms·

I'm a full time OCaml dev these days and I run into OCaml's 'lack of lightweight anonymous recursive functions' maybe three times a year. It costs 3 lines of co

by pgroves 15y ago

I'm a full time OCaml dev these days and I run into OCaml's 'lack of lightweight anonymous recursive functions' maybe three times a year. It costs 3 lines of code to declare the function (called loop() or whatever) and then call it. I've never realized I was supposed to want to switch languages because of it. Otherwise, this comment makes me more interested in Go than I have been before. OCaml has a bazillion features that I never use, and since every OCaml program can look completely different by using those features, the libraries outside the standard lib are all but incompatible with my code.

zem 15y ago
what about pattern matching? that is imo one of the saddest omissions from go - it's not a "huge" feature like continuations, but i find it makes a language significantly more pleasant to work with.
- uriel 15y ago
  Channels + select are a pretty good replacement for what one usually uses pattern matching in Erlang. There are pros and cons for both models, but they are roughly equivalent and I never missed pattern matching in Go.
  - ootachi 15y ago
    Pattern matching isn't just a feature to aid concurrent programming; it's extremely helpful for all sorts of code. However, since Go doesn't have unions (either tagged or unsafe), pattern matching in Go wouldn't be particularly powerful anyway.
- munificent 15y ago
  I asked Rob Pike why they didn't add pattern-matching given that it already has multiple returns and some other baby steps in that direction. His response was, "We considered it, but it turned out to be too much work in the compiler." That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user, don't have to?
  - uriel 15y ago
    The cost of complexity in the compiler is not only to the persons implementing it. Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.

by pgroves 15y ago

zem 15y ago

what about pattern matching? that is imo one of the saddest omissions from go - it's not a "huge" feature like continuations, but i find it makes a language significantly more pleasant to work with.

uriel 15y ago
Channels + select are a pretty good replacement for what one usually uses pattern matching in Erlang. There are pros and cons for both models, but they are roughly equivalent and I never missed pattern matching in Go.
- ootachi 15y ago
  Pattern matching isn't just a feature to aid concurrent programming; it's extremely helpful for all sorts of code. However, since Go doesn't have unions (either tagged or unsafe), pattern matching in Go wouldn't be particularly powerful anyway.
munificent 15y ago
I asked Rob Pike why they didn't add pattern-matching given that it already has multiple returns and some other baby steps in that direction. His response was, "We considered it, but it turned out to be too much work in the compiler." That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user, don't have to?
- uriel 15y ago
  The cost of complexity in the compiler is not only to the persons implementing it. Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.