4 ms·

Is it second best though? I can write an app in Go in the same amount of time it would take me in Python and it would be an order of magnitude faster, multithre

Is it second best though? I can write an app in Go in the same amount of time it would take me in Python and it would be an order of magnitude faster, multithreaded, and type checked. Python is really quite slow and error prone if you think about it.

smogcutter 8y ago
You're missing the point, he could've said brainfuck instead of python and the content would be the same: it's hard to motivate yourself to learn something new when you're already productive in another language and want to get work done.
- WrtCdEvrydy 8y ago
  I wonder if that will be the next abstraction layer. A programming language that compiles down into target programming languages. Reminds me of Haxe.
  - brandonhorst 8y ago
    This is already the world with JavaScript. It can be nice as the compiled code is still humanly understandable.
  - bluejekyll 8y ago
    In some senses, this is what all the JVM languages are, or the WASM languages, or C FFI. You can build compatible layers between any languages, but at the end of the day, most people want to be able to read the libraries and other source code they’re working with. Scala, Kotlin, and Java can all interop with each other, but at the end of the day much of the libraries get rewritten between the languages.
  - samatman 8y ago
    In addition to the sibling comments, this is also one of the nice things about the Clojure ecosystem: between the JVM and JS, you can target anything with an OS. I would love to see that expand to have an LLVM/C target; the GC complicates that but it could be done.
- kkarakk 8y ago
  guess what you've discovered the reason for ageism in the software industry. the way languages work nowadays is that it is easier to switch over to another language entirely that better solves your problem than create a new feature in [language you use]. if you can't do this quickly and easily, consider your career kaput when you hit 40
  - vidarh 8y ago
    As someone in my 40's, I find far more of an insistence of sticking to a single language they're familiar with among younger developers. Over the years, I've done commercial work in M68 asm, Awk, shell script, Pascal, C, C++, PHP, Javascript, WordBasic, Java, Ruby, and I've used about a dozen other languages on a hobby basis or out of a wish to learn. But at the same time, I don't randomly switch languages for no good reason. I see the attitude of thinking it is easier to switch as a large part of the problem. Yes, there are cases where a switch is worthwhile. But all to often I see people describing how and why they switch in ways that makes it very clear that they didn't grasp the architectural reasons for why their original solution was broken. The poster-child for that being Twitter, where they went from a Rails-setup that just violated pretty much every basic principle of proper architecture for scaling a messaging platform (I've written quite a bit about this, but the short of it is that their problem had been solved for decades: federate behind the scenes), and blamed it on Ruby and Rails. It's perfectly possible they benefited from their language changes, but the main thing their language change gave them was that it forced them to re-design their system from scratch. And that is a common story. It may well be that blaming a certain platform is sometimes necessary to provide "political cover" to justify a large rewrite, but to me, large scale language changes often suggest covering up design flaws. To bring things back to the article: In this case it's certainly possible Rust is a good choice for them, especially as they had past experience with it and used it in some parts of the system already, but here, to me, this sentence already implies a design problem (lack of concurrency): > The computations themselves are quick, but the problem is that we need to do a lot of them: for each order, we need to go over all available riders to determine which assignment would be the best. Personally, my first step would have been to run the calculations in parallel. Maybe they'd still also want to switch it to Rust, but unless they stop adding riders, they've just deferred the real problem unless they took the opportunity of the switch to Rust to also parallelise the calculations. Another issue here implies another area where a substantial portion of their time is a result of their design rather than language choice: > This means 0.6 second is a Ruby/DB overhead of loading data and sending assignments to riders. Why is there DB load here? There is simply no way that they are dealing with so many riders and locations in any given region that they can not hold an up-to-date view in-memory in the dispatcher (yes, they'll need to record it as well). A lot of developers these days are scared of loading things into memory, but you can often scale systems to 10x or 100x capacity by being willing to maintain in-memory state. Often you'll even end up with simpler systems. This is not to suggest they're wrong to pick Rust or wrong to choose to switch, because that also depends on what they're experienced with and what works for them, but it's to point out that being quick to go for switching languages is often a result of different viewpoints rather than need. And sometimes lack of experience.
j88439h84 8y ago
Not if you use pypy and mypy.
- aldanor 8y ago
  There's also things like numba - basically a Python decorator that lazily JIT-compiles Python functions to LLVM, and supports numpy. For scientific work, it's quite often hard to beat (and sometimes somehow beats a raw c/c++ implementation of the same thing).
- robrtsql 8y ago
  My issue with mypy is that I would like it to verify that I'm passing the right types into functions from my dependencies. For example, I do a lot of scripting with Python and boto3 to interact with AWS, and my scripts often fail the first time because I misread the field name or structure of a JSON object that goes into or comes from the API. It makes me wish I was using Java or Go, because at least then the compiler would have told me it was wrong. I'm not sure if a solution to this exists yet. It seems like it's up to the dependency to adopt mypy as well?
  - j88439h84 8y ago
    Yeah I think so. There is monkeytype which can infer the types from test runs and insert them into source, so its quite easy to add annotations.
