Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java at 30: Interview with James Gosling

thenewstack.io

Post reply on HN
Print view View original

381–390 of 437 posts

Re: Java at 30: Interview with James Gosling

#381

Post by neonsunset »

LtWorf wrote: post #272
FromTheSteppe wrote: post #265

Earlier quoted context omitted.

Well to be fair, if you wanted Performance, Linux support, and a framework which was built with dependency injection and async support in mind and not just have them as patched in footguns, you had to migrate to .NET Core. A Java 8 Spring app was just good enough.

If you want linux support, .net is not what you want. Linux support is an afterthought and it shows. And you never know if it might be dropped next year.

We've had this conversation before, it's likely a waste to reply but, well, my mistake.

For those interested as to why: https://news.ycombinator.com/item?id=43396171

A few more arguments while we're at it:

https://dotnet.microsoft.com/en-us/platform/telemetry (Linux leads with 77% of all systems invoking .NET CLI commands)

https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... (first-class epoll/kqueue integration with async, much like the one Go has with goroutines via netpoll)

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/u... (GC implementation is cgroups-aware, unlike Go)

Re: Java at 30: Interview with James Gosling

#382

Post by neonsunset »

mrcsharp wrote: post #356
LtWorf wrote: post #297

Earlier quoted context omitted.

3 seconds of looking at the API and you see it's not 1st class at all. Presuming you have ever done any programming on linux, that is.

> The API Which one?

Don't bother: https://news.ycombinator.com/item?id=43396171

These people could not care less about engaging with the subject, they are here because they feel obliged to engage in a moment of hatred of what they think is an enemy tribe.

Re: Java at 30: Interview with James Gosling

#383

Post by exabrial »

marginalia_nu wrote: post #162
exabrial wrote: post #92

Earlier quoted context omitted.

>My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA Java has one the greatest debugging capabilities ever. dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a deb…

> what legacy code? The Java API has its fair deal of baggage due to its extreme backward compatibility. Boolean.getBoolean[1] is one of the more accessible examples of a bad API that exists only because of legacy reasons, but there quite a number of them. [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Boolean....

Ow.

Re: Java at 30: Interview with James Gosling

#384

Post by mrcsharp »

neonsunset wrote: post #382
mrcsharp wrote: post #356

Earlier quoted context omitted.

> The API Which one?

Don't bother: https://news.ycombinator.com/item?id=43396171 These people could not care less about engaging with the subject, they are here because they feel obliged to engage in a moment of hatred of what they think is an enemy tribe.

Wow what a thread!

Re: Java at 30: Interview with James Gosling

#385

Post by znpy »

zdragnar wrote: post #343
znpy wrote: post #328

Earlier quoted context omitted.

> 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. I think that's mostly done in organisation where there's time, budget and willingness to optimize as far as possible. Sacrificing the guardrails doesn't make sense for the "general public" software but does tremendous sense in environment where l…

Is data access in such a project purely from in-memory sources? I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed.

> Is data access in such a project purely from in-memory sources?

yes.

> I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed.

Database access, if you're talking network latency query/transaction processing time, is essentially irrespective of the language being used, so that's not a good reason to shun Java as a language/rutime anyway.

Re: Java at 30: Interview with James Gosling

#386

Post by saagarjha »

pimeys wrote: post #320
saagarjha wrote: post #306

Earlier quoted context omitted.

It's probably possible to do if you think about it carefully but generally enqueuing a message is going to take a lock, especially if you can send an arbitrary number of messages (which may require the queue to be reallocated).

One very common queue implementation you can use to implement actors is the crossbeam-deque. It's work-stealing in nature, works in multi-threaded environments and has no locks. The implementation is quite simple to follow: https://github.com/crossbeam-rs/crossbeam/blob/master/crossb...

Oh, interesting. Ok I take back my claim then.

Re: Java at 30: Interview with James Gosling

#387

Post by int_19h »

shanemhansen wrote: post #236
hintymad wrote: post #79

Earlier quoted context omitted.

> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on w…

I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map. In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization. In general I think channels are great for connecting a few large…

Not just generics, but also a way to generalize iteration (i.e. the equivalent of Java iterators). Which Go has only got even more recently than generics.

Re: Java at 30: Interview with James Gosling

#388

Post by int_19h »

cogman10 wrote: post #27
brightball wrote: post #25

Earlier quoted context omitted.

When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier. Java the language eventually drove me away because the productivity was so…

Let me extol the virtues of Java the language. You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this…

The counter-example to this is C#. Barely younger than Java (by 5 years), and starting its life as mostly a Java clone with a sprinkle of Delphi, it evolved much faster and made many changes which "make things look better" without breaking things. Source-level compatibility goes pretty much all the way back to 1.0, as well.

Re: Java at 30: Interview with James Gosling

#389

Post by int_19h »

jbverschoor wrote: post #365
icedchai wrote: post #247

Earlier quoted context omitted.

Yes! Hibernate was awful, but still light years ahead of EJBs. I worked on a couple of Hibernate projects and always left asking why...

I never had any trouble with Hibernate tbh. It allowed you to drop back to raw sql if needed, and also custom fields to select if needed. I never understood the fight against ORMs. In the end you'll simply be writing your own framework

Only if you insist on a nearly 1:1 mapping between your data and your class hierarchy.

Re: Java at 30: Interview with James Gosling

#390

Post by int_19h »

lelanthran wrote: post #56
exabrial wrote: 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 performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. When Java got popular, around 1999-2001, it was not a close third behind C (or C++). At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.

I don't think that's accurate. Java at the time you're describing was already JIT-compiled (HotSpot debuted in 1999), which made it drastically faster than any plain bytecode interpreter. OTOH Python was - and remains - notoriously slow because, despite being compiled to bytecode, said bytecode is extremely high level and many opcodes in it represent potential numerous dict lookups etc.
Post reply on HN