Why we picked Java

https://blog.picnic.nl/why-picnic-picked-java-e53fafe0df1b

by pjmlp • 4 years ago

104 220 4 years ago

blog.picnic.nl

pcw888• 4 years ago

This is interesting because there's so much negativity towards Java, particularly new projects. But Java continues as an enterprise-class language, just as C++ does.

jgrant27• 4 years ago

Plenty of rationalization of how java (the language) is "subjective for developers" in terms of productivity and happiness. From a non-engineer view though, let's be real : nobody ever got fired for picking java. This was just a decision made in favor of managers over the poor engineers that will have to deal with maintaining a large Java code base over time.

_skel3• 4 years ago

As an engineer, Java would be one of the languages I would choose for maintaining a large codebase over time. It is far better for that than most other popular languages.

emodendroket4• 4 years ago

Agreed. Even if we buy into the argument that Java is just wordy and slow to work with, once we're doing with long-lived code that needs maintenance, that's less of a concern than code that's hard to decipher, so the trade-off seems like a good one.

nh23423fefe• 4 years ago

I never understand java hate. The hate seems isomorphic to: "i hate types and i dont use a real ide"

silvestrov• 4 years ago

refactor tools for Java is just so much better than what you can do in a plain text editor or if the language does not have type annotations.

hinkley2• 4 years ago

Large codebases in dynamic languages are the pits. Determining if some bit of code is used and how is a probabilistic exercise. Eventually you learn to give up or YOLO and see what happens.

btilly3• 4 years ago

And so we have a chicken and egg problem.

Thanks to verbosity, Java creates the very problem that it tries to help with.

Did you need to have that many programmers and that much code? Who knows. But once you have it, continuing with Java makes sense.

grumpyprole3• 4 years ago

If that is because of static types then I might agree with you, however once Spring and other reflection-heavy frameworks are added to the mix then I'm not so sure. Java's biggest problem is not the boilerplate, but the culture of over-engineering.

booleandilemma• 4 years ago

I disagree. The alternative is some rockstar developer saying "let's pick Elm!" or "let's pick Elixir!" and then leaving the company after a few months. I'd take Java (or C#) over several other languages in a heartbeat. I'll leave the more esoteric stuff for the weekend, thanks.

Existenceblinks2• 4 years ago

I picked Elm once and I managed to convince my boss to let me got rid of it 6 months+ before I left. Turned out it's a good move! (well.. a not that bad move)

macspoofing• 4 years ago

This was just a decision made in favor of managers over the poor engineers that will have to deal with maintaining a large Java code base over time.

What's wrong with maintaining large Java code bases? Say what you want, but the language is built for that.

The worst code-bases I've seen tend to come from dynamic languages. Try to maintain hundreds of thousands of lines of python or ruby code over several years, and see how fun that is.

From a non-engineer view though, let's be real : nobody ever got fired for picking java.

No. That's not a correct framing. Java is one of the few languages that able to strike a great balance between performance, development productivity, 'debuggability", cross-platform support (i.e. works just as well under Windows as Linux), language safety, and library and framework ecosystem. Honestly, it's hard to come up with a use-case where Java isn't a natural right answer.

Existenceblinks2• 4 years ago

I think nobody fires developers who pick a language the boss or whoever in power doesn't like. And the boss would just say: NO.

whywhywhydude2• 4 years ago

Most of the flak that java gets is from people who have never used/maintained java codebase. I moved from java to python and I actually miss java. It’s much easier to navigate and refactor java code. Yeah, you can write code faster in loosely typed languages like python, but maintaining it is a different story.

nagyf• 4 years ago

At my workplace I would pick Java 8/10 times. I would only pick something else when Java is really not an option (e.g. Scala/Python for Apache Spark, Typescript for CDK).

Maintaining a larga Java code base is very easy (I think much easier than e.g. Python). The tooling is awesome, there are countless libraries, last but not least Java is the easiest to hire for.

ch4s32• 4 years ago

Remember how Twitter had to re-platform from Ruby to Java to support its growth? Definitely not an enticing prospect, so our choice was geared towards the long run. Unlike Twitter, Picnic embraced Java from the get-go!

Once again, it must be said that almost no app will ever be twitter scale. Time to market is more important than needing to do some architecture in the future. Twitter was also early in both Rails and doing globally distributed web apps, a lot of lessons have been learned since and rails itself is much better, it's been almost 12 years after all.

