Live data from Hacker News

Java at 30: Interview with James Gosling

thenewstack.io

211–220 of 437 posts

Re: Java at 30: Interview with James Gosling

#211
post #174
post #159

Earlier quoted context omitted.

Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.

I don't see Java being any better in this regard. Microsoft has been historically much less aggressive with lawyers compared to Oracle.

Java has a strong history of OpenSource, and a great set of libraries. It also pioneered the managed dependency system early (Maven), so these libraries have been centrally available for two decades.

Moreover, a lot of these libraries are well-supported to this day. For example, Hibernate (the best ORM in business) is 28 years old, and has just released a new version. I recently consulted my former client (from 15 years ago), and I still recognized most parts of the stack that I set up way back then.

Re: Java at 30: Interview with James Gosling

#212

Earlier quoted context omitted.

IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.

> they are heavily discouraged throughout Java code That's so ignorant. Read the article please.

Let's revisit past conversations:

- https://news.ycombinator.com/item?id=43226624

- https://news.ycombinator.com/item?id=43584056

- https://news.ycombinator.com/item?id=36736326

And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

Re: Java at 30: Interview with James Gosling

#213

I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw ou…

> My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA

You state how you don't really use java, but the above confirms it.

Java debugging and diagnostic tooling is second to none.

Re: Java at 30: Interview with James Gosling

#214
post #18

Earlier quoted context omitted.

> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff. The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages. You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case. The elephant in the room is of course ZGC, w…

> Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible. It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical. It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstract…

Zero-allocation (obviously different from zero GC) frameworks made a bit of a splash a little while back, but I'm not seeing much about them anymore from a brief search. I would have sworn that quarkus was one of them, but it looks like that's definitely not the case anymore.

The downside is that you sacrifice a lot of the benefits of guard rails of the language and tooling for what may not end up being much savings, depending on your workload.

Re: Java at 30: Interview with James Gosling

#215
post #7

Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby. Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine. Java memory management seems weird from a Unix Philosophy POV…

Java is not ahead of Go, they're on part but often Go is faster while using 2-10x less memory. Value type makes optimization much easier in Go.

The fact that you specifically mention Go explains a lot. btw c# is faster than Java, so not third place, it's more a 5th~

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Java at 30: Interview with James Gosling

#216

Earlier quoted context omitted.

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 mos…

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

TLS is supplied by the underlying JDK, which has been 1.3 for some time. How is HttpsServer not 1.3?

Re: Java at 30: Interview with James Gosling

#217
post #213

I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw ou…

> My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA You state how you don't really use java, but the above confirms it. Java debugging and diagnostic tooling is second to none.

That's a really narrow view of the world, and I think another Javaism to think that Java is the entire world. Today's multi-service deployments run tens if not hundreds of auxiliary processes not using Java. They use network overlays that change how processes interact with the network core. A person who is debugging a knock on effect issues has to be able to look through many different layers of processes, many of which are written in C, C++, Go, etc. Having to learn an entire toolset to debug Python or Java is a huge burden and it makes introspection extremely difficult. Java essentially wants to be the entire platform, which isn't how the world works anymore.

Re: Java at 30: Interview with James Gosling

#218

I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw ou…

IT factor! Am I on a fashion website now? What kind of argument is that? Also, why on earth would you use strace or gdb for Java? It has enormously performant debugging tools in the JDK. Also, IDE debugging integration is second to none.

Because if I'm debugging a critical issues and wading through multiple layers of processes and system interactions, I don't want to have to learn a bespoke toolkit and debugging system for every single process.

Re: Java at 30: Interview with James Gosling

#219

Just going to remind y'all of this: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java... I went to a Java school. I remember my operating systems class involved writing simulated OS code in Java (for example, round robin for context switching). The argument was that it would be easier to understand the algorithms if the hardware complexities were minimized. I understand that sentiment, but I don't think Ja…

A lot of the arguments Joel makes in that article also apply to Python, and pretty much any other higher-level language that doesn't make you think about pointers. Ironically, he points out the Google had a great leap over Microsoft with MapReduce, which was built in Java.

The original version of MapReduce was written in C++. The successor library, Flume, was however written in Java, but Spolsky would certainly have been referring to the original MapReduce, since the Flume paper wasn't published until 2010.

Re: Java at 30: Interview with James Gosling

#220

I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw ou…

In my 20+ years using java, not once have I used strace or gdb. Java itself has fantastic debugger support, and IDEs have built in step through capabilities. Mentioning Java and Python in the same way in the context of performance is really odd. Python is nowhere near the JVM when it comes to performance

It sounds like you've only ever written code without dealing with it in production. You can't always plug your code into an IDE when your debugging someone else's JVM app on a remote server.
Post reply on HN