5 ms·

I think the key here is: > Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript Since their use of Javascri

I think the key here is: > Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript Since their use of Javascript predates Node (and the rest of that ecosystem, like Webpack or Babel or whatever), they've built up their own Javascript environment that doesn't rely on Node or Node conventions at all. Not so much a "get around odd shitshows" situation as much as a parallel evolution.

robpalmer 6y ago
Yes - you deduced correctly! There was a long period of parallel evolution. Over the last few years we've been able to get back on the standards track. The article describes this as one of the guiding principles. It's why we participate in TC39. Nowadays our tooling stack now uses TypeScript, Babel, Rollup & Terser which I regard as the most mainstream of choices. And we go out of our way to keep things aligned with ECMAScript, e.g. preventing the use of "experimentalDecorators".
- jgalt212 6y ago
  Bloomberg often gets accused of "not invented here" syndrome. But often times in the past, it's been the case that what they need hasn't been invented yet.
  - munificent 6y ago
    Would that make it "invented here" syndrome?
    - erikerikson 6y ago
      Traditionally NIH is the reason for rejecting things. The inverse would be accepting things because they are invented here.
  - ng12 6y ago
    This is endemic in the finance industry. Build something cutting-edge, rake in a bunch of money, and then let your tech rust.
- yaacov 6y ago
  Why did Bloomberg adopt server-side JS in 2005?
  - exdsq 6y ago
    I really want to know the answer to this question, seems a hell of a risk to move to JS prior to Node (for me it’s still a risk even after node because JS!).
    - robpalmer 6y ago
      In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new. JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.com/watch?v=ODgs0eWAIKc https://www.youtube.com/watch?v=ODgs0eWAIKc The main competing technology at the time was Lua which would probably have been a fine alternative. JS won. Four years later Node was released which took server-side JS to a mainstream audience and helped validate the choice. Ten years later saw the ES6 renaissance and the rise of JS as a credible language for application development. Now TypeScript takes it to the next level, enabling large robust systems to be efficiently built using JS. I'm pleased we bet on JS.
      - 0x445442 6y ago
        > The main competing technology at the time was Lua The main competing technology for what exactly? I could easily think of 10 other server side choices off the top of my head from the 2005 time frame; like Java or C# to name a couple. Something is missing here.
        addicted 6y ago
        Interpreted languages with no compile time it seems.
      - 6y ago
hvidgaard 6y ago
I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.
- robpalmer 6y ago
  No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.
  - hvidgaard 6y ago
    That is very true. But I still have a hard time to see the justifications of using JS on the server.
    - robpalmer 6y ago
      I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions. Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary. Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng https://www.youtube.com/watch?v=GrnBXhsr0ng
      - hvidgaard 6y ago
        I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.

robpalmer 6y ago

Yes - you deduced correctly! There was a long period of parallel evolution. Over the last few years we've been able to get back on the standards track. The article describes this as one of the guiding principles. It's why we participate in TC39. Nowadays our tooling stack now uses TypeScript, Babel, Rollup & Terser which I regard as the most mainstream of choices. And we go out of our way to keep things aligned with ECMAScript, e.g. preventing the use of "experimentalDecorators".

jgalt212 6y ago
Bloomberg often gets accused of "not invented here" syndrome. But often times in the past, it's been the case that what they need hasn't been invented yet.
- munificent 6y ago
  Would that make it "invented here" syndrome?
  - erikerikson 6y ago
    Traditionally NIH is the reason for rejecting things. The inverse would be accepting things because they are invented here.
- ng12 6y ago
  This is endemic in the finance industry. Build something cutting-edge, rake in a bunch of money, and then let your tech rust.
yaacov 6y ago
Why did Bloomberg adopt server-side JS in 2005?
- exdsq 6y ago
  I really want to know the answer to this question, seems a hell of a risk to move to JS prior to Node (for me it’s still a risk even after node because JS!).
  - robpalmer 6y ago
    In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new. JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.com/watch?v=ODgs0eWAIKc https://www.youtube.com/watch?v=ODgs0eWAIKc The main competing technology at the time was Lua which would probably have been a fine alternative. JS won. Four years later Node was released which took server-side JS to a mainstream audience and helped validate the choice. Ten years later saw the ES6 renaissance and the rise of JS as a credible language for application development. Now TypeScript takes it to the next level, enabling large robust systems to be efficiently built using JS. I'm pleased we bet on JS.
    - 0x445442 6y ago
      > The main competing technology at the time was Lua The main competing technology for what exactly? I could easily think of 10 other server side choices off the top of my head from the 2005 time frame; like Java or C# to name a couple. Something is missing here.
      - addicted 6y ago
        Interpreted languages with no compile time it seems.
    - 6y ago

hvidgaard 6y ago

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

robpalmer 6y ago
No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.
- hvidgaard 6y ago
  That is very true. But I still have a hard time to see the justifications of using JS on the server.
  - robpalmer 6y ago
    I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions. Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary. Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng https://www.youtube.com/watch?v=GrnBXhsr0ng
    - hvidgaard 6y ago
      I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.