Hacker News Reader

Comment by jwr | Hacker News Reader

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.

View on HN

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.

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.

Probably more to do with the runtime environment.

This is exactly why.

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.

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.

In my experience in the aerospace industry working closely with USAF, it depends entirely on the program (as in military/civil program, not computer program) as well as the systems being targeted for deployment. I worked on projects that allowed Python 2, but not 3, some that only allow the Python that ships with Anaconda or Canopy. Many programs and classified environments are barely getting approval for C++11 and some unfortunate teams are stuck with uncompiled VBA macros behind Excel UIs because the security personnel for their target systems is unable to review compiled code in fewer than 6 months... it is a mess.

C++11 is becoming pretty common. The super computer centers (LCFs) uses C++11 now.

I’ve seen software rejected this at a university as the IT teams (pleural) didn’t like the language it was written in. However the problem was solved by the software vendor withdrawing their quote as we were too hard to deal with.

There is nothing wrong with rejecting software because of the technology it uses.

Think about how important maintenance is. If an organization doesn't have in-house skillset to maintain and enhance software solutions they buy outright, why would they want it?

I agree, though this isn’t what occurred. University IT is wonderous to experience though I am speaking from an experience of just 1. Hopefully your mileage varies.

Why didn't they specify beforehand theor language choice? The negociation about Jython you describe should have taken place before the work started

It likely was, but buried in one of the hundreds of documents they reference.

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.

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.

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.

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?

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.

Try Micronaut, which is a micro framework specifically designed for superfast startup time and low memory footprint. It also works with GraalVM.

Lambda does re-use the JVM instances where it can to alleviate that.

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.

That is hilariously ironic considering 90% of AWS is written in Java.

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.

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.

It's like people think Java only supports concurrency via thread pool and isn't capable of event loop / async io models.

> 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?)

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.

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).

Groovy, the real JavaScript. I love Spock but never could get into using Groovy for non-test code.