The article is well worth a read in its entirety. I'm a millennial so it's all well before "my time" but wow.
Honestly - and this may sound weird - the biggest thing that struck me about this was that there were so many established respectable companies actually doing innovative stuff with operating systems and graphical environments. It feels like the gap back then between deep technical work and customers was so much smaller. Must've been an amazing time to be in the industry.
None of this would have happened in a 100% remote work setting. Don't get me wrong, I absolutely adore 100% remote work if you aren't doing anything important and you can't stand your team, and for those situations it is just plain human rights to enable 100% remote, but I do miss being part of a team and being in office with smart people.
Disclosure: I was working at First Person during this drama.
I had not seen Patrick's take on that fateful budget meeting before and it was interesting to read it. My recollection of the events are somewhat different.
As I recall, the business plan that was pitched suggested that the OS that was being targeted for widespread Java adoption was the Windows release code named "Chicago" (aka Windows 95). There was a widespread belief that Sun was in the process of "ceding" the workstation market to Microsoft as they couldn't afford to put Solaris on x86 without cannibalizing their own hardware business. At the time, Dave Rosenthal (a Sun Distinguished Engineer at the time) had circulated a paper that basically said, "Unless we change dramatically the desktop belongs to Windows NT." At the budget meeting (in February) Wayne put his pitch out there and Scott McNealy hit the roof (he really really disliked Microsoft). He wanted to fire whomever came up with that plan, and Wayne artfully stepped sideways and said it was all Patrick's idea[1].
The end result was that Wayne came back from that meeting, told the team that Sun was shutting down First Person at the end of the 1994 Fiscal year (June 30th, 1995) and that we should reach out to find other jobs within Sun or elsewhere because we wouldn't have our current job come July 1st. James negotiated with Sun Legal to release it "open source" so that when we were out job hunting we could point at something that others could look at to evaluate what we had been doing. They agreed and we did a really low key announcement of that in March just before the World Wide Web conference in Darmdstadt Germany. I had managed to get included in the small number of people going to that conference along with Mark Scott Johnson who was the manager at the time.
The San Jose Mercury news put our "low key" release announcement on the front page of the paper. That resulted in it being picked up by a lot of press outlets who talked to local engineers who gave it glowing reviews. When I showed up at the conference there was a small vendor exhibit area where Sun was going to be showing off the brand new SparcStation 20. The sales guys were in a PANIC because everyone was asking to see "Java" and "HotJava" and they didn't have any collateral to give them or demos. I spent a long night before the exhibits opened helping them download and install Java, and did probably four or five "training" sessions where I gave the sales guys enough to talk about.
Of course with that level of customer "impact" the thoughts of shutting down First Person became a memory and everyone back at HQ was maneuvering to have Java be part of their organization. It was hilarious when Bill Joy came out to congratulate us and tell us that now we knew Java was going to be successful we could put some world class people on it. I don't think he meant it the way it came out, or maybe he did, but either way it didn't have the impact he might have wanted.
Patrick had already left for Starwave at that point so he didn't get to see the shift internally. It was a pretty amazing thing though.
[1] Have I mentioned that the politics at Sun were pretty ruthless?
I discontinued using Java about 5 years ago after using it for what seems 20 years. Everyone was sold on Java for making beautiful, very well organized code bases that are VERY easy to understand, debug, and edit. And of course run-everywhere. I know a lot of people dispute that, but it's pretty much true with some various exceptions. Sun held it's promises. It's a damn beautiful language.
I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now. I know it's not as beautiful but it's definitely easy enough to read, easy enough to debug and edit. I don't want to make a new file for every, little, thing. I just want to process some data here and make a script there and handle problems, not code.
I feel teased by this comment in the fact that you didn't indicate which language (or languages) you moved to that give you those benefits?
Personally I moved from Java to Go, and couldn't be happier with it. Easy to use, easy to understand, similar advantages for debugging, but had some of the same proliferation of files at times.
I've injected a bit of python into my workflow too if I just want to do a quick data-oriented task.
I wouldn't call Java especially beautiful. When I learned about Java, I thought: "Hey, everything has its place! It is clear what kind of concepts to use. Interfaces, abstract classes, classes, enums ..." and I thought it was beautiful. This was however my own limited view on programming languages at the time. In hindsight, this system was quite stunted and held me back, by forcing everything into that shape. Later I learned other languages, which include language concepts for things, which I needed to write extra files and classes for in Java. One such example: Decorators.
Java has moved on nowadays, to include concepts, which other languages have had for decades, finally coming around to it. It did "modernize" a bit, one could say. Lambda expressions, namespaces, not having to put everything in a class (how silly that would be, to still have to do that). However, that doesn't make it beautiful, because those concepts are bolted on, for backwards compatibility reasons. It is not like there has been a redesign of the language or anything. It is going a similar way C++ is or has been going. Adding new syntax. It has to go that way, because there is no good extensible concept of Java syntax. Its syntax is always only a snapshot of the current state, that says "this is what is valid syntax right now", instead of offering a flexible way to extend the language.
I want to use languages, which have incorporated concepts, which traditionally Java did not even have or use alternative concepts, which make things possible and in this way shorten my code significantly. Then I don't have to write 10000 lines for simple things.
No language, however beautiful it may be, will solve a problem of overlooked use-cases, which cannot be solved using the concepts implemented in a library or program. For me beautiful code is code, which implements the simplest concept one can think of, in the simplest way, to make all intended use-cases possible. This is what I call flexibility. It is about implementing the least amount of limitations, not hard-coding assumptions, which are not justified, but all invariants, which are necessary. Not programming oneself into a corner.
> *I stopped using it because I stopped wanting to write 10000 lines for doing simple things. I want to write less code now.
Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines.
The syntax can be a little tricky at first, and without an auto-complete IDE it's still damn near impossible to figure out what the correct 1-3 lines should be unless you're really up to date on the streaming collections APIs.
The bottom line is, things are still improving with every release on the developer quality-of-life front. I've been pleasantly surprised! Caveat emptor, all languages have their ideal use-cases and tradeoffs. There is no holy grail (yet).
> ftware engineers around the world to join our team, there's never been a better time to join than now! The most I can reveal here is that our cloud service is very popular. AI / ML / automatic speech recognition / NLP / chatbots are our bread and butter.
> Java 11, with the introduction of lambdas, makes it trivial to express what used to require 10-15+ lines in 1-3 lines.
Makes this bit from the OP shine:
"Bill Joy ... was often comparing [Oak/Java] to more complicated and elegant languages like Python and Beta. He would often go on at length about how great [Oak/Java] would be if he could only add closures and continuations and parameterized types."
I'm sure they faced tradeoffs and Java's industry story is near unmatched so it's hard to argue they made categorically wrong tradeoffs, but imagine an alternate universe in which lambdas/closures and a few other features tamed verbosity and enabled python-comparable succinctness in Java back in the 90s.
IIRC Java had green threads and coroutines in its initial implementations. Imagine if they had kept them. People would probably complain they're unnecessary bloat.
Never got all the complaints about Java. It's a very versatile "good enough" language with a great ecosystem.
Thanks for the correction vips7L. The main idea I wanted to convey is that with every release, Java keeps evolving and improving in the expressiveness and usability departments.
Yes, between GraalVM and the other projects you mentioned, it's very exciting times on the technical engineering front at Oracle, especially for Java and the JVM.
Getting performance increases for free (as in, no code changes required) by swapping JRE implementation is pretty schweet.
Five years ago (depending on your company) you might not have even been using closures. Java has come a long ways since then, and lombok has eliminated most of the boilerplate. Modern Java can be pretty pleasant! Of course, there's a lot of crap code out there, but there's a lot of crap code everywhere.
Kotlin is nice, but setting up the build system can be a bit clunky, stack traces aren't quite as clear, it's more of a moving target, and important things like record classes are making it into Java. I tried it, but realized the code ended up being similar, just with less boilerplate, and switched back to Java. I feel like Scala went through a similar lifecycle. It looked amazing, supported lots of coding paradigms, but had a lousy build system. Once Java added lambdas, it was good enough, and Scala wasn't worth the hassle. Also, remember Groovy?
I'm sold on Kotlin and have been working professionally in it for a few years (mixed Kotlin/Java projects server-side), so take my opinion for what it's worth.
Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless.
I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know.
Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
Then I dare say you do not know the meaning of "convoluted build system".
Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own.
Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
Kind of, although C++ does have an advantage that others lack, it also shares the same symbiotic relationship with UNIX, by having been born on the same place as UNIX and C, by the same group of people of Bell Labs employees and initially started as C pre-processor.
Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
Personally I'm not sold on Kotlin. I don't think it offers much for me over Java 17. Maybe nullable types? But I haven't had problems with null in years.
I'm a long term java dev and just recently moved to Kotlin for some new core services. To be honest I just find them complementary. Kotlin breaks anything it likes and it's basically the pre-bleeding edge that java needs. Everything that java adds to the language and the JVM are rolled into Kotlin to make the runtimes faster/robust/stable.
It's just a syntactic sugar. E.g. allowing last functional parameter to be specified after the closing parentheses makes possible to create interesting structures that look more like config file than procedural code.
But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
It started out that way but in my eyes it has evolved to much more than just syntactic sugar.
While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX.
Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries.
Kotlin Flow is the answer for observability and rx-like reactive programming.
Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system.
I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.
I resent them for stealing the name of a beautiful island home to 145 million people. It’s so bad that even when you google Java while on Java island you get Oracle stuff first (in incognito).
I was hoping to read about an actual boat trip to Java but I knew that on HN I’m more likely to find programming stuff.
For people who are unaware of the place, I suggest googling photos of “Java nature”
I'm sorry about that. I might have been the one who originally suggested the name "Java" inspired by the cup of Peets coffee I had in my hand at the time.
To be fair it would have been Kim Polese and Patrick Naughton and James and Arthur Van Hoff who made the final decision on the name from the suggestions thrown out in that meeting. And furthermore Yahoo search was dominant then, maybe with AltaVista, and the idea of polluting the search space hadn't occurred to anyone.
Are you telling me I left a random comment about something that happened 25+ years ago and the relevant person saw it within two hours?
Mind blown :o
Anyway it made sense at the time, it’s just unfortunate. The only redeeming part is that in Indonesian it’s actually spelled Jawa so it doesn’t affect locals too much
I don't understand why people still use Java these days. It feels like Java has become Spring. (Mostly producing spring developers)
Alternative languages have branched off of the language and have succeeded with great buy in. (Clojure, Groovy [I think it's past it's heyday], Scala, Kotlin, etc]. However, java hasn't kept up. Yes, they copied a few nice things. However they're just surface level things. They're still encouraging people to write procedural code and worry about weird things that other frameworks take care of you. (Weird concurrency issues, DSLs, etc)
What I'm talking about:
- Pattern matching (this comes from scala) - They're slowly trying to give you something useful in a switch statement. It's no where near as expressive and extendable as what Scala gives you. (They went from int based, to string based, to some minor features for matching )
- Optional - this really hasn't been workable for those who are constructing functionality. It still feels like a procedural thing that is preventing you from writing if null, it doesn't avoid nesting in Java. In scala this is just apart of the flow of your code.
- Records- My understanding of the introduction of this is that it was a little different from POJOs and it broke external libraries. However, this is been a need since the days before Lombok. Additionally Groovy and Scala had this support.
- var.. ok nice you are now allowing for type inference.. but why not do var and val
A lot of these enhancements have been bandaids on the situation.. not full lets rethink some things and make them better
The only reason those alternate languages have buy in is because of the Java ecosystem, if Java fades aways those languages would likely fade away too.
You really think AWS is going to be offering Clojure SDKs?
Remains to be seem for Kotlin but the others haven't grow enough to develop a big ecosystem of their own.
If enough people are using Clojure and it's nicer than using the aws-java-sdk. yes.
Scala has a pretty big ecosystem. There are lots of new and exciting things being built there. (This is what used to be the experimental frameworks, libraries and creative projects that used to exist in java)
Honestly - and this may sound weird - the biggest thing that struck me about this was that there were so many established respectable companies actually doing innovative stuff with operating systems and graphical environments. It feels like the gap back then between deep technical work and customers was so much smaller. Must've been an amazing time to be in the industry.