Live data from Hacker News

Java at 30: Interview with James Gosling

thenewstack.io

311–320 of 437 posts

Re: Java at 30: Interview with James Gosling

#311
post #307

Earlier quoted context omitted.

I don’t care about opinions on Go the language, but the tooling around is excellent without being bound to an IDE. And no matter what you use: Goland, VSCode or dape in Emacs, your debugger will plug in the same delve. > the large majority is on VSCode Here, fixed it for ya. But since when is VSCode an IDE? It is just an extensible editor, not very far from Emacs or neovim. We’ll see how it plays out, but I assume th…

You mean tooling as it was already kind of available on Turbo Pascal for MS-DOS? When people discuss Go tooling feels like Renaissance folks resdicovering Roman city enginnering. VSCode is certainly an Integrated Development Editor, and it is such a dead concept that one of the key Visual Age and Eclipse linage of IDEs is the one behind it, Erich Gamma. Biggest difference is that one hardly needs to code extensions,…

> You mean tooling as it was already kind of available on Turbo Pascal for MS-DOS?

Spare me your stories of the TurboPascal, I am not a youngster, not easily impressed by name-dropping $some_old_thing and do not care about old men yelling at clouds. You may program in TurboPascal, if you like it.

> When people discuss Go tooling feels like Renaissance folks resdicovering Roman city enginnering.

People talk about Go tooling because it is good, lightweight, editor-agnostic, helpful and provided with the language. There are multiple language which fulfil some of the criteria, but not many fulfilling all of them.

> VSCode is certainly an Integrated Development Editor

If VSCode is an IDE, then also emacs and neovim and your lamenting has no meaning. And of course, the one behind VSCode is Atom which was heavily influenced by Sublime text.

> Biggest difference is that one hardly needs to code extensions, or manually configure them most of the time, a simple install button press is only that is needed to get any extension going, many of which graphical, taking all advantage of the Web platform.

So, basically a neovim distribution? Got it!

Re: Java at 30: Interview with James Gosling

#312
post #240

Earlier quoted context omitted.

Entity Beans were terrible, representing the height of JEE over complexity. I remember editing at least 3 classes, a couple interfaces, and some horrific XML deployment descriptors to represent an "entity." A lot of the tooling was proprietary to the specific app server. On top of that, it was slow. In the early 2000's, I used to work on JEE stuff for my day job, then go home and build PHP-based web apps. PHP was at…

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

Re: Java at 30: Interview with James Gosling

#313

I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong. For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealin…

[flagged]

HN only works because people are generally respectful and assume good faith. Your post is rather the opposite. I hope that you'll maybe reflect on that.

Re: Java at 30: Interview with James Gosling

#314

Earlier quoted context omitted.

Oh yeah. I still don’t understand why we even moved away from the original JEE model, including the different roles (app dev, deployed, etc). The whole spec was great with the exception of entitybeans. It provided things that are still not available it anything else.. why do we store configuration/credentials in git (encrypted, but still). And the context were easy to configure/enter. Caucho’s resin, highly underrate…

resin was okay but I never got what it offered over tomcat

Full JEE, not just servlets, performance, reloading, and a bunch of enterprise features. Resin existed.

After about 10+ years Spring kind of took over JEE.

Omg. Spring was just like moving code to xml. Different now, but still.

What I miss from JEE:

- single file ear/war deployment, today that’s a docker image

- the whole resource api from Java (filesystem/jar doesn’t matter). It means you don’t necessarily have to unpack the jar

- configuration / contexts for settings, + UI for it, database connections etc. Docker kind of works, most most images fail to achieve this. Docker compose kind of takes care of things.

- as said before.. all Java still runs everywhere

Re: Java at 30: Interview with James Gosling

#315

Earlier quoted context omitted.

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…

That is an excellent point too. It always made me wonder why I hear about companies who are running very old versions of Java though. It always seemed like backwards compatibility would make keeping up to date with the latest an almost automatic thing.

It is "mostly" backwards compatible. Applets and everything related to them where dropped. A few interface dependencies where changed to improve modularity of the runtime. Widely used hacks like sun.misc.unsafe are getting replaced with official APIs and locked down. Development of some Java EE packages has been taken over by a third party, so they are no longer packaged within the java namespace. To name just a few of the bigger examples.

Re: Java at 30: Interview with James Gosling

#316
post #310

Earlier quoted context omitted.

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

And yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones. A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.

> And yet many of us embraced Java,

That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.

Re: Java at 30: Interview with James Gosling

#317

Earlier quoted context omitted.

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…

> I'm not sure what you found in (checked) exceptions. I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex... Summary: Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library. More crashy code: If a method starts throwing a new exception, you might not reali…

> You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

Always assume exceptions will be thrown from a method or library.

Re: Java at 30: Interview with James Gosling

#318
post #310

Earlier quoted context omitted.

And yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones. A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.

> And yet many of us embraced Java, That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.

Also as much as I complain about the lack of JIT tooling in CPython, many people forget that usually most people don't have any issues in polyglot codebases, it isn't a zero-sum game, and various forms of FFI and language bindings exist.

That is one of the things I have been doing across JVM/ART, CLR, V8 for decades now, moreso if we include Perl and Tcl into the mix, I seldom write full blown 100% C or C++ code, when I reach to them, is to write native libraries or implement language bindings.

Re: Java at 30: Interview with James Gosling

#319
post #307

Earlier quoted context omitted.

You mean tooling as it was already kind of available on Turbo Pascal for MS-DOS? When people discuss Go tooling feels like Renaissance folks resdicovering Roman city enginnering. VSCode is certainly an Integrated Development Editor, and it is such a dead concept that one of the key Visual Age and Eclipse linage of IDEs is the one behind it, Erich Gamma. Biggest difference is that one hardly needs to code extensions,…

> You mean tooling as it was already kind of available on Turbo Pascal for MS-DOS? Spare me your stories of the TurboPascal, I am not a youngster, not easily impressed by name-dropping $some_old_thing and do not care about old men yelling at clouds. You may program in TurboPascal, if you like it. > When people discuss Go tooling feels like Renaissance folks resdicovering Roman city enginnering. People talk about Go t…

Apparently many people need the stories, given how much they boost Go about things that are prior art.

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.

VSCode has zero lines of Atom code into it, it started from Azure as Monaco project.

Does neovim distribution handle graphical development plugins, without spawing external windows?

Yeah, right.

Re: Java at 30: Interview with James Gosling

#320
post #299

Earlier quoted context omitted.

Is it really so? I haven't checked all the implementations, but my take here would be to use a channel with atomics instead of a lock...

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

Post reply on HN