7 ms·

Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure

by jwr 8y ago

Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure", because I was afraid they would get scared. But then I noticed that nobody actually cares much about what tools you use, as long as they get the job done. The end result is what counts.

samsonradu 8y ago
Many times it is hard to pinpoint what/when the ‘end result’ is. So while the clients are happy now, they won’t be happy to hear they might have a hard time maintaining the project through the years. Clients will want to know they can hire people to work on the codebase.
- dwaite 8y ago
  Unfortunately most times if an external vendor is delivering custom software the clients have already failed - software has a lifecycle that extends far beyond 1.0 delivery. This is why we still have things like X-UA-Compatible: IE=5.
cmauniada 8y ago
I wish I followed this advice when I was setting up lambdas on aws. There was this general distaste for "java" in the dev community. Doing a new project and this time around I am using java, and it works so beautifully. The second choice would have been python, but I like the strict type checking.
- vajrabum 8y ago
  Do you find that using the JVM in Lambda affects your cold start times? If so, do you have a pre-warm strategy and how does it work? Or maybe it doesn't matter for your application?
  - boyter 8y ago
    I did when I used Java Lambdas behind API gateway for a largish public API. I ended just setting the HTTP purification tests to run every minute. Solved the issue and let me know how stable it was. Not a huge issue in the end.
  - olavgg 8y ago
    Try Micronaut, which is a micro framework specifically designed for superfast startup time and low memory footprint. It also works with GraalVM.
  - sharpy 8y ago
    Lambda does re-use the JVM instances where it can to alleviate that.
    - dlhavema 8y ago
      That only matters if your concurrency is one. If you get 10 requests each before the previous one completes you will get cold starts every other call or so.. its manageable, just takes effort.
- mrep 8y ago
  That is hilariously ironic considering 90% of AWS is written in Java.
  - technion 8y ago
    Have you got a source or more information on this? I'm not disputing the statement - but I've seen several different languages claimed to run "most of AWS" (including Haskell at one point) and it'd be good to have a firmer answer.
    - mrep 8y ago
      I used to work for AWS. The API framework that powers most if not all of AWS API's is called "Coral" and is Java based.
      - jophde 8y ago
        It's like people think Java only supports concurrency via thread pool and isn't capable of event loop / async io models.
peterlk 8y ago
This is not always true. A friend once built an application for the government (I don't remember any more specifics) in Python. He delivered it to them and mentioned in a document somewhere that it was written in python. This was unacceptable to them because python was not on the list of approved languages. So, after some negotiating, he caved, switched the project to Jython (with minimal changes) and delivered it as "running on the JVM". This was seen as acceptable, and the delivery was accepted.
- giancarlostoro 8y ago
  I wonder why that is. I know theres a list of DoD approved software licenses and guidance on using open source software but didnt know there was a list of languages allowed.
  - sharpy 8y ago
    Probably more to do with the runtime environment.
    - sieabahlpark 8y ago
      This is exactly why.
  - dwaite 8y ago
    Some governments (and individual institutions) will have restrictions on only supporting standards because it allows for competing implementations. Some will require multiple implementations directly. Still others may have restrictions based on whether there was a successful audit of the runtime environment.
- misiti3780 8y ago
  That must have changed in the past 10 years because I was working on a DOD project in 2007 and it had a large python component.
  - frank_nitti 8y ago
zmmmmm 8y ago
I still tell people we're using Java instead of Groovy, but that's more because I can't be bothered having the repeated 5 minute discussion with them about what it is. (Besides that, I actually consider Groovy almost to be essentially like a template engine or set of macros for writing Java code. It's not like other JVM languages that try to introduce a different style).
- linkmotif 8y ago
  Groovy, the real JavaScript. I love Spock but never could get into using Groovy for non-test code.
  - zmmmmm 8y ago
    Yeah, you really need to adopt a completely different style if you're writing a whole applications with Groovy as opposed to scripting or test code. It's like a different language almost (more like nicer Java). It does work quite well for it when you do that though.
    - linkmotif 8y ago
      I really like groovy with all its groovy idioms and its extended library. It’s really fun to Google for how to write something in Groovy you usually get something really ice. I just didn’t like the lack of typing for non test code. And spotty IDE support even in IntelliJ. It seems to be perfect for tests because your code still compiles and you can fix the tests when you’re ready. Also Spock is beautiful...
  - nitrogen 8y ago
    You might enjoy Kotlin.
    - linkmotif 8y ago
      Yeah I really want to move to a language with pattern matching. Hopefully it will finally land in Java
