←back to thread

187 points chhum | 4 comments | | HN request time: 0.675s | source
Show context
nelup20 ◴[] No.44009800[source]
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).

It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.

replies(6): >>44009912 #>>44009928 #>>44009952 #>>44010109 #>>44010282 #>>44010468 #
sapiogram ◴[] No.44009912[source]
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
replies(3): >>44010013 #>>44010083 #>>44010285 #
overfeed ◴[] No.44010013[source]
The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity.

Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.

replies(3): >>44010172 #>>44010374 #>>44010391 #
1. whartung ◴[] No.44010374[source]
The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies.

Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful.

Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible."

So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.)

A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library).

Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work.

My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :).

Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.

replies(2): >>44010903 #>>44011419 #
2. wpollock ◴[] No.44010903[source]
You've made your point, but note the built-in HTTPS server only supports TLS 1.2, so don't use that for production code. (For testing it's probably fine.)
replies(1): >>44011244 #
3. whartung ◴[] No.44011244[source]
TLS is supplied by the underlying JDK, which has been 1.3 for some time. How is HttpsServer not 1.3?
4. password4321 ◴[] No.44011419[source]
You've made the project yours, nice! How many others work on it?

It's an uphill battle to convince my co-workers to do things my way.