5 ms·

For 9 out of 10 articles like this - "We rewrote our old code in tired old language FOO with hot new language BAR and it's SO MUCH BETTER!" - I suspect they cou

by sho 7y ago

For 9 out of 10 articles like this - "We rewrote our old code in tired old language FOO with hot new language BAR and it's SO MUCH BETTER!" - I suspect they could have simply rewritten with the same language, engineered it better and applied all the lessons learned, and achieved basically the same result, probably faster. But that doesn't scratch the "new hotness" itch, does it? That said, considering the requirements this thing sounds like it had to meet, perhaps golang was the right choice after all. Unlike certain other projects I know about where they HAD to write everything in golang/microservices/k8s/etc because it HAD TO SCALE, took 18 months instead of the 3 months it would have taken with rails but credit where credit is due - those 2 or 3 requests a minute (peak) are handled very, very quickly.

Barrin92 7y ago
> That said, considering the requirements this thing sounds like it had to meet, perhaps golang was the right choice after all. Yes, in this particular case I don't think 'the new hotness syndrome' applies. The performance limits of python given that it's dynamic and the multithreading problems are fundamental to the language.
- pjmlp 7y ago
  The same old theme. Common Lisp, Dylan, Smalltalk, JavaScript are just as dynamic as Python and yet run circles around its performance. The only thing lacking is more community love for PyPy and similar endeavours.
  - Barrin92 7y ago
    Sure it's true that if you go with one of the compiled versions of dynamic languages you're going to achieve speedups. And in particular in CL some of those can be achieved by making your programs less dynamic (inlining, early binding etc..), but it is in the nature of dynamic programs to be less optimizable than static programs. While interpreted python code is probably as slow as you can get, Go is still ahead of javascript, and Java beats Smalltalk, and something like C/C++ will take you even further. Implementing compilers for dynamic languages is no trivial feat. The amount of labour that went into something like V8 to get it to its current performance is astonishing.
sidlls 7y ago
That may be true in many cases, but this article really resonated with me. I spent more years than I want to admit working on a large machine learning and analytics platform that was originally built with Python. It was, frankly, a nightmare. The dependency problems, the performance issues, the problems with typing and use of data structures were all huge headaches to manage. I have a blog in the engineering organization I work in where I'm basically publishing a series of articles that reflect a similar path the Salesforce article describes, for basically the same reasons. (My group is using Java, not Go, though.)
- blub 7y ago
  You're doing ML in Java? :) What are the equivalents of some of the popular Python libs for that?
  - roseway4 7y ago
    DL4J and the ND4J library are a good start and at a high-level offer equivalent functionality to tensorflow, pytorch, and pandas: https://github.com/eclipse/deeplearning4j https://github.com/eclipse/deeplearning4j
fiedzia 7y ago
>I suspect they could have simply rewritten with the same language, engineered it better and applied all the lessons learned No, you can't do that. There are many benefits that come from underlying technology choices that you can't backport to old stack, and if you try, you'd create a monster nobody would like to touch. There might be fewer developers willing to work with Elm than something else, there are none willing to work with "we rewrote javascript standard libraries so that it kind of resembles Elm, but poorly".

by sho 7y ago

Barrin92 7y ago

> That said, considering the requirements this thing sounds like it had to meet, perhaps golang was the right choice after all. Yes, in this particular case I don't think 'the new hotness syndrome' applies. The performance limits of python given that it's dynamic and the multithreading problems are fundamental to the language.

pjmlp 7y ago
The same old theme. Common Lisp, Dylan, Smalltalk, JavaScript are just as dynamic as Python and yet run circles around its performance. The only thing lacking is more community love for PyPy and similar endeavours.
- Barrin92 7y ago
  Sure it's true that if you go with one of the compiled versions of dynamic languages you're going to achieve speedups. And in particular in CL some of those can be achieved by making your programs less dynamic (inlining, early binding etc..), but it is in the nature of dynamic programs to be less optimizable than static programs. While interpreted python code is probably as slow as you can get, Go is still ahead of javascript, and Java beats Smalltalk, and something like C/C++ will take you even further. Implementing compilers for dynamic languages is no trivial feat. The amount of labour that went into something like V8 to get it to its current performance is astonishing.

sidlls 7y ago

That may be true in many cases, but this article really resonated with me. I spent more years than I want to admit working on a large machine learning and analytics platform that was originally built with Python. It was, frankly, a nightmare. The dependency problems, the performance issues, the problems with typing and use of data structures were all huge headaches to manage. I have a blog in the engineering organization I work in where I'm basically publishing a series of articles that reflect a similar path the Salesforce article describes, for basically the same reasons. (My group is using Java, not Go, though.)

blub 7y ago
You're doing ML in Java? :) What are the equivalents of some of the popular Python libs for that?
- roseway4 7y ago
  DL4J and the ND4J library are a good start and at a high-level offer equivalent functionality to tensorflow, pytorch, and pandas: https://github.com/eclipse/deeplearning4j https://github.com/eclipse/deeplearning4j

fiedzia 7y ago

>I suspect they could have simply rewritten with the same language, engineered it better and applied all the lessons learned No, you can't do that. There are many benefits that come from underlying technology choices that you can't backport to old stack, and if you try, you'd create a monster nobody would like to touch. There might be fewer developers willing to work with Elm than something else, there are none willing to work with "we rewrote javascript standard libraries so that it kind of resembles Elm, but poorly".