By "lurking" people mean that the executives who care nothing about open source are firmly in control, and some day may try to assert their control in ways that nobody else likes.

You may not remember incidents like why Jenkins was forked from Hudson, but Oracle is run by people driven by what they think they can get away with, and not by what is good for the projects that they have power over.

> the executives who care nothing about open source are firmly in control, and some day may try to assert their control in ways that nobody else likes.

I have no idea what Oracle may do tomorrow, but Oracle has been in control of Java for a decade, and what it has actually done is 1. significantly increase the investment in the platform and 2. open source the entire JDK. So I don't know about the next ten years, but the past ten years have been really good for Java (well, at least on the server).

> Oracle is run by people driven by what they think they can get away with, and not by what is good for the projects that they have power over.

I don't share your romantic views of multinational corporations. Corporations are not our friends, and while they're made of people, they're not themselves people, despite what some courts may have ruled. But like people, different corporations have different styles, and it would be extremely hard to call any of them "good." I have certainly never heard of one is driven by caring (although what you do when you don't care may differ; some may be aggressive with licensing, some are in the business of mass surveillance, some help subvert democracy, others drive entire industries out of business through centralizations and others still drive kids to conspiracy theories). When you look at what Oracle has actually done so far for Java, I think it has been a better, and more trustworthy steward than Microsoft and Google have been for their own projects (Java's technical leadership at Oracle is made up of the same people who led it at Sun). And people who bet on Java ten years ago are happier now than those who bet on alternatives (well, at least on the server). This despite some decisions that made some people unhappy. You can like the good stuff and be disappointed about the bad stuff without some emotional attraction or rejection to these conglomerate monsters.

Your opinion is your opinion.

My opinion of the company and its products is more consistently negative than any other large company. And while you think that the non-Java world is suffering, I think you have some tunnel vision.

Let's just say that I am personally happy with my decision to stay away from Java. And the brief periods where I had to work with Java were misery. Languages have personalities as well as companies, and there is a reason that the startup world stays away from Java in droves.

> and there is a reason that the startup world stays away from Java in droves.

You may have your own case of tunnel vision. I mean, sure, there are "droves" of startups that stay away from Java (many only to turn to it later), but there are also "droves" that adopt it from the get-go.

Why don't we look for some concrete information?

According to the statistics reported by https://www.codingvc.com/which-technologies-do-startups-use-..., Java looks like the fourth most commonly used language in the startup world, and its usage is not particularly well correlated with success.

Both Ruby and Python are more popular than Java, AND are better correlated with how good the company is. Your odds of being in a successful startup are improved if you are in those languages INSTEAD OF Java.

What about from the individual programmer level? Triplebyte did an article about how programming language and hiring statistics correlate. My impression is that their programmers are mostly being hired into relatively good startups, so it is a pretty good view of the startup world. That article is at https://triplebyte.com/blog/technical-interview-performance-....

Long story short, Java was the #2 language that programmers chose. Behind Python. Not so bad. But choosing Java REDUCED your odds by 23% of actually getting to a job interview. And for those got to a job interview, it reduced your odds by 31% of actually getting hired. By contrast Python IMPROVED those same odds by 11% and 18% respectively.

Apparently the startup world doesn't like Java developers either. You'd be far better off with Python.

Now I'm sure that you can trot out every successful Java startup out there. And there will be quite a few. But based on available data, not opinions, I did NOT express tunnel vision when I said that the startup world stays away from Java in droves.

If you truly believe any of the conclusions you've drawn from the numbers in the links you posted, then your favorite programming language REDUCES statistics skills.

Startups don't use Java because Java is for large-scale stable long- lived enterprises, not for prototyping simple small web apps that might be thrown away in a couple of years.

You often hear this, but what does it actually mean? Why is Java for one but not the other.

Here is my understanding.

Java was designed to limit the damage that any developer could accidentally do, rather than maximize the potential for productivity. Which is an appropriate tradeoff for a large team.

It is hard to get good statistics on this, but the figures that I've seen in books like Software Estimation suggest that the productivity difference is around a factor of two.

This matters because it turns out that teams of more than 8 people have to be carefully structured based on the requirements of communication overhead. (A point usually attributed to The Mythical Man-Month.) This reduces individual productivity. Smaller teams can ignore this problem. The result is that measured productivity for teams of size 5-8 is about the same as a team of 20. But the throughput of large teams grows almost linearly after that. An army does accomplish more, but far less per person.

Limiting damage matters more for large teams. Which are more likely to be affordable for large enterprises. However being in such an environment guarantees bureaucracy, politics, and everything negative that goes with that.

By contrast startups can't afford to have such large teams. Therefore they are better off maximizing individual productivity so that they can get the most out of a small team. And using a scripting language is one way to do that.

Today, I go back and forth between three languages at work - .Net, JavaScript, and Python. For simple prototype web apps or more realistically REST microservic APIs to feed front end frameworks, I really don’t see either being slower to develop.

For larger applications with multiple developers working in the same code base, the compile time checking of static languages is a god send. I would at least move over to TypeScript instead of plain JavaScript.

Oracle has a long track record of Sales & Marketing tactics which we can use as a reliable benchmark to predict outcomes.

Oracle will likely pursue the most aggressive strategy they can get away with Java.

I don't believe Sun was suing Google, but Oracle did.

The fact that Google is switching to Kotlin is mostly a means to absolve themselves of the 'Oracle risk' - it's a big change surely, a decision not taken lightly.

The future of Java under Oracle is hard to predict but there's legit concerns Oracle will make things hard.

Kotlin uses the same VM and API, so it makes no difference in this regard. It's not a big change – it's fully interoperable with Java. You can easily take a single class in a Java application and rewrite it in Kotlin, and everything continues working just as before.

Google adopted it because, as they more or less said in the announcement, it was already being adopted by the community and it hugely improved development experience.

but you splitting your developer base. * There will be people better at kotlin * There will be people better at java.

This is a problem when you are looking at hiring new people etc . This fragmentation is going cause issues just because people are hedging against Oracle future decisions.

In a perfect world Google should have bought Sun and the current version of Java would look at lot like Kotlin.

Kotlin is a light syntax for a coding style. It's as easy for a Java dev to learn Kotlin as it is to learn Spring or Hibernate or whatever library or framework the team at your new job uses

It's a whole other domain of things to learn, and now we're stuck with context switching all of the time.

Even if Kotline were 'better' (And I don't think it is), it'd have to be quite a jump better.

It's a little nicer for getting ideas down quickly, but beyond that to me it's just 'different' and now a whole other bag of things to support.

If I have to chose between Kotlin+Java or just Java I'll take just Java.

Going back to Java from Kotlin there's really nothing I miss.

I think Sun might have wanted to sue Google?

https://news.ycombinator.com/item?id=10951407

Yes, thanks for that, it stirred my recollection as I actually bumped into Jon Swartz by accident just in that era.

I don't think it was money, so much as the established culture at Sun (i.e. James Gosling: "Sun is not so much a company but a debating society). A more aggressive CEO/leadership/culture would have maybe raised the money to take on Google, or to take another tact.

So while you are right - and thanks for the reference - the issue here is what Sun was about, vs. what Oracle is about.

Whatever Sun was "about", sadly, it didn't work, and damaged some excellent technologies, like Java and Solaris, that Sun couldn't invest a lot of resources into because it no longer had them. Oracle managed to save one of them and make it thrive. Sun, as a big, impactful company, was a product of the dot-com bubble. It certainly made more lasting contributions than other bubble-era companies, but its strategy couldn't survive the crash. Maybe great ideas can be born in companies like Sun but need companies like Oracle to sustain.

I've been saying for years that Pivotal Labs is a debating club that produces code as a by-product. But now I'm wondering if I read the Gosling quip and then forgot I had.

Google made $billions from Java while Sun went near bankrupt, and is now a top-10 wealthiest company in USA. Oracle trying to get $ from Google in partnership with the former Sun is a different issue from your company's risk.

I do understand Oracle is paying the bill. As well as the team working on Graal and TruffleRuby. so I am grateful for that. Thank You.

>What do you mean by "lurking"?

Referring to Copywriting API a while ago and the JakartaEE problem which has blown up on my twitter feeds. I understand why Oracle is trying to charge money, and I am perfectly fine with that, I just don't like they are using Copywriting API as the tool. And whatever problem it is with JakartaEE this time around I don't have time to follow.

In a lawsuit, Oracle pushed for API's to be copywritten, not just their implementation. They also have paid lobbyists. They're also greedy assholes. The combo of greedy assholes and the ability to rewrite the law is a dangerous one.

So, I don't use a language unless it's open with patent grants and has a non-malicious owner. At this point, Wirth's stuff is probably legally the safest.

I'm curious about the last part. Are you using Modula 2 or something?

I don't have any public projects to release right now. So, I don't have to worry about getting sued. Modula 2 was nice but you could use any of Wirth's with low risk. Although Lisp's had lots of companies involved, Scheme is probably safe with PreScheme aiming for low-level use. A Racket dialect with C/C++ features like ZL language had could be extremely powerful and safe.

Rust, with Mozilla backing it, is probably not going to get you sued. Nim has potential given their commercial interests are paid development and support so far. As in, less greedy they are the better. Languages with community-focused foundations, such as Python, controlling them are probably pretty safe. Although it was risky, the D language now has a foundation. Although no foundation or legal protections, the Myrddin and Zig languages are being run by folks that look helpful rather than predatory.

So, there's you a few examples you might consider if avoiding dependencies on companies likely to pull shit in the future. Venture-backed, publicly-traded, growth-at-all-costs, and/or profit-maximizing-at-all-costs are examples of what to avoid if wanting to future-proof against evil managers turning it from good dependency into bad one.

> copywritten

copyrighted

"Copywritten" probably means nothing, but if it did, it would have something to with copy writing, the act of writing for publication (usually commercial, usually not long-form).

Added: FYI "copyrighting" is not a conscious decision, or an action you can take. Copyright emerges automatically when you create a work, what they've done is defend their copyright in court, and the courts have mixed opinions on the matter.

That is a gross mischaracterization of what Oracle did. They didn't just defend a copyright in court. They pushed to extend copyright to a mostly functional element that copyright law has not traditionally been thought to cover. It's a tremendously harmful viewpoint for interoperability.

Not just "not traditionally been thought to cover", but which existing precedent said DID NOT cover.

Does it surprise anyone that this case was decided by the Federal Circuit? The rogue court most consistently overturned by the Supreme Court, which also is responsible for most of the disastrous software patent cases out there.

The only bright light is that the Supreme Court has reopened the question. Given how often they overturn the Federal Circuit, we have real hope that we'll return to the previous precedent. Which is that since matching APIs is a functional part of how code works, and things that are functional are by law not copyrightable, APIs are not copyrightable.

Yes, copywritten isn't a word, but their point was that Oracle pushed for API's to be copywritable, which was not the case before their suit. It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time.

Not to belabor the point, but... "copyrightable".

> It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time.

I mean, it has been big news, and it has already been nuclear war, with Oracle putting Google in a position to switch android from Dalvik (and successors) to OpenJDK. I agree that it could become a pretty horrible precedent (imagine if Microsoft forbade Sun from implementing Excel functions in StarOffice, or for that matter, if MS were prevented from producing Excel in the first place).

> imagine if Microsoft forbade Sun from implementing Excel functions in StarOffice, or for that matter, if MS were prevented from producing Excel in the first place

The things you're talking about are already protected by patents, and the copyrightability of APIs have nothing to do with them. At the very least, for something to be copyrightable it must be some specific fixed expression (a piece of text, image, video or audio). So the O v. G ruling applies only to actual (code) APIs; not to protocols (or REST "APIs") and certainly not to stuff that's already protected by patents (the distinction between the two may not always make sense to programmers, but it is what it is; for example, algorithms are patentable but not copyrightable, while programs are copyrightable but not patentable).

You should do some reasearch on the Oracle vs Google case.

It's literally no different. Excell has APIs just like Java, it's just the code goes in cells rather than on lines.

The licensing has gotten super onerous.

The licensing has gotten far better. First, Oracle has just open sourced the entire JDK for the first time ever, and second, instead of offering a mixed free/paid, open/proprietary JDK (with -XX:+UnlockCommercialFeatures flags), it now offers the JDK under either a completely free and open license (under the name OpenJDK) or a commercial license for Oracle support subscription customers (under the name Oracle JDK).

Thanks, that clear things up bit.

What licensing? OpenJDK is licensed under GPLv2 plus Classpath exception, the same as ever.