It seems like this article could have stopped with, most Dutch developers already write Java professionally.

spullara• 4 years ago

Honestly the biggest reason we had to re-platform to the JVM was latency (fail whale was a 5s timeout) and not growth. Ruby was just too slow for all the stuff we wanted it to do. It ended up being 10x fewer servers AND 10x lower latency.

skwirl4• 4 years ago

I feel like this is a pretty important comment that busts a popular myth about Twitter and Ruby. The notion that Ruby was a poor choice even for a young Twitter that hadn't hit scale makes Ruby (or at least, late 00s/early 10s Ruby) look even worse than it already does.

tommek4077• 4 years ago

That said: time to market with java is also quite nice and one selling point for it.

lowbloodsugar2• 4 years ago

I think people confuse "I don't personally know Java" with "Java has a slow time to market." Sure, for people that don't know Java, learning Java to that level is definitely going to cost you time.

topspin2• 4 years ago

Java was designed to, and still delivers, rapid development.

Is it possible for java developers to entangle their work through poor choices such that development becomes slow? Absolutely; the java ecosystem has accumulated a number of such tar pits. Competent java developers avoid these.

Unfortunately incompetent java developers abound. The world is full of java developers that haven't learned anything new since Java 6 appeared 16 years ago.

The above argument is also used by C++ advocates; C++ is great if you know what you're doing and apply the solutions provided in modern iterations. Ironic since java was Sun's 'fix' for C++. Given the rapid rise of competitors to C++ I believe that argument isn't working terribly well.

emodendroket4• 4 years ago

True enough. But Java (and other options) have changed in the meantime too. Are the productivity arguments equally true today as they were when Twitter decided on Rails?

ch4s32• 4 years ago

I haven't kept up with Rails or Java for a couple of years, but Rails has always been laser focused on rapid feature delivery. If I knew up front I'd end up with twitter I might not start with Rails, but I wouldn't choose Java either. The truth is, there are a lot of good options today and hiring will be a consideration. I think the big negative for Java there is that almost every dev sort of knows it, so the signal to noise ratio there isn't very good.

_skel3• 4 years ago

A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer.

There is definitely a higher barrier to entry with Java, and starting new projects involves a bit more setup, but that is never the bottleneck. You start a project once. You work on it every day after that. The time it takes to set up the build system is a drop in the bucket compared to the rest of the work. Maybe it will take your company a few more hours to get to market because of that? Big deal.

jeroenhd• 4 years ago

