5 ms·

Of course weird domain specific libraries are a major reason to use python. I can get my oddball service up in a few days vs weeks or months to replicate some b

by nimish 7y ago

Of course weird domain specific libraries are a major reason to use python. I can get my oddball service up in a few days vs weeks or months to replicate some bizarre library. If all you're doing is basic web stuff then sure you can do it in Lang du jour but even after a decade go doesn't have a competent xml library for example. Time to market is killer. Python buys you time to determine whether your product is even worth building. Deployment sucks though. e: I literally could not have written the services in my current role in a language other than Java or Python without replicating 100kloc libraries. Java would have required a bunch of work to integrate with the other services we had. So: python. If that costs me an extra $1k/mo for servers but gets us a customer paying $100k a month, was it wasteful?

lmm 7y ago
Why was it easier to integrate with those other services from Python than from Java? Only because you already picked Python for those, right? (I agree with you about time to market being the important thing. I don't think Python is winning that game any more though: its dependency management and deployment has fallen behind the rest of the industry, and newer languages have largely caught up with its conciseness without having to make the same compromises)
- nimish 7y ago
  Not really. Setting up a scalable Java service is complicated even with tooling like spring boot, and Java has better libraries for our use case, but the feedback cycle and general code velocity was much slower since we'd be on java 8 among other things. Plus learning spring or a Java ee framework is tantamount to learning a whole new language it wasn't worth the time then.
  - lmm 7y ago
    > Setting up a scalable Java service is complicated even with tooling like spring boot How so? You can use much the same techniques you would in Python, or you can deploy a .war to a bunch of application servers and achieve what you'd do with docker/kubernetes/etc. in a much simpler way. You've also got a much better chance of scaling up with a single instance and not needing to scale horizontally. > the feedback cycle and general code velocity was much slower since we'd be on java 8 among other things What's keeping you on Java 8? Major JVM version upgrades are much easier and safer than even minor Python upgrades. I'm not doubting your situation, but old version of one language versus new version of another is not really a fair basis for comparison. > Plus learning spring or a Java ee framework is tantamount to learning a whole new language it wasn't worth the time then. Sure. I'm not saying it's wrong to choose to stick with the technology you're currently using - there's definitely a cost to switching or learning something new. But it's worth being conscious of whether your technology choices are being driven by legacy constraints and whether you'd want to make a different choice on a green-field project.
    - nimish 7y ago
      1. "Deploying a war to an application server" is a giant pain in the ass when you don't have people deeply familiar with EE app servers and tuning them. Python is not the best choice here but little can beat go's scp deploy 2. Tell that to every library that relied on java EE being shipped with the JDK. A lot of the reason to use Java was these libraries that are, if you're lucky, in maintenance mode. They're still stuck on 8 since it's not worth putting the time to migrate them to 11+ (I don't have that luxury, unfortunately) 3. > technology choices are being driven by legacy constraints This project was greenfield but the problem domain is plagued by legacy constraints (all the way back to mainframes). "Rebuild from scratch" in a nicer, newer language would take years compared to a runway measured in months, so you do the math.
      - lmm 7y ago
        > Python is not the best choice here but little can beat go's scp deploy Java is pretty damn close to that if you take the route of building a shaded jar (and embedding jetty if you need a web server). You need to install the JVM on the target server but that's all. > Tell that to every library that relied on java EE being shipped with the JDK. A lot of the reason to use Java was these libraries that are, if you're lucky, in maintenance mode. I don't think I ever saw a library like that? There's a huge, high-quality ecosystem of open-source Java libraries and I've never heard of any of them being reliant on Java EE. > This project was greenfield but the problem domain is plagued by legacy constraints (all the way back to mainframes). "Rebuild from scratch" in a nicer, newer language would take years compared to a runway measured in months, so you do the math. Sure, but you can't say this project is an example of when Python is a good technology choice if really the main reason you were using Python was because of legacy constraints.

by nimish 7y ago

lmm 7y ago

Why was it easier to integrate with those other services from Python than from Java? Only because you already picked Python for those, right? (I agree with you about time to market being the important thing. I don't think Python is winning that game any more though: its dependency management and deployment has fallen behind the rest of the industry, and newer languages have largely caught up with its conciseness without having to make the same compromises)

nimish 7y ago
Not really. Setting up a scalable Java service is complicated even with tooling like spring boot, and Java has better libraries for our use case, but the feedback cycle and general code velocity was much slower since we'd be on java 8 among other things. Plus learning spring or a Java ee framework is tantamount to learning a whole new language it wasn't worth the time then.
- lmm 7y ago
  > Setting up a scalable Java service is complicated even with tooling like spring boot How so? You can use much the same techniques you would in Python, or you can deploy a .war to a bunch of application servers and achieve what you'd do with docker/kubernetes/etc. in a much simpler way. You've also got a much better chance of scaling up with a single instance and not needing to scale horizontally. > the feedback cycle and general code velocity was much slower since we'd be on java 8 among other things What's keeping you on Java 8? Major JVM version upgrades are much easier and safer than even minor Python upgrades. I'm not doubting your situation, but old version of one language versus new version of another is not really a fair basis for comparison. > Plus learning spring or a Java ee framework is tantamount to learning a whole new language it wasn't worth the time then. Sure. I'm not saying it's wrong to choose to stick with the technology you're currently using - there's definitely a cost to switching or learning something new. But it's worth being conscious of whether your technology choices are being driven by legacy constraints and whether you'd want to make a different choice on a green-field project.
  - nimish 7y ago
    1. "Deploying a war to an application server" is a giant pain in the ass when you don't have people deeply familiar with EE app servers and tuning them. Python is not the best choice here but little can beat go's scp deploy 2. Tell that to every library that relied on java EE being shipped with the JDK. A lot of the reason to use Java was these libraries that are, if you're lucky, in maintenance mode. They're still stuck on 8 since it's not worth putting the time to migrate them to 11+ (I don't have that luxury, unfortunately) 3. > technology choices are being driven by legacy constraints This project was greenfield but the problem domain is plagued by legacy constraints (all the way back to mainframes). "Rebuild from scratch" in a nicer, newer language would take years compared to a runway measured in months, so you do the math.
    - lmm 7y ago
      > Python is not the best choice here but little can beat go's scp deploy Java is pretty damn close to that if you take the route of building a shaded jar (and embedding jetty if you need a web server). You need to install the JVM on the target server but that's all. > Tell that to every library that relied on java EE being shipped with the JDK. A lot of the reason to use Java was these libraries that are, if you're lucky, in maintenance mode. I don't think I ever saw a library like that? There's a huge, high-quality ecosystem of open-source Java libraries and I've never heard of any of them being reliant on Java EE. > This project was greenfield but the problem domain is plagued by legacy constraints (all the way back to mainframes). "Rebuild from scratch" in a nicer, newer language would take years compared to a runway measured in months, so you do the math. Sure, but you can't say this project is an example of when Python is a good technology choice if really the main reason you were using Python was because of legacy constraints.