raverbashing 8y ago
> But then I noticed that nobody actually cares much about what tools you use, as long as they get the job done. Unfortunately there are a lot of cases where this matter: - Customer requires the sw to run on their standard environment (think some version of RHEL, or some Windows Server version). Hence you're limited to what's supported there (usually from the vendor). No bleeding edge versions of Python/Node/.NET etc. You might need to build a Go or Rust binary for that specific system and it might not always be obvious. Java might be a different story, but I wouldn't risk it. - Embedded software (for similar reasons) - Sw that needs to run on a customer's system - Sw that needs to interface with an existing system (loading a DLL/.so? JVM?)
- marco_salvatori 8y ago
  Yes. When a client hires a developer, he cares that he receives a proper delivery and he cares that all of the decisions related to that delivery were made in his best interests. Technology choices are an important part of building a technical vision for a company and planning for software maintenance. People may not seem to care much, but that's only because they are trusting the people they hire to care and to know better than they do. When there are any questions on technology, clients appreciate and value unbiased discussion on those choices, in the context of their business. An important part of having clients, perhaps the most important, is establishing trust and one does that with success, but also a record of transparent, appropriate project decisions.
trimbo 8y ago
> Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure", because I was afraid they would get scared. That seems... dishonest? What happens when the client wants to hire someone else in the future, only to find out it's not Java, it's actually this language which is not mainstream at all?
- sethhochberg 8y ago
  I think it would be dishonest if the agreement was that the software should be built in Java - but to me, this reads more like an operational concern. The client felt comfortable with a software package they can deploy on the JVM... but that doesn't necessarily mean they cared whether it was written in Java. If I were hiring a dev for a Java project, I'd explicitly hire a Java developer, not just someone who promised a product which would run on the JVM.
  - OkGoDoIt 8y ago
    I think the point is the client might not be sophisticated enough to realize there’s a distinction there. If my auto mechanic replaced a part in my car with something that worked basically the same but cost me a lot of time and money and hassle to fix when it breaks down the road, I’d be pretty upset, especially if he strongly implied that he replaced it with a normal part.
    - trimbo 8y ago
      > I think the point is the client might not be sophisticated enough to realize there’s a distinction there Yup, that's exactly my point. Your car analogy is a good one. I was going to make a similar one with house construction but you've hit on it well.
deleted 8y ago
[deleted]
baud147258 8y ago
Actually, I think there are cases where the clients would care: for example with on-premise software, using either the OpenJDK or Oracle JVM will incur different costs. Idem with Oracle/SQL Server.

by jwr 8y ago

samsonradu 8y ago

Many times it is hard to pinpoint what/when the ‘end result’ is. So while the clients are happy now, they won’t be happy to hear they might have a hard time maintaining the project through the years. Clients will want to know they can hire people to work on the codebase.

dwaite 8y ago
Unfortunately most times if an external vendor is delivering custom software the clients have already failed - software has a lifecycle that extends far beyond 1.0 delivery. This is why we still have things like X-UA-Compatible: IE=5.

cmauniada 8y ago

I wish I followed this advice when I was setting up lambdas on aws. There was this general distaste for "java" in the dev community. Doing a new project and this time around I am using java, and it works so beautifully. The second choice would have been python, but I like the strict type checking.

vajrabum 8y ago
Do you find that using the JVM in Lambda affects your cold start times? If so, do you have a pre-warm strategy and how does it work? Or maybe it doesn't matter for your application?
- boyter 8y ago
  I did when I used Java Lambdas behind API gateway for a largish public API. I ended just setting the HTTP purification tests to run every minute. Solved the issue and let me know how stable it was. Not a huge issue in the end.
- olavgg 8y ago
  Try Micronaut, which is a micro framework specifically designed for superfast startup time and low memory footprint. It also works with GraalVM.
- sharpy 8y ago
  Lambda does re-use the JVM instances where it can to alleviate that.
  - dlhavema 8y ago
    That only matters if your concurrency is one. If you get 10 requests each before the previous one completes you will get cold starts every other call or so.. its manageable, just takes effort.
mrep 8y ago
That is hilariously ironic considering 90% of AWS is written in Java.
- technion 8y ago
  Have you got a source or more information on this? I'm not disputing the statement - but I've seen several different languages claimed to run "most of AWS" (including Haskell at one point) and it'd be good to have a firmer answer.
  - mrep 8y ago
    I used to work for AWS. The API framework that powers most if not all of AWS API's is called "Coral" and is Java based.
    - jophde 8y ago
      It's like people think Java only supports concurrency via thread pool and isn't capable of event loop / async io models.

peterlk 8y ago

