15 ms·

A case study from my own personal experience: We generally do everything in Java. Python is avoided because of all the usual complaints - dynamically typed, no

A case study from my own personal experience: We generally do everything in Java. Python is avoided because of all the usual complaints - dynamically typed, not fast enough, GIL, etc. So, as a PoC, I decided to try rewriting one of our services in Python. And, compared to the Java one, it is: Cheaper to write and maintain. About 1/10 as many SLOC. About 1/20 as many person-hours. Has better static type checks. For example, Java's type checker cannot statically verify for null safety. The Python one I chose does do that. Note that, since I did choose to put type hints on everything, the productivity boost in question cannot be attributed to dynamic typing. (That said, not all 3rd-party libraries have type hints, so, if you want to type check everything, you may have some yak shaving to do.) Uses less RAM. About 1/2 as much. Is faster. Admittedly I'm leaning on numpy, Cython, and friends for this. It may well be much slower for projects where that is not possible. But still, I think that the point about premature operation stands in this case. (Disclaimer: I also have a colleague at $FAMOUS_COMPANY who tells me they are moving off of Python because they found the opposite of the above in many cases. Though I personally suspect that a mitigating factor is that their profit margins and scale are large enough that all the coefficients in their cost/benefit formula are wildly different from the norm.)

killingtime74 5y ago
Kotlin Scala does all these and interface with Java to boot
TheDudeMan 5y ago
> Java's type checker cannot statically verify for null safety. Check out NullAway. > Uses less RAM. About 1/2 as much. Were you on a modern JVM?
- mumblemumble 5y ago
  It's not just null. For example, Java much more frequently leaves you in a situation where you need to cast to/from `Object`. In Python, `Any` type hints can usually be avoided, because of union types.
  - taeric 5y ago
    First, I want to make it clear that if you have a programming style that works for you, please don't take this as an attack against it. Keep using what works. If you find yourself commonly having to cast to/from Object in Java, that is almost certainly something of your own doing.
    - ubercore 5y ago
      What's the "Java way" of accomplishing something like you'd represent with Union or Intersection types?
      - dljsjr 5y ago
        A common interface with all of the required functionality exposed as interface methods. A Java person would argue that if you have a function that takes an object that can be two totally disparate things with no shared functionality then that’s a code smell.
      - taeric 5y ago
        Apologies for forgetting I had posted this... :( My gut would be a visitor for the fully general case. Though, I would also accept that you are using the wrong language for the abstractions your are writing? My guess is it will depend on why you are needing/wanting one of those types. For a lot of plumbing code, these aren't as necessary as stipulated. Yes, there could be some duplication of code. But, especially in a microservice landscape, most of that duplication will be each service doing their version of whatever you are doing.
      - programmer_dude 5y ago
        There is none, without up or down casting. This is just some "guideline" that gets paraded from time to time (in OOP circles). On second thought, I am sure there's a "design pattern" for sum types out there. Why take the easy way out, am I right?
      - deleted 5y ago
        [deleted]
mixedCase 5y ago
Not that I'm a Java proponent, but have you tried doing the same rewrite effort on modern Java and with modern tools? With newer tools and most important of all: your rewrite being a second iteration with the benefit of hindsight, you may notice that the language choice makes less of an impact than expected. IME language differences tend to shine the most when writing something the first time around and its expression capabilities shape the design.
- mumblemumble 5y ago
  I also rewrote a Python service in Java in an attempt to control for that. The results came out similarly in terms of development & maintenance effort. Unfortunately it wasn't a thing where a performance comparison made sense, though, so I didn't really do one. My sense was that the big benefit was actually down to the libraries and syntactic sugar. Dataclasses, comprehensions, and generator functions all have a big impact, but so do things like Python just generally having more ergonomic libraries for talking to databases, producting/consuming REST APIs, and reading/writing data files.
  - xapata 5y ago
    I suspect there's some algorithmic choice hidden in a library in this comparison, where the Python library has the right choice for the job and the Java library has the wrong one.
  - twic 5y ago
    You mentioned NumPy. NumPy is great, and there is basically no Java equivalent. So if you are doing the kind of work which NumPy can help with, it's going to be very hard work to beat it with Java, either in development speed or execution speed. To put it another way, perhaps what you tested here was having a great array library vs not having a great array library! It would be interesting to test Python vs Java on a more generic task, where there isn't a huge advantage from a particular library or set of libraries. It would also be great if someone would write a NumPy-style library for Java. My team would use that a lot!
    - 5y ago
ar_lan 5y ago
> So, as a PoC, I decided to try rewriting one of our services in Python. Not to your main point - but this line threw me off. I really thought you were discussing this as a "person of color", and I was so confused as the relationship of persons of color and Python. ^_^
- xrobledo84 5y ago
  So what does PoC mean here then?
  - twobitshifter 5y ago
    Proof of concept
  - deleted 5y ago
    [deleted]
overtomanu 5y ago
you have to also consider backward compatibility. If at all there is another version change in python like the one that happened from 2.0 to 3.0, maintenance effort would be more.
- BiteCode_dev 5y ago
  Java, Perl and Ruby all had the same. In fact, in 2018, Java 8 was still massively used: https://jaxenter.com/java-8-still-strong-java-10-142642.html https://jaxenter.com/java-8-still-strong-java-10-142642.html Then you have libs and frameworks, and they break compat too. The JS ecosystem basically broke everyone code for 10 years every 6 month. It's not a Python thing.
  - mumblemumble 5y ago
    According to the latest jrebel report, about 70% of Java shops are still on Java 8 as of earlier this year. The changes with Java 9 certainly created plenty of work for me. Java's famous claim to backward compatibility mostly concerns the JVM itself. They have done a killer job there. But the virtual machine is not the same thing as the platform that rests atop it. This is not by way of complaining about Java 9. The changes are good and needed to happen. And the reasons why most people are still on Java 8 are also legitimate. Everyone's handling the situation in a fairly mature way, from what I've seen. The level of histrionics about Python 3, though... I've got a lot less sympathy for that.

killingtime74 5y ago

Kotlin Scala does all these and interface with Java to boot

TheDudeMan 5y ago

> Java's type checker cannot statically verify for null safety. Check out NullAway. > Uses less RAM. About 1/2 as much. Were you on a modern JVM?

mumblemumble 5y ago
It's not just null. For example, Java much more frequently leaves you in a situation where you need to cast to/from `Object`. In Python, `Any` type hints can usually be avoided, because of union types.
- taeric 5y ago
  First, I want to make it clear that if you have a programming style that works for you, please don't take this as an attack against it. Keep using what works. If you find yourself commonly having to cast to/from Object in Java, that is almost certainly something of your own doing.
  - ubercore 5y ago
    What's the "Java way" of accomplishing something like you'd represent with Union or Intersection types?
    - dljsjr 5y ago
      A common interface with all of the required functionality exposed as interface methods. A Java person would argue that if you have a function that takes an object that can be two totally disparate things with no shared functionality then that’s a code smell.
    - taeric 5y ago
      Apologies for forgetting I had posted this... :( My gut would be a visitor for the fully general case. Though, I would also accept that you are using the wrong language for the abstractions your are writing? My guess is it will depend on why you are needing/wanting one of those types. For a lot of plumbing code, these aren't as necessary as stipulated. Yes, there could be some duplication of code. But, especially in a microservice landscape, most of that duplication will be each service doing their version of whatever you are doing.
    - programmer_dude 5y ago
      There is none, without up or down casting. This is just some "guideline" that gets paraded from time to time (in OOP circles). On second thought, I am sure there's a "design pattern" for sum types out there. Why take the easy way out, am I right?
    - deleted 5y ago
      [deleted]

mixedCase 5y ago

Not that I'm a Java proponent, but have you tried doing the same rewrite effort on modern Java and with modern tools? With newer tools and most important of all: your rewrite being a second iteration with the benefit of hindsight, you may notice that the language choice makes less of an impact than expected. IME language differences tend to shine the most when writing something the first time around and its expression capabilities shape the design.

mumblemumble 5y ago
I also rewrote a Python service in Java in an attempt to control for that. The results came out similarly in terms of development & maintenance effort. Unfortunately it wasn't a thing where a performance comparison made sense, though, so I didn't really do one. My sense was that the big benefit was actually down to the libraries and syntactic sugar. Dataclasses, comprehensions, and generator functions all have a big impact, but so do things like Python just generally having more ergonomic libraries for talking to databases, producting/consuming REST APIs, and reading/writing data files.
- xapata 5y ago
  I suspect there's some algorithmic choice hidden in a library in this comparison, where the Python library has the right choice for the job and the Java library has the wrong one.
- twic 5y ago
  You mentioned NumPy. NumPy is great, and there is basically no Java equivalent. So if you are doing the kind of work which NumPy can help with, it's going to be very hard work to beat it with Java, either in development speed or execution speed. To put it another way, perhaps what you tested here was having a great array library vs not having a great array library! It would be interesting to test Python vs Java on a more generic task, where there isn't a huge advantage from a particular library or set of libraries. It would also be great if someone would write a NumPy-style library for Java. My team would use that a lot!
  - 5y ago

ar_lan 5y ago

> So, as a PoC, I decided to try rewriting one of our services in Python. Not to your main point - but this line threw me off. I really thought you were discussing this as a "person of color", and I was so confused as the relationship of persons of color and Python. ^_^

xrobledo84 5y ago
So what does PoC mean here then?
- twobitshifter 5y ago
  Proof of concept
- deleted 5y ago
  [deleted]

overtomanu 5y ago

you have to also consider backward compatibility. If at all there is another version change in python like the one that happened from 2.0 to 3.0, maintenance effort would be more.

BiteCode_dev 5y ago
Java, Perl and Ruby all had the same. In fact, in 2018, Java 8 was still massively used: https://jaxenter.com/java-8-still-strong-java-10-142642.html https://jaxenter.com/java-8-still-strong-java-10-142642.html Then you have libs and frameworks, and they break compat too. The JS ecosystem basically broke everyone code for 10 years every 6 month. It's not a Python thing.
- mumblemumble 5y ago
  According to the latest jrebel report, about 70% of Java shops are still on Java 8 as of earlier this year. The changes with Java 9 certainly created plenty of work for me. Java's famous claim to backward compatibility mostly concerns the JVM itself. They have done a killer job there. But the virtual machine is not the same thing as the platform that rests atop it. This is not by way of complaining about Java 9. The changes are good and needed to happen. And the reasons why most people are still on Java 8 are also legitimate. Everyone's handling the situation in a fairly mature way, from what I've seen. The level of histrionics about Python 3, though... I've got a lot less sympathy for that.