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

341–350 of 437 posts

Re: Java at 30: Interview with James Gosling

#341

Post by lycopodiopsida »

bitwize wrote: post #337
lycopodiopsida wrote: post #321

Earlier quoted context omitted.

> Apparently many people need the stories, given how much they boost Go about things that are prior art. No one but you here cares about prior art. And not even you, most likely, otherwise you would write your in some kind of lisp which was first on most of the things. > Emacs could be an IDE, if it came with the whole Lisp Machine for the ride, sadly it is only a subset of the whole experience. Lisp is just an imple…

Emacs has no "plugins", it's all just Lisp code, all the way down. Big Ball of Mud architecture refined to a state of sublime elegance. Can I put my cursor on a defun in Visual Studio Code, Eclipse, or IntelliJ, mash C-M-x, and immediately have that functionality available in my running editor session with all my work? I can in Emacs, and that capability has allowed me to smooth out the rough spots in many a workflow…

No need to convert me there, I am already in the church.

For programming purposes emacs is not that different from any modern editor - there are some built-in capabilities, the rest you get from ELPA/MELPA/Git. It has no proper plugin arhitecture, which is a gift and a curse at the same time, but mostly works out. Where emacs shines compared to vscode/neovim/etc is that it has a very solid support for prose, org-mode, denote and prots color schemes which are that good. It is why I continue to use it, even though I am not interested in lisp per se these days and could easily replace it for programming with any other advanced editor.

Re: Java at 30: Interview with James Gosling

#342

Post by icedchai »

jbverschoor wrote: post #312
zmmmmm wrote: post #240

Earlier quoted context omitted.

The worst thing about EntityBeans is they were so bad they made Hibernate look good, which led people to think it was good. After 10 years of hammering against ORM complexity I finally switched to using thin database wrapper layers and have not once ever regretted it.

I you just wanted queries, entity beans were ok. Just a lot of boilerplate code, but the overal architecture and structure of JEE is still very sound

A lot of boilerplate and XML hell!

What did you like about JEE? I worked in that world for years and don't miss it in the least.

Re: Java at 30: Interview with James Gosling

#343

Post by zdragnar »

znpy wrote: post #328
zdragnar wrote: post #214

Earlier quoted context omitted.

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

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

Re: Java at 30: Interview with James Gosling

#344

Post by surajrmal »

fidotron wrote: post #128
eikenberry wrote: post #98

Earlier quoted context omitted.

It's a core principle. Don't communicate by sharing memory; share memory by communicating. The overuse of Mutex and Lock are from developers bringing along patterns from other language where they are used to communicating via shared memory. So this aspect of the language just doesn't click as well for many people at first. How long it takes you to get it depends on your experience.

My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization. But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.

Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Google internally recommends not using them in many situations.

Unbuffered IO is a tradeoff. For certain use cases it does help, because throughput isn't everything. I'm sure Buffered is better in the average use case, but that doesn't mean you would never need unbuffered.

Re: Java at 30: Interview with James Gosling

#345

Post by surajrmal »

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

Note that the mpsc queue in the rust stdlib is also a clone of crossbeam and therefore also lockless.

Re: Java at 30: Interview with James Gosling

#346

Post by Kwpolska »

breadwinner wrote: post #336
Kwpolska wrote: post #292

Earlier quoted context omitted.

None of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.

What about the ones you can recover from? You don't want to crash the entire application every time there's an exception!

You usually wouldn’t crash the entire application, the request that causes the issue will return a 500 error. (Or equivalents for non-web environments.)

Re: Java at 30: Interview with James Gosling

#347

Post by zabzonk »

Pet_Ant wrote: post #260
zabzonk wrote: post #258

Earlier quoted context omitted.

> You can literally write code that will compile in both. An example, please.

int fibonacci(int n) { if (n } ...if only the return type was "Crow" then you could .eat() that...

That will not compile with javac, as it is not a method of a class.

Re: Java at 30: Interview with James Gosling

#348

Post by hintymad »

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…

Yeah, even with channels and goroutines, I’d imagine we can encapsulate them as primitives in containers like concurrency literatures often advocate. Case in point, it was fun to go through Pike’s talk Go Concurrency Patterns, yet I’m not sure all the patterns he discussed in the talk would be that simple to implement compared to just declaratively using well-packed containers

Re: Java at 30: Interview with James Gosling

#349

Post by timbit42 »

jbellis wrote: post #30
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…

more like 100x faster than Python/Ruby and that's before you throw in real multithreading

I have heard around 50x, which is about the same as between assembly and BASIC on 8-bit systems.

Re: Java at 30: Interview with James Gosling

#350

Post by fidotron »

surajrmal wrote: post #344
fidotron wrote: post #128

Earlier quoted context omitted.

My experience is a shocking amount of the golang community believe channels are a performance problem for whatever they're doing, and they use mutexes in some misguided effort at optimization. But then I have also encountered Rust people that will look down on Java but had no idea buffered I/O had higher throughput than unbuffered.

Depending on the situation, channels can absolutely be higher overhead and not worthwhile. Google internally recommends not using them in many situations. Unbuffered IO is a tradeoff. For certain use cases it does help, because throughput isn't everything. I'm sure Buffered is better in the average use case, but that doesn't mean you would never need unbuffered.

> Depending on the situation, channels can absolutely be higher overhead and not worthwhile.

Like streaming arrays one byte at a time through the channel.

Such devs just aren't very good, and hear "Google internally recommends not using them in many situations" but jump to inferring that means all of their situations qualify.

> but that doesn't mean you would never need unbuffered.

Note that this was never claimed.

Post reply on HN