ngrilly 8y ago
And it will also use less memory.
ofrzeta 8y ago
I've done development in both and I doubt that you can be as "productive" in Go as in Python on a wide range of subjects. One reason is dynamic typing, the other is the vast amount of libraries the Python ecosystem offers. Nothing has been said about run time or robustness, though.

smogcutter 8y ago

You're missing the point, he could've said brainfuck instead of python and the content would be the same: it's hard to motivate yourself to learn something new when you're already productive in another language and want to get work done.

WrtCdEvrydy 8y ago
I wonder if that will be the next abstraction layer. A programming language that compiles down into target programming languages. Reminds me of Haxe.
- brandonhorst 8y ago
  This is already the world with JavaScript. It can be nice as the compiled code is still humanly understandable.
- bluejekyll 8y ago
  In some senses, this is what all the JVM languages are, or the WASM languages, or C FFI. You can build compatible layers between any languages, but at the end of the day, most people want to be able to read the libraries and other source code they’re working with. Scala, Kotlin, and Java can all interop with each other, but at the end of the day much of the libraries get rewritten between the languages.
- samatman 8y ago
  In addition to the sibling comments, this is also one of the nice things about the Clojure ecosystem: between the JVM and JS, you can target anything with an OS. I would love to see that expand to have an LLVM/C target; the GC complicates that but it could be done.
kkarakk 8y ago
guess what you've discovered the reason for ageism in the software industry. the way languages work nowadays is that it is easier to switch over to another language entirely that better solves your problem than create a new feature in [language you use]. if you can't do this quickly and easily, consider your career kaput when you hit 40
- vidarh 8y ago
  As someone in my 40's, I find far more of an insistence of sticking to a single language they're familiar with among younger developers. Over the years, I've done commercial work in M68 asm, Awk, shell script, Pascal, C, C++, PHP, Javascript, WordBasic, Java, Ruby, and I've used about a dozen other languages on a hobby basis or out of a wish to learn. But at the same time, I don't randomly switch languages for no good reason. I see the attitude of thinking it is easier to switch as a large part of the problem. Yes, there are cases where a switch is worthwhile. But all to often I see people describing how and why they switch in ways that makes it very clear that they didn't grasp the architectural reasons for why their original solution was broken. The poster-child for that being Twitter, where they went from a Rails-setup that just violated pretty much every basic principle of proper architecture for scaling a messaging platform (I've written quite a bit about this, but the short of it is that their problem had been solved for decades: federate behind the scenes), and blamed it on Ruby and Rails. It's perfectly possible they benefited from their language changes, but the main thing their language change gave them was that it forced them to re-design their system from scratch. And that is a common story. It may well be that blaming a certain platform is sometimes necessary to provide "political cover" to justify a large rewrite, but to me, large scale language changes often suggest covering up design flaws. To bring things back to the article: In this case it's certainly possible Rust is a good choice for them, especially as they had past experience with it and used it in some parts of the system already, but here, to me, this sentence already implies a design problem (lack of concurrency): > The computations themselves are quick, but the problem is that we need to do a lot of them: for each order, we need to go over all available riders to determine which assignment would be the best. Personally, my first step would have been to run the calculations in parallel. Maybe they'd still also want to switch it to Rust, but unless they stop adding riders, they've just deferred the real problem unless they took the opportunity of the switch to Rust to also parallelise the calculations. Another issue here implies another area where a substantial portion of their time is a result of their design rather than language choice: > This means 0.6 second is a Ruby/DB overhead of loading data and sending assignments to riders. Why is there DB load here? There is simply no way that they are dealing with so many riders and locations in any given region that they can not hold an up-to-date view in-memory in the dispatcher (yes, they'll need to record it as well). A lot of developers these days are scared of loading things into memory, but you can often scale systems to 10x or 100x capacity by being willing to maintain in-memory state. Often you'll even end up with simpler systems. This is not to suggest they're wrong to pick Rust or wrong to choose to switch, because that also depends on what they're experienced with and what works for them, but it's to point out that being quick to go for switching languages is often a result of different viewpoints rather than need. And sometimes lack of experience.

j88439h84 8y ago

Not if you use pypy and mypy.

aldanor 8y ago
There's also things like numba - basically a Python decorator that lazily JIT-compiles Python functions to LLVM, and supports numpy. For scientific work, it's quite often hard to beat (and sometimes somehow beats a raw c/c++ implementation of the same thing).
robrtsql 8y ago
My issue with mypy is that I would like it to verify that I'm passing the right types into functions from my dependencies. For example, I do a lot of scripting with Python and boto3 to interact with AWS, and my scripts often fail the first time because I misread the field name or structure of a JSON object that goes into or comes from the API. It makes me wish I was using Java or Go, because at least then the compiler would have told me it was wrong. I'm not sure if a solution to this exists yet. It seems like it's up to the dependency to adopt mypy as well?
- j88439h84 8y ago
  Yeah I think so. There is monkeytype which can infer the types from test runs and insert them into source, so its quite easy to add annotations.

ngrilly 8y ago

And it will also use less memory.

ofrzeta 8y ago

I've done development in both and I doubt that you can be as "productive" in Go as in Python on a wide range of subjects. One reason is dynamic typing, the other is the vast amount of libraries the Python ecosystem offers. Nothing has been said about run time or robustness, though.