Who pissed in your Java this morning, gramps? Performance has nothing to do with whether you’re “the programmer” (whatever that means, I assume that’s what you consider yourself among this sea of mediocrity around you) and “React dev”. It’s all about incentives, and truth is that performance isn’t very high priority for majority of software.
There are very, very strong incentives for performance. Google and other hyperscalers have done studies on their data at scale (and boy do they have a lot of data), and even delays measured in hundreds of milliseconds harm user retention. On the backend side, 1% improvements in performance can translate to millions of dollars in reduced costs at scale annually. There simply are not enough qualified programmers in the world to create performant software.
With open source it's not even about incentives. I still put effort into the software I make on my own time because I create the kind of software I want to see in the world, ie. software that doesn't feel miserable to use. It's simply about culture. People build up assembly and lower-level abstractions in general to be the scary monster in their closet, and not something they could actually learn if they just tried.
I’ll be happy if over night all Python code in the world can reap 10-100x performance benefits without changing much of a codebase, you can continue having soup of multiple languages.
Me too, but changing the referential semantics would be a massive breaking change. That doesn't qualify as "without changing much of a codebade". And tacking on a giant new orthogonal type system to avoid breaking existing code would be akin to creating a new language. Why bother when you can just write Python modules in Rust.
Still makes no sense. OP demands introduction of different runtime semantics, but this doesn't require adding more language constructs (TS-like superset). Current type hints provide all necessary info on the language level, and it is a matter of implementation to use them or not.
From all posts it looks like what OP wants is a different language that looks somewhat like Python syntax-wise, so calling for "backwards-compatible" superset is pointless, because stuff that is being demanded would break compatibility by necessity.
Google basically played a J++ with Android Java, with Kotlin as their .NET/C#.
At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.
Pretty sure they did a J# ;). But I agree that Kotlin is their C#.
The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.
A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.
Edit: Apparently android is forking OpenJDK, since Android 7.
Correct, and J# was a brief transition language to help migrate Visual J++ applications onto the .Net SDK. J++ -> J# -> C# was the evolution.
I say J# is a more apt comparison because like Microsoft's Java, android has a substantial set of APIs that aren't part of the JDK standard. Working on Java vs Anrdoid is practically like working with the JDK vs .Net.
It isn't, check Gerrit commit history, they only take bits and pieces, plus ART doesn't do all bytecode equivalents. Some JVM bytecode don't have counterparts in Dex, rather get desugared into multiple instructions.
J# was the transition product to port J++ into .NET, I am quite sure.
Not only I was there on those years, my employer was a MSFT partner that got to test .NET before it was announced to the world, so that we could have our products as part of the announcement event in Portugal.
OpenJDK is cherry picked, Google only picks pieces of it, rather than full compatibility.
No idea what you are talking about. Google internally has a massive amount of code based on JDK 21, and the (amazing and completely transparent move) to JDK 25 is nearly complete.
That's the full OpenJDK @ Google, and it has been for a very long time.
No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.
They definitely did not, it was Android Java from day one, and Oracle should have crushed them like Sun did to Microsoft, unfortunately Google was the geek darling of do not evil, thus they got a pass from fanboys.
Oracle's Java Mobile Edition could've crushed Android. No one stopped them.
> Google was the geek darling of do not evil, thus they got a pass from fanboys.
Oracle's case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys' doing.
Android was not 100% compatible with Java, but mostly because it had a specialized environment. It did not support things like dynamic bytecode generation, but it faithfully reproduced pretty much everything else that made sense.
And yeah, it would have been so much better with Oracle(tm)(r)(c)(fuckyou) running Android with Pure Java(tm)(r)(c)(screwyou) instead. Now with EJB5 and more XML!
You might be too young to remember, but SunOracle essentially abandoned the Java language development for more than a decade, until Kotlin provided a very much needed magic kick.
Oh, and if you think _Google_ is bad for splitting the Java ecosystem, let me introduce you to J2ME and JavaCard.
Because at the time of WebAssembly announcement all the doomsayers were screaming at the top of their lungs: "JS/TS are dead! Serious developer would never choose it! Finally I can have my <x> in the browser!"
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web.”
Serious question: why would you use Python on the web? Unless you have some legacy code that you want to reuse. Performance is somehow worse than CPython, C-extensions are missing, dev experience is atrocious.
The web is the only major platform that has a language monoculture to its detriment (i.e., not all problems are Javascript shaped). IMO the web ought to become multilingual (and become JS optional_ to further ensure its continued longevity and agility. Hopefully one day browser vendors will offer multiple runtime downloads (or something similar capability).
WASM already offers this, for better or worse... There should be improved interop APIs for DOM access, but WASM is already very useful and even for directed UI control, "fast enough" a lot of the time. Dioxus, Yew and Leptos are already showing a lot of this to be good enough. That said, I would like to see a richer component ecosystem.
All the embedded systems I've worked in have many languages you can use to compile whatever, burn, and run whatever you like. Consoles run game engines and programs written in all sorts of different languages. They don't care as long as they can execute the binary. Phones can run apps using many different languages (C, C++, Rust, Python, etc.).
I’m thrilled to share that I’ve just successfully executed a high-impact release, delivering rich, chocolate-infused value to the ecosystem. It’s all about optimizing internal processes to achieve peak output. #Disruption #Innovation #PersonalGrowth #ValueDelivery
reply