This is not always true. A friend once built an application for the government (I don't remember any more specifics) in Python. He delivered it to them and mentioned in a document somewhere that it was written in python. This was unacceptable to them because python was not on the list of approved languages. So, after some negotiating, he caved, switched the project to Jython (with minimal changes) and delivered it as "running on the JVM". This was seen as acceptable, and the delivery was accepted.

giancarlostoro 8y ago
I wonder why that is. I know theres a list of DoD approved software licenses and guidance on using open source software but didnt know there was a list of languages allowed.
- sharpy 8y ago
  Probably more to do with the runtime environment.
  - sieabahlpark 8y ago
    This is exactly why.
- dwaite 8y ago
  Some governments (and individual institutions) will have restrictions on only supporting standards because it allows for competing implementations. Some will require multiple implementations directly. Still others may have restrictions based on whether there was a successful audit of the runtime environment.
misiti3780 8y ago
That must have changed in the past 10 years because I was working on a DOD project in 2007 and it had a large python component.
- frank_nitti 8y ago

zmmmmm 8y ago

I still tell people we're using Java instead of Groovy, but that's more because I can't be bothered having the repeated 5 minute discussion with them about what it is. (Besides that, I actually consider Groovy almost to be essentially like a template engine or set of macros for writing Java code. It's not like other JVM languages that try to introduce a different style).

linkmotif 8y ago
Groovy, the real JavaScript. I love Spock but never could get into using Groovy for non-test code.
- zmmmmm 8y ago
  Yeah, you really need to adopt a completely different style if you're writing a whole applications with Groovy as opposed to scripting or test code. It's like a different language almost (more like nicer Java). It does work quite well for it when you do that though.
  - linkmotif 8y ago
    I really like groovy with all its groovy idioms and its extended library. It’s really fun to Google for how to write something in Groovy you usually get something really ice. I just didn’t like the lack of typing for non test code. And spotty IDE support even in IntelliJ. It seems to be perfect for tests because your code still compiles and you can fix the tests when you’re ready. Also Spock is beautiful...
- nitrogen 8y ago
  You might enjoy Kotlin.
  - linkmotif 8y ago
    Yeah I really want to move to a language with pattern matching. Hopefully it will finally land in Java

raverbashing 8y ago

> But then I noticed that nobody actually cares much about what tools you use, as long as they get the job done. Unfortunately there are a lot of cases where this matter: - Customer requires the sw to run on their standard environment (think some version of RHEL, or some Windows Server version). Hence you're limited to what's supported there (usually from the vendor). No bleeding edge versions of Python/Node/.NET etc. You might need to build a Go or Rust binary for that specific system and it might not always be obvious. Java might be a different story, but I wouldn't risk it. - Embedded software (for similar reasons) - Sw that needs to run on a customer's system - Sw that needs to interface with an existing system (loading a DLL/.so? JVM?)

marco_salvatori 8y ago
Yes. When a client hires a developer, he cares that he receives a proper delivery and he cares that all of the decisions related to that delivery were made in his best interests. Technology choices are an important part of building a technical vision for a company and planning for software maintenance. People may not seem to care much, but that's only because they are trusting the people they hire to care and to know better than they do. When there are any questions on technology, clients appreciate and value unbiased discussion on those choices, in the context of their business. An important part of having clients, perhaps the most important, is establishing trust and one does that with success, but also a record of transparent, appropriate project decisions.

trimbo 8y ago

> Back when I worked on building software for clients, I used to tell people "we run all software on the Java Virtual Machine" instead of "it's written in Clojure", because I was afraid they would get scared. That seems... dishonest? What happens when the client wants to hire someone else in the future, only to find out it's not Java, it's actually this language which is not mainstream at all?

sethhochberg 8y ago
I think it would be dishonest if the agreement was that the software should be built in Java - but to me, this reads more like an operational concern. The client felt comfortable with a software package they can deploy on the JVM... but that doesn't necessarily mean they cared whether it was written in Java. If I were hiring a dev for a Java project, I'd explicitly hire a Java developer, not just someone who promised a product which would run on the JVM.
- OkGoDoIt 8y ago
  I think the point is the client might not be sophisticated enough to realize there’s a distinction there. If my auto mechanic replaced a part in my car with something that worked basically the same but cost me a lot of time and money and hassle to fix when it breaks down the road, I’d be pretty upset, especially if he strongly implied that he replaced it with a normal part.
  - trimbo 8y ago
    > I think the point is the client might not be sophisticated enough to realize there’s a distinction there Yup, that's exactly my point. Your car analogy is a good one. I was going to make a similar one with house construction but you've hit on it well.

deleted 8y ago

[deleted]

baud147258 8y ago

Actually, I think there are cases where the clients would care: for example with on-premise software, using either the OpenJDK or Oracle JVM will incur different costs. Idem with Oracle/SQL Server.