4 ms·

> Academia on the other hand will make great languages that never reaches critical mass Interesting choice of words: my guess is that the great languages Acade

> Academia on the other hand will make great languages that never reaches critical mass Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

yawaramin 4y ago
Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1] > Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is <100ms on average. The BuckleScript author estimates that the build system should scale to a few hundred thousands files in the current condition. > Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! * > Most of the messenger core team's new features are now developed in Reason. Dozens of massive refactors while iterating on ReasonReact. Refactoring speed went from days to hours to dozens of minutes. I don't think we've caused more than a few bugs during the process (counted toward the total number of bugs). In a high-velocity codebase, modularity is the name of the game. And you will be hard-pressed to find languages outside the ML family which are that good at modularity. OCaml is just about the only industrial-ready language in this space. [1] https://reasonml.github.io/blog/2017/09/08/messenger-50-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
- dmitriid 4y ago
  Don't buy that propaganda, however well-intentioned it is. At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.
  - yawaramin 4y ago
    Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.
    - dmitriid 4y ago
      I can't find what I wrote at the time, but there were multiple UI/UX issues and logic bugs.
      - yawaramin 4y ago
        In any case, the point I was making was that languages from academia potentially could scale up in high-velocity and larger teams.
- potamic 4y ago
  Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.
  - yawaramin 4y ago
    They are now, at the time the post was written ReScript did not exist and people used to refer to the combination of BuckleScript + Reason as 'ReasonML' for simplicity.
- Zanfa 4y ago
  They must have changed how they report bugs, because the number of issues messenger.com experiences is definitely more than 10 a year. Also super slow.
grumpyprole 4y ago
> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.
- IshKebab 4y ago
  God what's the compilation time of millions of line of Haskell? > In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency. There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.
  - germandiago 4y ago
    Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.
    - grumpyprole 4y ago
      Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.
      - germandiago 4y ago
        Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

yawaramin 4y ago

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1] > Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is <100ms on average. The BuckleScript author estimates that the build system should scale to a few hundred thousands files in the current condition. > Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! * > Most of the messenger core team's new features are now developed in Reason. Dozens of massive refactors while iterating on ReasonReact. Refactoring speed went from days to hours to dozens of minutes. I don't think we've caused more than a few bugs during the process (counted toward the total number of bugs). In a high-velocity codebase, modularity is the name of the game. And you will be hard-pressed to find languages outside the ML family which are that good at modularity. OCaml is just about the only industrial-ready language in this space. [1] https://reasonml.github.io/blog/2017/09/08/messenger-50-reason https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

dmitriid 4y ago
Don't buy that propaganda, however well-intentioned it is. At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.
- yawaramin 4y ago
  Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.
  - dmitriid 4y ago
    I can't find what I wrote at the time, but there were multiple UI/UX issues and logic bugs.
    - yawaramin 4y ago
      In any case, the point I was making was that languages from academia potentially could scale up in high-velocity and larger teams.
potamic 4y ago
Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.
- yawaramin 4y ago
  They are now, at the time the post was written ReScript did not exist and people used to refer to the combination of BuckleScript + Reason as 'ReasonML' for simplicity.
Zanfa 4y ago
They must have changed how they report bugs, because the number of issues messenger.com experiences is definitely more than 10 a year. Also super slow.

grumpyprole 4y ago

> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

IshKebab 4y ago
God what's the compilation time of millions of line of Haskell? > In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency. There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.
- germandiago 4y ago
  Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.
  - grumpyprole 4y ago
    Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.
    - germandiago 4y ago
      Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.