IntelliJ comes with a step by step GUI to set up Spring Boot for you with all kinds of bells and whistles, with the choice between Gradle or Maven for your build chain (last time I checked, maybe they're moving away from Maven at this point). You follow the steps and get going. You can set up a project as fast as the time it takes to Google the exact name of that npm/pypi package.

Sure, you'll want to check your settings before pushing your first code to prod, but the same is very much true for any other "default" deployment.

The same is very much true for other "boring" platforms as well, such as dotnet these days. Getting started is quick and easy.

Java will have a significantly longer setup process if you decide to throw out all the work that's been done for you and implement your own boutique web server and routing system, but that's not a realistic scenario for most companies.

I imagine most of the Java horror stories people recall come from the days where there were no good Java libraries and everyone was reinventing the wheel. Sometimes there are weird dependencies that stop being maintained and rather than fix the problem, companies opt to stick to ancient versions of Java and the JVM, but that's not really a Java problem either, that's a supply chain issue.

I don't understand what the higher barrier to entry is supposed to be like in practice. If you know the basics of backend development in any language, you can get started. Learning to place annotations on top of endpoints is a five minute tutorial process, not dissimilar from how setting up routes in any other language takes reading a page or two to get right.

The only barrier to entry I can think of is that you probably want the full version of IDEA which costs money, though you can use all of its features for free by sticking to the EAP release if you're tight on money.

eternalban2• 4 years ago

There is definitely a higher barrier to entry with Java

This is what is missing from the conversation. Most of us Java fans have been doing Java for a while. I started in '96. We know the JVM. We grew up with Java and were exposed to various aspects of this platform for over 2+ decades. Java the language is not that hard to pick up, but the platform in its total glory is formidable to those new to the language.

I myself never realized this until a few years ago when in course of quizzing a very vocal anti-Java front-end dev in a startup, he blurted "it intimidates me".

And I think this is really the issue.

raverbashing• 4 years ago

A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer.

Really, really doubt this. 100%. Not blaming the developer, surely, but even modern java is more complicated than running something in node.js

The time it takes to set up the build system is a drop in the bucket compared to the rest of the work

It's not just a one-off, Maven will make your development slower every day of the week. Every build, every unit test run, etc

ReflectedImage8• 4 years ago

"A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer"

It takes 2.5x time to develop a program in Java rather than Python. It's been measured.

So you will reach market in 2.5 years instead of 1 year. Bit of a difference to say the least.

hbrn7• 4 years ago

A competent Java programmer is not slower than a competent Python programmer. Time to market won't suffer.

A fast horse is not slower than a fast car.

Languages and ecosystems shape how people think. For example, you will find that Java and Python programmers have very different values and principles. Given same options, they will make extremely different choices. Clearly this is going to have at least some effect on time to market.

I found Java to be a land of overengineering, verbosity, and anti-patterns. The infamous "Hammer Factories" [1] post screams Java to me.

[1] https://www.danstroot.com/posts/2018-10-03-hammer-factories

bsan34• 4 years ago

Java has been improving pretty fast and is starting to close the gap in spots where it's been seen weaker to Go etc. Fact still remains that it has excellent lib ecosystem, tooling, observability and large code bases with multiple teams are much easier managed in static languages. At this point most of the downsides are from legacy frameworks. A modern framework + Kotlin is very productive.

kuratkull• 4 years ago

Really interested what you mean by Java having gaps compared to Golang. You can basically write Golang like code in Java, just leave out any useful language features and you've got it. I have used both professionaly and am not a fan of either. (I really like typed and compiled languages, so those are not my issues with them).

bsan34• 4 years ago

Co-routines .. that's a useful pattern Go did out of the box. Fast startup .. important for containers and auto-scaling

Co-routines have been in Kotlin for a while, got added to Java (Project loom) recently. Same for startup time. Native image support in Project Leyden

nprateem• 4 years ago

Isn't Kotlin slow to compile though? I created a simple hello world Kotlin multiplatform website the other day and it took like 30 seconds to recompile any time I changed anything.

bsan34• 4 years ago

Havent used multi-platform. We use it for Android and Server, seems ok

ryloric2• 4 years ago

Can you list a few modern frameworks? Just curious, I was using Play a few years ago but that was Scala.

bsan34• 4 years ago

Quarkus and Micronaut. Spring replacements almost. Backed by commercial companies and strong dev teams

Super light frameworks, more http focused, Kotor and Javelin

Spring itself had a major overhaul recently

Qtips872• 4 years ago

What about C#? Have you guys considered the .net framework?

synergy20• 4 years ago

C# seems to be the pick for those programmed in microsoft ecosystem in the past, it's not attractive for beginners or non-microsoft-ecosystem developers per se, esp in this cloud and internet era.

metaltyphoon• 4 years ago

it's not attractive for beginners or non-microsoft-ecosystem developers per se, esp in this cloud and internet era

Spoken like its 2002!

mastry• 4 years ago

I’m dumbfounded that anyone would believe that C# is not attractive for cloud development - Microsoft’s platform or otherwise. C# is a fantastic language and dotnet is a great, modern platform. IMO c# is a tad more beginner friendly than Java.

Lariscus• 4 years ago

I am mainly a dotnet developer but even I think that if you already have a team full of Java developers there is little to gain from switching to C#. Just the effort of learning a completely new set of libraries and frameworks would give me pause.

jeremycarter2• 4 years ago

A shout out to Orleans https://learn.microsoft.com/en-us/dotnet/orleans/

waynesonfire• 4 years ago

In fact, we did migrate from Java to Kotlin: only not for our backend codebases, but for our Android app.

good call. that's where it belongs.

ptkanchi• 4 years ago

The correct language to chose as a start up is one that your team has expertise in and allows you to move with speed. It seems silly to over optimize for future "re-architecting"

endisneigh3• 4 years ago

I've always found these types of articles annoying. Pick the language that you know and can hire for cheaply. The end.

If your product or service is a success you can completely rewrite your app and change your entire stack.

fishtoaster2• 4 years ago

Pick the language that you know and can hire for cheaply.

That's exactly what they did.

Go make your thing already.

This article is about a company founded in 2015 that now has a 300-person technical team. They already made their thing and this post is a retrospective looking back at that experience.

endisneigh3• 4 years ago

Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

https://news.ycombinator.com/newsguidelines.html

Also, my comment that is about making their thing is not about this article specifically, but in general as this type of article is very common, but I removed it to clarify my main point.

loganc2342• 4 years ago

I feel like they wanted to make this article because of the bad rap that Java gets in the developer world compared to some “trendier” languages. The article was advocating for the exact approach that you say should be followed when picking a language.

endisneigh3• 4 years ago

I suppose - every article I've read in this vein always has the same conclusion - use what you know, and everything else is just a rationalization. What would be more interesting is the opposite.

duped• 4 years ago

and can hire for cheaply

Unless you're writing things in C or brainfuck, you shouldn't "hire for" language experience.

phillipcarter• 4 years ago

The whole article could have just been this:

Another important factor is that the team of engineers building the first version of Picnic’s platform already had ample experience using Java and the JVM.

And the author of the blog post is a book author on the language and Java Champion, so uhh, yeah, it would be very weird not to go with Java in this case.

shadowgovt3• 4 years ago

Another important factor is that the team of engineers building the first version of Picnic’s platform already had ample experience using Java and the JVM.

Nine times out of ten, that's the whole story.

prhn• 4 years ago

I love Java.

I focused on front-end for 10 years. Starting with motools and IE6, jQuery, into React + Redux. I moved on exclusively to backend development after a few years of the latter.

You couldn't pay me enough to maintain a highly available/scalable system that wasn't written in a "verbose," strongly typed and compiled language. I'm done with that pain. If you're going to pick Node, I hope you're using TypeScript. Python, no thanks.

Refactoring and implementing new features in Java with IntelliJ feels like cheating, in comparison.

Even Go, which I actually really like, starts to lose specificity at large scale due to its intentional terseness. I deeply dislike implied interfaces, and the error handling in a large codebase is really noisy (one of Java's main complaints), without much net benefit.

There definitely was a learning curve with Java. To the untrained eye it looks very noisy and magical, but once you learn to visually parse it and understand what all the annotations do you can move very quickly with low risk.

Your mileage may vary. If you can move fast without breaking things using some other technology, go for it. But I hope you're prepared for success, when 30+ devs are contributing code to your house of cards. You'll want all the natural protections you can get from your choice of stack.

The_Colonel• 4 years ago

Refactoring and implementing new features in Java with IntelliJ feels like cheating, in comparison.

This shines especially in large monoliths. Refactoring microservice interfaces is hell (which means it's rarely done and they rot), refactoring module interfaces in a Java monolith is a breeze.

Very few projects benefit from microservice architecture.

5e92cb50239222b2• 4 years ago

Very few projects benefit from microservice architecture.

I think the pendulum will swing in the other direction, as it usually does. The previous (NoSQL) hype burned out in about ten years, hopefully this one will go out a bit quicker.

CuriouslyC• 4 years ago

It isn't just refactoring them that is hell. Even testing things can be hell - those unit tests just became integration tests or you're rolling the dice with mocks. If you don't get the result you expect from a service call, the lack of a single call stack you can debug up and down means tons of time wasted jumping around.

They're hell for new developers coming on to a project too, since they can't just follow IDE links to trace execution paths, and too few projects implement full REST call request/response type safety for endpoints.

packetlost2• 4 years ago

As someone maintaining a hugely complex system in Python: type hints make it bearable, but not good. A strongly typed, verbose language is an absolute, fucking, *must* for all but the simplest of systems. You can make it work if you're building web services where the type contract is in the web/RPC API (and hopefully strongly enforced), but for basically anything else, use something with a good type system. I cannot stress enough how important it is for scaling complexity.

If you must use Python, turn on mypy with the `--strict` flag, and do it early in your project's lifecycle. Do NOT make exceptions or allow for "gradual" typing, it's monumentally more difficult to add typing after the fact than early on. Type hint as much as you can, including tests. Pytest's fixtures can be type hinted both at the `def` and with their results as function args.

EdwardDiego3• 4 years ago

We should form a support group. Even though I'm pushing Mypy as hard as possible, there's some notable areas it can't help, like unittest.mock call assertions.

ReflectedImage8• 4 years ago

Or you could use Python with microservices that talk over a message queue instead.

neverartful• 4 years ago

Python is strongly typed, but it is not statically typed. Statically typed is what you're after.

nicoburns• 4 years ago

Static types are great, but they can be quite painful in languages like Java that don't support Sum Types/Tagged Unions. I just want to represent "OR" goddammit.

It should also be noted that statically typed doesn't necessarily imply verbose. Many statically typed languages support type inference which more or less gives you the best of both worlds.

5e92cb50239222b2• 4 years ago

Java supports sealed classes (which is close enough to sum types at least for the stuff I work on), and pattern matching over them is in preview.

https://openjdk.org/jeps/409

https://openjdk.org/jeps/427

UncleMeat2• 4 years ago

You can very easily create an Or<T1, T2> class that supports the relevant features.

mradek• 4 years ago

(just my opinion)

I find java mentally exhausting. I have only ever worked with java once, and it was long ago when I just began my career over 6 years ago.

Since then I mostly work with typescript and go on backend, and the languages are quite simple and strange code can be understood quickly without having to dive too much into documentation and navigating a million folders/layers of OO abstraction.

I've tried getting back into java and each time I just get exhausted looking at the code.

dandigangi3• 4 years ago

Similar feelings towards Java. Kotlin has been a refreshing change to read by comparison at my new job. Much less exhausting.

yCombLinks2• 4 years ago

That's not necessarily due to java. I have a guy on my team (we're a java shop) with completely exhausting code. Everything is layers and miles of indirection. No one else here does that. It is admittedly more common in the java world though.

super256• 4 years ago

Your mileage may vary.

Idk, I have written Java EE (and Jakarta EE) projects, and I found everything to be so much worse than e.g. Next.js + TypeScript. It feels like everything is broken in the Java web-dev ecosystem, except spring. I had plenty of struggles with the JPA, where some SQLite JDBC wasn't straight up working or MySQL8 was not supported. This was just to get the project running.

Then, JSPs have like 300 different ways and 300 different opinions on how to do stuff. Should you do routing via XML? Should you put your routes in annotations? Or do implicit navigation in the JSPs? Managing sessions is a pain too.

Setting up and deploying Java application servers in prod is way too complicated compared to Node, Deno, Python, Ruby, Whatever.

Starting with motools and IE6, jQuery, into React + Redux

Anyway, I hope you didn't have to write pure react without any framework on top of it. I mean, the library is fine, and the React patterns mostly stay the same, but React.js is missing a lot. Personally, I wouldn't touch pure react, unless I have to write my own framework on top of it, but that hasn't been the case yet.

P.S. I also had to work on JavaFX applications in the past. I used IntelliJ too, and the tooling of JavaFX is broken to the point, where you can't even use place controls in your great FXML. Which just made me think about another thing I dislike: Java's XML fetish. I don't hate the format, but knowing what XML namespace is the correct one is often beyond me.

Writing new Java is probably fine, but older Java codebases are the often PITA. :(

whywhywhydude2• 4 years ago

XMLs, JSPs, Java EE are relics of the old age. They were built during late 90s and early 2000s. No new projects use them. You can’t say Java is bad because of how things were 20 years ago.

yCombLinks2• 4 years ago

All of the things you complained about were out of fashion before the thing you endorsed was even invented. Hardly a fair comparison.

skwirl4• 4 years ago

It feels like everything is broken in the Java web-dev ecosystem, except spring.

"Except Spring?" Spring IS the modern Java web-dev ecosystem. You can't write it off as a small exception. With Spring Boot it is very easy to get something working quickly.

It sounds like you may be suffering from the Paradox of Choice when it comes to the broad Java ecosystem(s). For new projects, just pretend nothing exists except Spring Boot and use annotation/java config for dependency management.

There's obviously a lot of legacy Java out there, but it's so massively popular that there's an immense amount of greenfield development going on as well. Don't take jobs working on Java EE stuff unless nowhere else will hire you and/or they are paying you a massive amount of money to do it.

rlawson• 4 years ago

Yep Java rocks and is well suited for larger projects. If I have a small team and need to move super fast - then I use Django. If it's > 10 devs and is going to be a large project then it's Java all the way.

metanonsense• 4 years ago

When we started our company 9 years ago (after many years as a freelancer in bloated Java-based enterprise projects), I had only one condition: no Java! With 2022 Java, I definitely would not have asked for that.

ghostwriter4• 4 years ago

In retrospect, it seems that Scala’s popularity has peaked, and we’re happy that we chose the Java programming language.

This doesn't sound like a thorough assessment of Java alternatives one would normally expect from an engineering team. There's hardly any technical reason to choose Java in favour of Scala3 today, except one: the team's lack of Functional Programming expertise. Otherwise, choosing Scala for JVM would almost certainly result in better quality software in terms of safety and internal components design suited for long-term maintenance.

yukinon2• 4 years ago

There's hardly any technical reason to choose Java in favour of Scala3 today, except one: the team's lack of Functional Programming expertise.

I disagree about your premise at multiple points, but I want to focus on just one point - In my experience, Functional Programming is a large enough of a technical reason to not choose Scala in a company of a reasonable size. It's actually such a big reason that it deserves more than as an afterthought as you have it written.

I worked in Scala for 10 years. Not only was it difficult finding seasoned Scala devs, but also we often had to compromise by hiring Java devs and training them on Scala. Time and time again, functional programming was always the most difficult hump for them to grasp and it took experienced devs forever to learn the language and a new paradigm at the same time. Sure, you could hire someone who knew functional programming already and came from a background writing Haskell, but they were rare and usually commanded exorbitant salaries that made sure they were never in the equation to begin with.

Not to mention, you better have a disciplined team with strict linting rules and styleguides, otherwise your devs will go off the rails using Scala in ways that the team isn't prepared to learn. Or if you have Java-trained-Scala devs, they might revert to their old OOP ways.

Because of that, it actually causes more problems, resulting in worse quality software and worse deliveries overall.

It's too much of a risk, really. Especially when Java is not really a terrible choice in a large enough organization - same huge JVM ecosystem, large pool of devs, mature toolset, etc..

ghostwriter4• 4 years ago

I disagree about your premise at multiple points, but I want to focus on just one point - In my experience, Functional Programming is a large enough of a technical reason to not choose Scala in a company of a reasonable size.

You say you disagree with my premise, yet you seem to be confirming the point I made. Your arguments revolve around difficulties with finding devs for a team and with training them to actually understand FP at a level that would allow them to untangle their algorithmic thinking from OOP. It's exactly what I said about the only proper reason to choose Java over Scala: team's lack of FP expertise. Other than that, my point still holds: type algebra and explicit nulls opt-in bring better quality software overall. And it does require FP expertise, not just awareness or vague familiarity with.

otherwise your devs will go off the rails using Scala in ways that the team isn't prepared to learn

This also contributes to my initial point. But I'd like to know what are your examples of off-the-rails, as I've been to situations where a couple of folded traversals had been called similarly "too much" in a Scala codebase, but for someone writing Haskell it was just a regular application of a familiar pattern.

Sure, you could hire someone who knew functional programming already and came from a background writing Haskell, but they were rare and usually commanded exorbitant salaries that made sure they were never in the equation to begin with.

This is a specific argument that could be made within your organisation. I don't know your budgets and the requested salaries by respective candidates, and you didn't clarify the level of expertise your teams were looking for, so I can't make an informed judgement about the merits of this argument and to what extent it could be applied onto the tech stack in general. I've been doing FP for a meaningful amount of time, mostly in Haskell, and the common theme over all these years has always been a visible shortage of FP positions compared to the number of capable candidates willing to compromise on their salary in exchange for an opportunity to use Haskell at their workplace. Many of them were instead compromising on Haskell in exchange for a regular Java-grade salary for writing Scala. And I've never heard of people commanding better salaries just for the fact of being able to write Scala instead of Java. Usually it was due to additional set of skills, like strong algorithmic training or extra years of business domain expertise, and these traits bring additional value to organisations, if they are able to utilize them within their teams.

Especially when Java is not really a terrible choice in a large enough organization

It certainly isn't terrible, but it also is neither safer nor more productive. For a developer who has a good command of both paradigms, Scala would be a better choice on JVM.

grumpyprole3• 4 years ago

Sadly there’s very little evidence supporting productivity differences between programming languages, especially in bigger real-world contexts.

Only because it's almost impossible to quantify and is so contextual. However there is a good reason why Java is getting many extra language features from functional programming, e.g. streams, records, "sealed classes", pattern matching. Yes, productivity. Personally I am far more productive in OCaml, Haskell and Rust than Java; and that's after spending many years getting a lot of Java experience. But these are not necessarily good choices for the risk averse, which really comes down to the real reason why you chose Java.

kaba014• 4 years ago

Streams are not a language feature, they only depend on generics and lambdas. There are surprisingly expressive FP libs available for Java written with only existing tools (vavr for example).

Also, Java deliberately move slowly, it is a huge benefit for the platform as it can better avoid potentially vain features that would have to be maintained forever even if they are not popular. Algebraic datatypes debuted many many decades ago, yet they only become sort of mainstream in the last couple of years.

grumpyprole3• 4 years ago

Both lambdas and generics did not ship with Java originally. Yes Java moves slowly, but it would move even more slowly if they waited for published studies proving the productivity gains of these features.

fulafel• 4 years ago

Interesting that the choice was vs other JVM languages, and vs Scala specifically. The starting point to align tech choices with "realities of the hiring market" does make Java come out as the obvious choice then. But of course lots of companies hire developers for learning ability and the expecatation that they pick up the used language on the job, which also selects for other desireable qualities... no right or wrong answers here of course.

jonfromsf• 4 years ago

Is it true that Java isn't slower than Python/Ruby/.Net? What are the fast ORMs and MVC frameworks for it that let you build a web app quickly the way ROR / Django / whatever .net people use?

olavgg3• 4 years ago

Grails

mgl• 4 years ago

You may find this product interesting: https://stratoflow.com/

nazka• 4 years ago

I am starting to check this ecosystem but Spring Boot for the MVC framework is the ref. Used by so many big and small startup. I know a famous fintech using it too. Netflix etc also... Then JPA as the ORM and Hibernate. For the migration Flyway or liquidbase.

And then everything in Spring and stuff you can plug from the ecosystem.

kaba014• 4 years ago

Python and Ruby are probably the slowest commonly used languages, they are on the order of 10x slower than comparable C code. Comparatively Java/JS/.NET sits around 1-2x C speed, with .NET exposing some lower level details allowing manually fine tuning the performance, while Java has hands down the best GC implementations out of these 3. So one can’t objectively order them, for CRUD apps all 5 are great, and I think that there are very very few areas where C#/Java is not a good choice for performance reasons and you have to go lower level to C/C++/Rust.

marginalia_nu5• 4 years ago

While there are things I wish it did better for the sort of stuff I use it for (foreign memory API can't arrive fast enough), Java is a pretty solid pick.

It's boring and unsurprising to a fault, which is a great selling point if you want to build something of nontrivial size and scope.

Another strength is that it has a large well rounded standard library and a large set of mature libraries you can pull in when needs must. Not quite as batteries included as python, but not far off.

The tooling is best in class, the available IDEs are great, debuggers and profilers are ridiculously powerful even at face value, and that's not going into the iceberg of weird shit you can do, like you can attach a debugger to live production process like no big deal.

There are pitfalls when it comes to frameworks. Like both Spring and Spring Boot are quagmires that tank your performance. Like whatever velocity you gain from starting off with those is lost waiting 90 seconds for the planets to align every time you want to run your unit tests.

0xmarcin3• 4 years ago

Have you got a chance to read "Java Puzzlers: Traps, Pitfalls, and Corner Cases"? Java is a very surprising language with a lot of strange corner cases (a lot of them related to reified generics and wrapper types).

There is also a lot of magic going on in JVM e.g. there is one optimization that causes stack trace to be omitted if the exception is thrown from a given place a lot of times. Beginners then see an exception without a stack trace and are stuck. SO rel: https://stackoverflow.com/a/3010106/1779504

Spring can be a source of confusing problems when defining beans (especially when you have to use Qualifier's). Most of the juniors that I had a change to work with had very hard time getting used to Spring bean model. And I am not mentioning here strange Spring Proxy behaviour that can defy even programmers with 10+ years of exp

marginalia_nu5• 4 years ago

Yeah. Generics is arguably Java's weakest point. They're an afterthought in the language's design and should in general probably be avoided in all but the most trivial cases. A lot of problems go away if you stop trying to make Java into Haskell or C++ and just avoid the feature unless absolutely necessary, which you rarely do.

That said, I did once sorta port a somewhat tortured definition of Haskell's parser monads to Java's type system for an event at work, mostly as a joke. Like it's doable. Wouldn't want to maintain that code, but it's doable.

In general I don't think "does it confuse beginners" is a great metric for what makes a good programming language. You'll be able to find a beginner who is confused by almost anything. Beginners are hopefully not the same people who will write or maintain the code.

kaba014• 4 years ago

I have read that book, and while it is a great read, it rarely employs realistic code you would run into (will you really cast some number literal multiple times and try to guess the resulting value in actual prod code? And things like that)

I have yet to be bitten by this stack trace behavior, thanks for the heads up, but I think every platform has its idiosyncrasies. I would still not change it for UBs everywhere :D

And I really don’t think that the spring model is all that difficult, we just have plenty of bad developers and not enough focus on proper education of juniors (often done by “senior”, bad devs)

dingi• 4 years ago

Java seems to be getting a lot of flak. I would very much prefer to maintain a large Java code base over large JS, Python, Ruby code base hands down. Trust me, you don't want to be in a position to maintain a 100KLOC mess of an app written in JS by long goners.

0xmarcin3• 4 years ago

I don't like Java although I have to use it at my current job. There is simply no other alternative that is both widely known and supported (think a lot of programmers and a lot of libraries). I see only 2 other candidates C# & Go, switching to either of them means significant effort and temporary performance drop for the entire company.

Java is a very backward language, at my current job we use Lombok to generate boilerplate code. Lombok itself is a compiler hack, I don't like it. Why is that Java 17 records does not have supports for builders or for "withers" (point.withX(3)), C# & Scala offer both of those things. This makes records unusable for most of my use cases.

The other hard miss is lack of named parameters. This either makes code very verbose or less readable.

And my last complain is about lack of support around Futures/async/await. Yes there will be project loom, maybe even in next JVM release but currently we don't have it and a lot of libraries will need at least a year to support it. So instead of await's I have to manually compose CompletableFutures into spaghetti like code. I really hate this. We propose to our architect to use Project Reactor but the idea was discarded (after all Reactive Programming is not very popular among "commodity" programmers).

If I had to start a company now I would probably also pick Java (or Go), my main points would be: - Free compiler and IDE - Good library support for wide range of use cases - Programmers available on the market (Java) or willing to learn (Go) - Good build system, static analysis tools, best practices, learning materials & stack overflow - Language is battle tested (sorry Haskell, Ocaml & Lisp)

Yeah this reduces it to Java for JVM, C# for .NET, Go if you are adventurous. If someone pick something more ambitious like Scala 3 or Rust I would gladly join that company, but if it was my own I would not risk it.

ithrow• 4 years ago

I would add nodejs/Typescript as a mature option by now. Also, for web apps, using only one programming language sounds like a net positive for me.

jeremycarter2• 4 years ago

I'd argue that Java/C# with Typescript is still a reasonable mix to maintain, they're not entirely foreign.

mike_hearn4• 4 years ago

Most of your complaints are resolved by Kotlin, which can be mixed and matched with a Java codebase on a file level.

ghostwriter4• 4 years ago

Language is battle tested (sorry Haskell, Ocaml & Lisp)

do you mean battle-tested by yourself? Otherwise it's kind of FUD opinion, as Haskell is battle-tested across industries in quality-demanding domains[1], and I'm sure the other two have similar lists of industrial application.

[1] https://www.reddit.com/r/haskell/comments/6p2x0p/list_of_com...

hbrn7• 4 years ago

Author credentials: Java Champion

I mean, it's perfectly fine to pick language you're most familiar with, but maybe let's not pretend you're not biased? I wouldn't want to work for a leader that is full of BS.

SanderMak2• 4 years ago

Thanks, I guess? FYI, I joined Picnic in 2019, long after this choice had been (independently) made.

hbrn7• 4 years ago

I'm confused. You wrote an article about how somebody else chose Java, but you're using the term "we", but it doesn't include you?

The article unquestionably leaves the impression that you were there when the choice was made.

dandigangi3• 4 years ago

Couple jobs ago worked a startup that was a hoard of Java developers from Cars.com. Pretty much their defining factor around why they picked Java since it was the team they could build to get the company off the ground. Undervalued factor considering what teams you can build early on and the skills they possess.

exabrial• 4 years ago

Java17 is fast... _very_ fast. CDI is a the killer framework.

Why we picked Java

Related Stories