More accurately, imagine how much better the world would be right now if the Java community had been interested in dealing with the many usability and performance problems encouraging developers to move elsewhere.

Imagine if all of those years of saying that it was just laziness causing people not to like Maven, massive object hierarchies, or repeating claims about JIT performance which statistically represented no application anyone actually used had instead translated into “There are a ton of basic gaps which give every new user a bad first impression. We should do something about that!”. Repeat for “Maybe it was a really bad idea re-inventing PHP-style typing with introspection so you have all of the inconvenience of static types but still commonly find type-confusion problems which editors and the compiler won't tell you about”, “Maybe it isn't reasonable to tell people that you normally need to edit multiple XML and properties files to run anything more than hello world”, or “Maybe we should burn with fire any codebase which thinks the right way to handle an error is to permanently stop working but still keep running so anything which doesn't do an end-to-end health-check won't know all of your users see the service as down”.

It may sound a bit bitter but I'm saying that as someone who started using Java circa 1995, left to more productive shores, and recently came back to a new development team seeing that nothing seems to have changed in terms of the amount of time developers spend fighting the tools rather than doing their jobs. Yes, Java code can have competitive performance (Solr/ElasticSearch are world-class) but the code I see is more commonly slower than Python while using more memory and lines of code because it turns out that even heroic attempts at JIT optimization can be easily defeated by the average enterprise Java architecture.

What sort of code do you see that is slower than Python??

It is either the “we have rewritten it in X language and due to the nature the rewrite we actually realized what is a better architecture for our software/half of the features are not even needed”, or you compare totally unrelated things.

Also, I think people commonly underestimate complexity. Just look at your typical npm package description, it is not XML, yet you would never be able to write it by hand. For sufficient complexity, XML is quite good and human parseable.

Also, it simply doesn’t matter. Noone writes 344 hello world projects. What may be missing (but is there with spring boot for example) is an auto-generator for projects.

> What sort of code do you see that is slower than Python?? > > It is either the “we have rewritten it in X language and due to the nature the rewrite we actually realized what is a better architecture for our software/half of the features are not even needed”, or you compare totally unrelated things.

Code which is over-architected with many levels of indirection and attempts to bolt on dynamic behaviors at various levels in the frameworks used. I’ve seen teams unable to optimize things because there were so many levels of indirection that they were unable to reason about the system.

This is not Java the language but enterprise Java the culture as the problem. I have at multiple points seen a web app replaced by Perl (in the 90s), PHP, or Python to get whole multiple performance improvements and stability increases (no more mystery OOMs where it helpfully stays running serving errors rather than exiting so the OS would restart it) when the previous team literally had no idea how to make it faster or stable within the libraries they thought Real Developers™ had to use.

That’s entirely culture, not the core language, but a very high percentage of developers I’ve interacted with had thought that good Java developers were supposed to write code with that much extra complexity. I’ve been wondering whether something like Kotlin will spur a bit of a renaissance as people realize that they don’t have to do things the old enterprise Java way.

That will happen regardless of the language.

The same people were doing that with C, SUN RPC/DCE, C++, CORBA, COM/DCOM, and will do it with Go gRPC or whatever else comes down their path.

This is true in general but I've seen it mostly commonly in Java and done by people who are certain that you aren't doing Java right if you don't. That's why I said “Java community” — there are definitely people pushing for less gratuitous complexity but they don't appear to be a majority. I've seen people be told that they might not be smart enough to be programmers if they didn't immediately grasp the wisdom of a small project needing a hugely complex stack, and once you get the filtering mechanism of that attitude going it takes active effort to recover.

The Java JEE community was created by former C++ CORBA and DCOM developers.

Everything that people complain about Java culture has its roots in 90's C++ and Smalltalk enterprise development platforms.

Even J2EE initial version, hated by so many Java bashers, was originally written in Objective-C as part of the collaboration effort between NeXT and Sun, in the context of OpenSTEP support for Solaris.

Which ended up Sun coming up with J2EE after they decided Java was the way forward and not Objective-C, while Apple post NeXT acquisition when Java still had parity with Objective-C, used the same ideas to port WebObjects into Java as well.

Yes – if I was writing a longer comment C++ would have been my first choice for a contender in the competition of which language has been worse served by complexity fetishists.

My point to the original poster was that it was too simplistic to criticize people for not using Java or the JVM without acknowledging the many legitimate reasons which motivated people to adopt alternatives, and many of the recent features the language has acquired were added because they’d been popular elsewhere. I consider that healthy since competition benefits everyone and especially in programming languages many partisans are loathe to admit that different people have different sweet spots because not everyone does the same work.

Everybody on this thread took literally my wish of "one language" but I never would've said C++ would be replaced by Java, for example. So I really meant "one language" in each category. Obviously there has to be a language to generate machine code, and then another higher-level language on top of that, and so forth.

The world is better off with fewer rather than more languages for obvious reasons. I never really considered the industry to be a fragmented mess until "Go" and "Rust" came along. That was the straw on the camels back for me where I just said: "Ok please stop, you aren't helping."

I have just used one language professionally, but do you think having just one language can solve the problem? But, I agree if a language has all the features you need, and is mainstream, you are well off using that than jumping in for another language for the heck of it and reinventing wheel is not helping anybody.

I am repeating myself, but different people might have different working style. And have different communities have different taste and ways of doing stuff.

Language is not the only barrier in communication. It is just one parameter. I honestly think, different languages allows different ways of doing things (not better), with different tradeoffs. My preference to some language is not just about language I know, but also with respect to what I want to do. And how I want to do solve the problem at hand.

Even if a language, supports all possible styles of programming, will that result in a coherent language? Then, might the language be language not get very big that different people working in different styles resulting either in monstrosity of code base or fragmentation in language community. Else, the language itself might not represent the problems succinctly as the user wants. Features are not the only issue here.

If the language is just needles and redundant, there is not going to be difference in its absence. Yet, I have seen people who have very strong opinions on how to organize code, OOP or not OOP, and of course tabs vs spaces. The fragmentation is inevitable and going to exist as long as strong opinions exist.

The best analogy I can think of to make the point of how important the 'single language syntax' goal should be is "mathematics".

Imagine if everyone "doing" math did it their own way, using their own sets of symbols, and syntax. Even Einstein got his Special Theory of Relativity transform directly from Lorentz. Most innovations are built on top of other innovations, and the ability to share depends on common language.

Not to refute your point here, but I consider improvements in the way the language lets you express your thoughts is also very important. But, I get what you are saying.

Consider an extreme straw man example of roman numeral system winning over everything just because of the inertia. The decimal system is great innovation because, it gave us succinct way expressing idea of numbers.

Not all languages are like that, but certain languages allow and encourage certain style of programming like OOP for java, though it is a multi paradigm language. I think inertia plays a big role here too. Java is always going to be OOPy language for the most part, because it is what community is built on.

Most problems in trying to understanding and communicating is going to be about concepts not the language. The syntax is probably some work, but half a day of work. But, I often do not find it hard to read the code in some other language, I get it once I see the code. But, even after seeing some code, I find it hard to come with code in that language. Because, that is the hard part. jq is one such language. Even though it is niche. When after reading docs, I find it so hard to combine all the small parts of it to make sufficiently large program. That will take, however similar the syntax is.

That is the reason, some particular style of programming dominating a language community. We got settle on something. Language is geared towards solving problems and introducing features for certain style. And that helps. It gives a coherent outlook to language and the community.

That is what I mean when I say, fragmentation is inevitable. Not everybody wants to understand all different ways of doing things. Even if the concepts seem understandable, thinking in terms of them is much harder for people. Multiple language for different dominant style seems to be a saner alternative than single language with all the different style.

One thing you may be missing is that a lot of the work usability over the past decade was not with Java itself, but rather other JVM languages.

As far as performance there is no doubt that the modern JVM is quite fast. Vert.x benchmarks are consistently on par with Actix and other low level frameworks.

> As far as performance there is no doubt that the modern JVM is quite fast

As a non Java developer, the reason I don't touch anything Java related is because of popular applications like:

1. Eclipse and Jdeveloper which you have time to get a coffee before any of them boot up

2. solr/elastic search: 8 core and 16GB of RAM as a minimum requirement on a DEV machine, that's insane when sqlite can do basic full text search on the cheapest raspberry pi

3. Jenkins which can't run a few jobs without using many GB of memory. Other CI/CD I've used and was made in Java were also dog slow and painful in so many way: IBM urban code and another one made by oracle which was well oracle

4. the arduino IDE which often freeze my laptop forcing me to ctrl+alt+suppr

5. oracle DB: internally refer as the beast by people who deal with it, I wasn't able to run a local copy on my machine as my work laptop don't match their 256GB of RAM server we have for the dev environment.

6. boot time which make it almost unusable for CLI type of application

7. Oracle

Maybe you can make fast and efficient Java application but the highly visible ones aren't that good if you don't need all those complicated features. On the contrary, applications made in Go/Rust tend to run fine on my machine or the cheapest server.

> Eclipse and Jdeveloper which you have time to get a coffee before any of them boot up

I just take to time to wait for one of those Rust builds to finish

> solr/elastic search: 8 core and 16GB of RAM as a minimum requirement on a DEV machine, that's insane when sqlite can do basic full text search on the cheapest raspberry pi

Definitly not the hardware requirements of a 2011 dev workstation, the first time I used Solr, and as such also not the requirements of using it in 2021.

> Jenkins which can't run a few jobs without using many GB of memory. Other CI/CD I've used and was made in Java were also dog slow and painful in so many way: IBM urban code and another one made by oracle which was well oracle

So which alternative are you using with similar capabilities and less hardware resources?

> the arduino IDE which often freeze my laptop forcing me to ctrl+alt+suppr

XCode does it all the time, and is pure native code, in a mix of C and Objective-C code.

> . boot time which make it almost unusable for CLI type of application

Learn to use AOT compilers for Java.

> Oracle

Partner in crime alongside Sun and IBM in making Java widespread, having a RDMS that allows for stored procedures in Java, responsible for sponsoring research work to prove it is possible to write high quality JIT compilers in Java, did more for Java than Google would ever done for it, if they actually bothered to buy Sun.

> 2. solr/elastic search: 8 core and 16GB of RAM as a minimum requirement on a DEV machine, that's insane when sqlite can do basic full text search on the cheapest raspberry pi

You would need to be using the production server settings and traffic volume for this to be true. I run both - sometimes simultaneously - on a 2012 MacBook Air with 8GB and rarely even notice them running. Unless you’re hammering the system with expensive requests these less memory than Gmail in Chrome.

That's the requirement for dev, prod is double that: https://www.google.com/search?q=elastic+search+hardware+requ...

Those figures Google highlights are for a Palo Alto product which uses ElasticSearch. Speaking from experience, that is much higher than necessary - usually the 1GB default is more than enough for development use and even production for lighter usage. The general figure to care about is index size - if you’re indexing hundreds of GB in development you might have problems fitting it on a laptop but otherwise this is not excessive or unusual given the massive feature set.

You're conflating the monstrosity of J2EE (which admittedly was a mess, and completely unrelated to Java itself) with the "Java Language" by which I mean the syntax of the language itself.

Yes the younger/newer generation took a look at all the XML files in J2EE and said "Isn't there something simpler", and so now today we ended up with JavaScript running on the server side (NodeJS). TypeScript came to the rescue over the last 5 years, but now we have a world with TS and Java. The solution should have been to make Java run in the Browser, and not JavaScript, but I understand the history, and how, when, why that occurred. I've been coding 30ish years myself, like you.

> You're conflating the monstrosity of J2EE (which admittedly was a mess, and completely unrelated to Java itself) with the "Java Language" by which I mean the syntax of the language itself.

I'm not sure how well you can separate that: most people are going to hit those bumps when they get started, and they're going to see an ongoing frictional cost against their productivity. Yes, there are some neat things in the language — especially newer versions — but there are a lot of people who would benefit a lot from, say, a “Java: the good parts” distribution which makes it easy to start a new project and evolve it, and then SEO it as much as possible so people get that advice rather than the 10+ year old stuff many web searches will have highly ranked.

I do think there's an interesting alternate history where WebAssembly happened many years earlier in the form of Java byte-code. That would have lost a lot of the ability to read other people's code but it would have had better performance earlier and a good story for language competition which has brought many good features to Java from other languages. Unfortunately, after around 1997 or so that really came down to Microsoft so it would have been VB or C# in any case.

XML is interestingly similar where the core language community charged ahead building ever more standards on top of it but assumed that its inevitability meant someone else would fix their … not great … tools, specs, and examples for them — and then were surprised when almost everyone abandoned them for easier tools. I always liked the idea of XPath but it's effectively never moved past 1999 unless your world exclusively avoids libxml2, which wasted most of the hard work the standards group did.

One thing I think may be common about both of those is a big shift in how easy it is to build and ship development tools and programs: a 90s programmer had to live with what they got in a distribution to a much greater extent because you couldn't count on everyone having an internet connection, a fast one, package management hadn't happened much outside of the Linux/BSD world, and new things required waiting for someone to write a book you could order, finding a local user group, asking in Usenet, etc. Warts in your language still mattered but less so since for many people it was easier to keep using something than switch. After the 2000s, though, I think a lot of people realized that the cost of switching was so low that they had to care about developer ergonomics a lot more unless they had something like the massive platform pull Apple had with Objective-C and Microsoft had with C#.

On the .NET side our JEE mess is called SharePoint and DCOM.

Also regarding XML, Biztalk anyone?

I remember DCOM! I was a WIN32 MFC C++ Windows app developer from 1990 to 2000. I forget which person at MSFT finally ended up admitting "The Registry" was a mistake, but I think it was Gates?

It was right around the time when WAR/EAR/JAR files in Java were showing the power of having everything packaged and self contained. Meanwhile MSFT was stuck in DLL Hell for decades. ha.

As Java/.NET consultant I deal with both stacks since they exist, so it is always kind of funny see one side throwing balls to the other one, without realizing their own glass roof.

Regarding Java packing, isn't it funny how everyone is jumping into Docker hype just to get what Java containers have given us for the last 15 years?

Yeah technology stacks have gotten completely out of hand over the decades. My current concoction is here:

https://github.com/Clay-Ferguson/quantizr

Java+SpringBoot+Docker

I think I'm "doing it right", but like religions no one's is provably correct.

The younger kids are saying: "Meh, we'll just run NodeJS on the server, so we can ignore the J2EE mess the previous generation created since they're older and therefore dumber than us."

> I'm not sure how well you can separate that: most people are going to hit those bumps when they get started.

Your XML example is spot on and I agree. However I'd never say XML itself was flawed specifically because some of the tools, APIs, and specs built on top of it were flawed.

That would be like saying electricity itself is flawed because you don't like electric tooth brushes.

Likewise, Java was not flawed just because J2EE was a mess. The fact that J2EE drove people to NodeJS, has nothing whatsoever to do with Java itself.

> However I'd never say XML itself was flawed

I’ll say XML was flawed. It was a great initiative behind the wrong data model. The idea was to take what made sense for documents (strings with markup) and use that to represent everything else. But most data structures are really awkward expressed that way, and you run into weird decisions like: Should my map be a list of items or a set of attribute pairs in a single node? Is the key a node or an attribute? When does order matter? Etc.

If the XML standards group started with JSON or YAML or .. anything else, I think they would have made something really useful. But we didn’t think of that at the time, so instead we have XML. An impressive monolith built on a dead mountain.

You took the first half of my sentence pretended like that was the complete thought. It wasn't. The whole sentence is the thought.

What I meant was "You can't say technology X is flawed because tools using X are flawed".

Ha, not even. I see more shops doing TS/TS (backend TS/FE TS).

Even me, 20 year Java vet. Basically been doing full time TS for about 5 years now.

Q: Why does TypeScript exist? A: To fix JavaScript.

Q: Why was JavaScript invented? A: To run code in the Browser.

Q: Why didn't they run Java in the Browser? A: They did (applets). They tried. They failed. So they had to start over. They WANTED "Java" in the browser, but it wasn't practical for memory and CPU reasons, so they cobbled JavaScript together over a weekend.

TS is what everyone is coding nowadays, and yes it definitely "fixed" the problems with JS.

However the world would be a better place if there was just Java, and neither of it's two offspring were ever born (JS and TS).

Yet, it compiles to JavaScript and it allows many of the things that make JavaScript unsafe.

JavaScript is highly mutable and under the right circumstances you can trick JavaScript applications to modify themselves. i.e.: Prototype pollution.

You can write 100% perfectly type-safe code in TypeScript. You'd have to accidentally do a 'var' instead of a 'let' variable, or forget to add a type to a parameter, but if you try you can get pretty much 100% type-checking on every letter of every variable or object.

Run this, please.

    // 100% type-safe function :-)
    function f(a: Date): number {
        return a.getDate();
    }

    // Input to 100% type-safe function
    const p = new Proxy(new Date(), {
        get: function(target, prop, receiver) {
            if (prop !== 'getDate') {
                return Reflect.get(target, prop, receiver);
            }

            return function() {
                console.log('Not typesafe :(');
            };
        }
    });

    f(p);

Output: "Not typesafe :("

What happened? all type-safety was circumvented. The f function that should return a number did not return a number. In fact, it didn't return anything.

The TypeScript compiler didn't return any errors either. This is perfectly valid TypeScript.

Why? because TypeScript is based on JavaScript. It is not 100% typesafe and it will never be.

Is TypeScript an improvement? yes. Does it help a lot of people? yes. Is it 100% typesafe? no.

Did TypeScript "fix" JavaScript? Mostly, but no. I hope the mods unflag my original comment.

I had already given two examples of how you can create non-type-safe code in TypeScript. I mentioned 1) the 'var/let' way and 2) The "Not including types on parameters" way.

You then gave an actual example of #2. lol.

That is not what is happening here. TypeScript correctly infers that type of the variable is a Proxy for a Date object. If you do not supply a Date object as first argument, the code won't compile.

The part that breaks things is that when f invokes a.getDate(), the Proxy get trap changes will return another function instead of Date#getDate at runtime, and that wasn't validated at compile time.

Proxy is part of JS. When did I ever say ANYTHING in JS is typesafe? Nothing in JS is typesafe.

However this is also simultaneously true: You can code in TypeScript and achieve 100% type safety by putting types on everything. If I claim all cubes can be painted red, you can't disprove that by proving green cubes exist.

And what does TypeScript compile to? JavaScript.

Does TypeScript forbid using JavaScript features? no.

Can TypeScript realistically verify that your program is type-safe? no.

Is TypeScript 100% type-safe? no. They wanted fast adoption, therefore they allowed JavaScript and untyped variables.

You can go into my 250,000 loc project and randomly pick any variable name, method name, parameter name, etc., and put a typo in it or wrong type, and the compiler will catch it.

I have 100% type safety, and it's all done by TypeScript and my programming language IS TypeScript (not JS)

The the final output format generated by a compiler has absolutely nothing to do with whether the Language being compiled is typesafe or not. That would be like saying since Bytecode is not typesafe therefore Java is not a type safe language.

TypeScript is not the only way to achieve that.

Google closure compiler and JetBrains IDEs can use JSdoc to validate types. I have used those to a reasonable level of accuracy to document entire JavaScript projects where I cannot migrate to TypeScript.

Excellent. Rock on man. I never thought I'd be a Microsoft fan again, but after they invented TypeScript/VSCode, I love them so much I might move to Redmond.

Just Java? That seems bizarre. There's so many more languages now days than just Java. I would love for Swift to take off. Don't get me wrong there is a lot in the Java ecosystem, but it's age is showing. And it's not lightweight. If I'm trying to spawn processes quickly it's not Java. If I want to run 100 instances of something, the RAM is going to cost me. JS and other fast to boot languages are also much more adaptable to serverless.

Now I'm not saying there's no room for Java any more, but "just Java" meeeeeeh.

This. Time flies by and before long it happened.

I can confirm that the seeming majority of application-layer code written at Google is Java (with Go being a relatively small contributor by way of comparison).

That said, I shudder at the thought of Java being any larger than it is, much less ubiquitous. If I had to choose between this world and one where Java was the "one true language" (or even a more extreme version of the current situation where we have other languages all built atop the JVM) I would pick this world with fragmented languages every single time.

Whatever people find unacceptable about Java could've been fixed. No need to burn it all down and start over.

Remember, I'm talking about "source level" syntax of the language not any specific VM implementation. Every compiler and VM can be replaced eventually.

It's the code syntax that needs to be "universal" not anything else.

> Whatever people find unacceptable about Java could've been fixed.

It's been DECADES. Plenty of time to fix things but nope. I don't know what Java's developers were interested in but improving things for other developers was not one of them.

C# is literally a better Java already. And Kotlin.

I agree. The problem with Java is its culture, which cannot be fixed by same thinking which created it.

And by culture I mean, java attracted people who think that lines of code are cheap and see nothing wrong with a 200 line class which has no actual behaviour beyond boilerplate. People who measure their output by the number of lines of code added per day, not the number of features added to a project per year.

Any "fixed" version of java needs to either bring those people along - and in the process import a lot of java's stale thinking. (Some corners of the C# world struggle with this). Or leave those people behind and build a new community around your new thing (eg Scala, Clojure). You can see this in the java community already - there are plenty of tools in the modern JVM for doing terse functional programming. But as far as I know that stuff remains unpopular. Why? My theory is that most of the people who really care about writing terse, efficient, maintainable code jumped to better languages years ago.

> 200 line class which has no actual behaviour beyond boilerplate

A skilled Java developer might make a huge POJO have every variable private and then implement getters and setters to control or monitor access to every member.

But then some noob straight outta college will look at that code, not understand why it's being done so 'stupidly', and just delete all the accessors and make every variable public, so you don't even need any getters/setters. Said noob will consider himself a superior programmer until he looks back on it 10 years later, with enough wisdom to see clearly.

Yikes! On behalf of everyone who doesn’t write Java for a living, 200 lines for a plain data object, full of trivial getters and setters everywhere is crazy. Code like that decimates your velocity because of how much effort it takes to refactor or add features to your project.

The noob’s instincts are right. Well written code in just about any other language doesn’t need all that crap. And for good reason - you can really feel the difference if you actually measure your performance programming, in the short term or the long term. And in either features/hour or features/line changed.

I worked at a place once which had this C# project which wrapped incoming http calls into calls to our internal backend (also http). Then it took the JSON from the backend and converted it to JSON for the browser. The code was 3500 lines full of that sort of POJO getter and setter crap. Every time we added a feature, this code needed to be updated. We had 2 people assigned full time to do those changes. After way too many meetings we managed to replace the whole thing with a few hundred lines of nodejs code. Those guys were moved into more useful roles - saving the company 2 full time salaries.

I probably have 1000s of plain getters and setters in my code, and I never typed ANY of them. lol. VSCode has a "Generate Getters and Setters" refactor function, and I can make them plain publics any time I want. So you can't blame the Java Language itself for their existence.

What a waste. C# has properties. If Java wasn't so against breaking forwards compatibility, Java could actually be a good language. It was good in 1995 but the changes since then have been too slow and too late.

About 1998 when Microsoft tried to invent their own "flavor" of Java, I lost all interest in the company, and that's right when I switched from a C++ developer to Java. C# was just another "copy" of the VM concept Java had, as you well know. Even if C# was superior under the hood (which it isn't) I still claim it just fragmented the industry and was just an example of a company creating their own proprietary stuff for their own self-serving reasons, and before you think you're correcting me, yes I know the CLR is supposed to be machine independent. When VBScript was finally yanked out of browsers the world celebrated.

I will openly admit however when VSCode came along and TypeScript I totally regained a new love for Microsoft, and they have redeemed themselves, also by accepting Linux into their dying OS.

The fact that you didn’t have to type them doesn’t make them free. Software spends most of its lifetime in maintenance. Those getters and setters have to be documented, adjusted, unit tested, code reviewed, deleted and renamed, and scrolled past.

Typing is easy. It’s all that other stuff that I avoid by using better languages / better conventions.

That's why experienced Java devs generally try not to put any logic code in POJOs.

So you never generally even open those files unless you're expending the 5 seconds it takes to add a new prop. But as I said I could make each property use one line of code if I chose too...something like "String x;" just like all other languages.

Setters and getters are only popular in Java EE/Spring based environments (and it can be easily useful).

There is nothing in java that requires it per se, it’s just a design pattern/“standard” for some library to dynamically inspect objects. As for the amount of time it takes, I’m fairly sure that it takes less time to press alt+insert+select setters getters than it is to write anything, but to each there own. It’s not like people read source code from top to bottom.

Also, this decimates your velocity is just straight-up coming from an alternative world. How do you write code, are you copying something by typing?

I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality. Fact is, Java is so huge that for every unreadable mess of a project, you get someone working on robot programming or something totally different with proper architectural decisions and the like. It is quite a bad take to assume it for the whole language.

> Setters and getters are only popular in Java EE/Spring based environments (and it can be easily useful).

I'd love to see stats on how common this stuff is amongst java programmers. I think its more popular than you think.

I agree that modern java has lots of modern tools to write reasonable code - like closures and functional primitives. But its very normal amongst java programmers to never use that stuff.

I worked as a professional interviewer for a year or so recently and interviewed 400+ programming candidates. One of the tasks was a 30 minute coding challenge - using the candidate's own computer and preferred language. A huge percentage of the java programmers, even under explicit time pressure, wasted time adding needless junk (like getters and setters or extraneous, pointless classes) to their code. Out of maybe 50 java programmers I think I only saw 1 or 2 java candidates use any of java's functional programming primitives (like map) to keep their code terse and clean. Most typed everything manually, and didn't know or didn't use their IDE's codegen features.

Is that the fault of java, the language? I don't know. As I said in another comment I think the problem is cultural. I don't really have a problem with java-the-language. But a large part of java-the-community seems blissfully content with mediocrity. I took java off my resume years ago because I don't want that kind of coworker.

> How do you write code, are you copying something by typing?

In the languages I use, copy+paste is never needed. Thats what the compiler is for, and things like rust's derive(Eq) macros.

> I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality.

Nope. Eg:

https://github.com/apache/incubator-retired-wave/search?q=ge...

I think every sufficiently large community will have outliers (in both direction), and Java is huge. I have a similarly bad opinion on the average JavaScript developer (or basically every “average” developer), but it is the product of the business decisions behind projects (cheap, bad developers, with huge churn rate) more than fundamental technical one.

Nonetheless, I’m sorry for my previous overtly aggressive comments, it has no place here.

> I have a similarly bad opinion on the average JavaScript developer

I write a lot of javascript for a living, and you're not wrong[1]. I think the struggle javascript has is that an extremely high percentage of javascript programmers are pretty new to programming in general. So there's an awful lot of javascript code written by unsteady hands.

If javascript is a magnet for novices, java feels like a magnet language for middle aged with kids "programming is just a job for me" indifference. I feel contempt for that mindset - but to respond in kind to your apology, I think the contempt I feel is probably reflected fear / disgust at the idea of settling. To me programming still feels like casting magic spells. I think I'm terrified of that spark some day being extinguished.

[1] I check in on this issue every year or so and it never fails to delight and horrify in equal measure: https://github.com/ChainSafe/web3.js/issues/1178

I personally don't mind heated technical debates. It's unfortunate that there's so many SJW moderators hiding in their 'Safe Spaces' who think it's their job to terminate any arguments that arise. I guess they're always "on the hunt" and trigger happy.

We don’t write it, and we don’t read it, so it never needed to be there. Boilerplate is our arch-enemy, and I’m glad we have Groovy and Scala and Kotlin to attack it.

If it really bothers you, there is lombok. But I will tell you something, the complexity of most programs will require many lines of code that you simply can’t decrease anymore. Whether it is more by a tiny tiny factor doesn’t matter, over performance, observability and maintainability of a language - though being on the JVM, the mentioned languages can tick all of them (I’ve only written groovy with gradle, but due to the lack of typing, I though of it as more of a scripting language)

I use Java since first beta. These getters and setters are always looking awkward for me, unless they are part of a library API, so they are useful for providing backward compatibility, or they are lazy objects, or they are defined in an interface. In my own code, I avoid using them in POJO.

For example, I prefer

  public class LineOptions {
    public Color color = Color.BLACK;
    public int thickness = 1;
    ...
  }

  void drawLine(int sx, int sy, int tx, int ty, LineOptions options) { ... }

  ctx.drawLine(0,0, 100, 100, new LineOptions() {{ color=Color.RED; thickness=3; }});

IMHO, it is much simpler and easier than classic POJO + Builder patterns.

  public class LineOptions {
    private Color color = Color.BLACK;
    private int thickness = 1;
    ...
    public LineOptions() { }
    public LineOptions(Color color, int thickness, ...) {
      this.color = color;
      this.thickness = thickness;
      ...
    }
    public Color getColor() { return this.color; }
    public LineOptions setColor(Color color) { this.color = color; return this; }
    public Color getThickness() { return this.thickness; }
    public LineOptions setThickness(int thickness) { this.thickness = thickness; return this; }
    ...
  }
  
  ctx.drawLine(0,0, 100, 100, new LineOptions().setColor(Color.RED).setThickness(3));

or even more classic

  LineOptions opts = new LineOptions();
  opts.setColor(Color.RED);
  opts.setThickness(3);    
  ctx.drawLine(0,0, 100, 100, opts);

The Java languages gives you the choice of whether to use getters/setters or not. You added a good example. The main reason I love getters/setters is they are a 'hook' to add any code (like logging) if you want to detect when a variable is being read/written.

Isn't that exactly what is happening in Java land now?

That's what Scala and Kotlin are, fixes for the original Java flavor. Then again, more alternatives are good for competition; and incubating and sharing new designs that aren't possible in a very old language.

barring competition languages seem to stall out over time. Java fell out of favor because every java app turned into a pile of xml and factories that everyone hated and was slow to develop. The faster evolution of peer languages allowed for recognition of what people didn't like in Java (The ceremony of getting setup and invoking "app" logic).

The better parts of Scala, kotlin, and the guava library are steadily making their way into the language. But if there wasn't competition the language would absolutely stagnate again as risk aversion sets in.

Right, I think the languages that compile JVM bytecode were much more heading in a better direction than the ones who said "let's have fun and just start from scratch, and further fragment the industry"

Couldn’t you also say the same thing about Java not going with one of the earlier bytecoded VMs? Or, from the other direction, would we have seen more languages embrace the JVM if it’d been more open and things like invokedynamic had been added earlier?

I think there are some interesting points to made where you’re coming from, but this fragmented approach isn’t effectively making them. Something like a blog post might be better.

Here's a non-fragmented translation for ya: "The fewer languages there are the easier it is for developers to share code."

You’re just painting caricatures of language designers. Flamebait without substance.

This sounds far-fetched to me, partly because of the nontrivial technical differences between Java and Go and partly because of the politics surrounding Oracle’s ownership of Java and the way Oracle quashes community efforts.

Value types, interior pointers, multiple levels of pointers, slices, and radically different indirect dispatch semantics are just a few things that Go has that Java doesn’t. These aren’t things that you can staple to Java. Java is more than syntax, it’s the semantics of the JVM and its object system, which should only be extended in a backwards-compatible way.

So I’m gonna say that the reason Go exists is exactly because the creators didn’t want to burn down Java and start over. It turns out that you can create a new language without burning anything down. There is also C# and the various nontrivial differences between C# and Java, like value types and type erasure in generics.

There are plenty of languages which exist side-by-side with Java in the JVM: Clojure, Kotlin, and Scala to name three. These all have their differences but they’re all designed specifically with the JVM in mind. Go isn’t.

Go instead decided to go with a minimal runtime with a one-two order worse GC than any you can find in the JVM, which will result in inferior throughput in actual world benchmarks.

While generating less garbage decreases the load on the GC so it can sometimes get away with it, complex server apps will not fall into this category. So actually, I really don’t see much value in go, other than the “you can throw as many developer at it, because they can’t really step on each other’s foot” which is actually great for what it was created for.

> ...which will result in inferior throughput in actual world benchmarks...

You're telling me that Go's garbage collector, which is optimized for low latency, has worse throughput than the JVM's default allocator, which is optimized for high throughput?

Most garbage collectors are either designed for low latency or high throughput. You cannot optimize for both. The choice for high throughput makes sense for batch programs, like compilers, command-line tools, generating analytics reports, etc. Choosing low-latency makes sense for web services and the backend services behind them.

As fanout increases, the GC latency in backend services becomes much more important.

I think the world was almost tolerable before Go and Rust came along. We already had too many languages even before those two, but at least there was a clear leader: Java. Nowadays the market is completely fragmented.

What's your issue? How exactly do more languages harm you? Or harm anyone? Is choice bad for some reason?

I think all languages do suffer from their initial design. And spend 5-years iteration to circumventing them. Java will have proper asynchronous management in 5 years, Go will have generics in 5 years, Rust will have a garbage collector variant in 5 years, Python and JavaScript will have full multithreading in 5 years.

In the end, no language is catching the whole problematic and solve it at once. So there is a programming language fatigue.

PS: when I say that things happen within a timeframe of 5 years, it includes the time to deliver the feature in the language, and people to massively adopt it, and new developped code to include it in mass.

Every new language is an attempt to fix some problems in the existing languages but at the same time be simple to learn and use. But the problem-space of programming is very complex. So while a new language does something better than some existing languages the language designers do not foresee all problems that may arise in actual use.

Maybe a way to proceed would be to have a common set of code which every new language would try to rewrite, and thus see how much better it is, or is not, than the existing ones. Comparative analysis.

Exactly right. Each new language thinks they've simplified and solved problems, but in the end they end up having to solve the same old problems that have already been solved decades earlier lots of times.

The ability share code is critical. For people to share and cooperate it's much better to have fewer languages, than 100s.

Companies are spending billions each year because of having to translate from one language to another.

Rebuilding similar functionality maybe but who's actually porting between languages?

Plus code can already be shared with various bindings. Lately there's been a big push with "microservices" or generally networked architectures so different components built in entirely different stacks can still interoperate just fine.

> Whatever people find unacceptable about Java could've been fixed.

yeah by making it common lisp instead of java

That's a great point. Lisp is so simple in every way, you could make a good case that it was superior to all other languages, and that perhaps inventing Java was the mistake and Lisp should've been the "final" language.

There was never, and shall never be, a particular reason to anoint Java - or any other development environment - as some kind of universal panacea “one true language”, and demanding everyone’s attention for your own pet preference is beyond hubris and into the realms of absurdity.

> All those kiddies

You chose the wrong venue for this remark.

Perhaps you have this forum confused with Reddit. By my estimation, everyone here is over forty, either in body or in soul, and by way of particularly cringeworthy example the correspondent you most unfortunately chose to rag on was already a computer scientist of international note twenty-five years ago. Many, if not most, of the designers of the new programming languages and paradigms under discussion are of similar breadth and depth of experience.

There is no monopoly on the grumpy old fart act; there is only a difference in their willingness to continue pushing back the boundaries of ignorance.

All of which is notwithstanding the necessary and essential vigour of youthful perspectives, c.f. Seymour Cray’s notable preference for working with recently graduated engineers both for their energy and their fresh ideas.

I am sufficiently ancient to not require any external validation, and yet here you are.

I disagree with your assessment, but at least we can see where you fall with respect to that attribute.

To put it plainly, Java is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix.

edit to respond: calling them "bells and whistles" is a deep misunderstanding of what sum types are. They profoundly change how every single piece of code in the language is written, starting from how nulls are handled, and cannot be retrofitted into an existing ecosystem. (You can add them later, but baking in sum types from the start is very different. In particular Java would not have its terrible exception system if it had sum types.)

Sum types are coming to Java in the form of sealed classes:

https://openjdk.java.net/jeps/397

To be fair, Java has always supported a particular flavor of sum types founded on subtyping: use an abstract class with a private constructor as a base, add nested static final subclasses for the variants, and decide whether to use instanceof or the Visitor pattern to dispatch on each variant. (The Visitor approach corresponds to a certain isomorphism -- the sum type `A + B` is equivalent to `forall T. (A -> T, B -> T) -> T`, where the pair of handlers `(A -> T, B -> T)` is the titular visitor.)

That JEP elaborates on the same ideas (notably using `instanceof` instead), as the linked JEP explains, but the motivation for sealed classes extends to further harmony with subtyping. The major item seems, to me, to be allowing interfaces to be a supertype. A minor but distinctive item is that the sum type's variants can be defined at (some) distance from the base type, rather than all being defined in a single breath.

The problem is, even though you could always express sum types in Java, it's verbose, unpleasant, and above all "clever" in a way unnecessary in other languages. I think this JEP helps somewhat -- the private constructor trick in particular goes away -- but it doesn't really help with clients of your sum type. Pattern matching is still yet to come, and if you want a Visitor, you still need to write a Visitor.

To the grandparent's point, this JEP isn't enough to provide a coherent alternative to checked exceptions or other kinds of structured control flow.

Every language is fundamentally broken from day 1, whether it is a known tradeoff or something that remains hidden for several years. Also, even if you had the perfect language with a presumably not-mainstream feature, you would have to make that feature somewhat known in the developer ecosystem (just look at Rust’s borrow checker, it does cause issues for newcomers as opposed to features already having an analog in other languages). While FP ideas were known before Java (ML predates it by quite a few years), it has become only recently more acceptable, so it makes sense to only know incorporate it into the language (and yet again, do note that FP is not a silver bullet so java has to let developers write imperative constructs just as well as before)

Unlike first-class monads, sum types are not some sort of esoteric FP construct that arises from challenging technical problems around dealing with external state. They are the very obvious dual of product types, which every language has some version of. They are easy to understand, require very little tutorial-ing, and their power is immediately obvious when you start using them.

Product types model "x and y", sum types model "x or y". One of them is universal. The other has been totally missing from mainstream languages until recently. No wonder our software sucks so much.

I agree with you in that I really like and really miss them from languages since most of them doesn’t have it in a feasible way. But sealed classes are coming fortunately in Java at least.

I’m curious what your alternative is, given that Go famously also lacks sum types.

Yes, Go is a fundamentally broken language too. As is C++, as is C. Sum types are the absolute bare minimum a language must have for me to not consider it broken beyond hope.

Go in particular is really unfortunate for a language so new. The language's weaknesses have dropped my estimation of its creators by several notches.

"I'm broken and can not use a language without Sum Types"

There, I fixed it for you.

Yes, that's possible. I would rather tear my eyes out than use a language without sum types. The benefits of sum types in being able to model arbitrarily complex domains are extraordinarily massive.

Every language has product types. Every programmer understands how useful product types are. Why in the world would the same not apply to sum types?

You sound like you have a hammer, and so every problem looks like a nail.

Sum types can be useful. Other aspects of languages can be useful, too. Why fixate on that one? And if you're going to say that it's a minimum bar, well, some of the other features are missing in most languages that have sum types.

Pick the language that has the total set of features that makes it easiest to write whatever program you're trying to write. Don't get locked in to focusing on only one feature.

I work with Java in my day job; it's by no means my favorite language, but I can be quite productive in it.

I haven't kept a tally of my frustrations with Java, but I can assure you that the most frequent is its lack of first-class sum types. Every time I need to encode (encode!) such a basic concept as "it could be this or that" using subclasses and some Design Pattern to Manage the Variants (usually Visitor, sometimes State), I metaphorically weep for my soul.

There are plenty of other minor gripes I have with the language -- there have been multiple instances where generic generics (HKTs, `class Foo<F<_>>`) would have made things much clearer -- but sum types are certainly the most prominent.

Yes that's why I write Rust.

Our field has a terrible reputation for quality. In my estimation roughly 70-80% of that is directly or indirectly because of the lack of sum types.

Directly: people don't have the right tools to make invalid states in their business logic unrepresentable.

Indirectly: the lack of sum types results in broken null and error handling.

Late reply; I hope you see it. My reply is late because I had to think for a day first. So, my sincere congratulations - a post that makes me think for a day is much rarer than a post I agree with.

To me, sum types for error handling are isomorphic to checked exceptions. They both let you do dual-track programming - separating the normal path from the error path. Both have compiler support for enforcement. But checked exceptions are no longer considered to be the answer. What went wrong?

The problem turned out to be the programmers. They did at least two things that subverted checked exceptions.

First, they silently ate exceptions (that is, had an empty catch block just to make the exception go away. This is the equivalent of having a sum type that is either an integer or Nothing, and a function. Rather than return the sum type, the function returns an integer. In the Nothing case, the function just returns 0. That's about the same as the empty catch block to not have to declare the exception in the function's return type.

The second way checked exceptions went wrong was the opposite. When a function could throw Exception1, Exception2, Exception3, and Exception4, it was tempting to just declare it as throwing Exception (the base class). In the same way, a function that gets SumType1 back from one function, SumType2 back from another function, and SumType3 from a third function may return the sum of the sum types. It becomes an Everything type.

In both cases, the problem was that programmers were lazy. But here we are 20 years later, and programmers are still lazy. Until the programmers change, sum types won't fix things any more than checked exceptions did.

Thanks for the thoughtful response. I spent a bit of time thinking about it, and thank you for that as well.

So, I think you're right about a result type being isomorphic to checked exceptions, for the reasons you laid out. If you compare it to Rust, what ends up happening is similar -- many libraries return an error type that's a union of all their dependencies' error types, and binaries end up using an "everything" anyhow::Error type in the end. However, I think where sum types in general end up working and checked exceptions don't are:

1. Sum types don't encourage a mix of checked and unchecked exceptions the way Java does. Translating from Rust, all exceptions that are meant to be handled by regular users are checked. The only exceptions that are unchecked are broken invariants (panics), which usually end up being handled either through aborting the program or through some sort of top-level restart logic. You could write Java in that style but it's not the ecosystem's convention.

2. Sum types are more general than checked exceptions: they can be used to express nulls and business logic as well. I suspect checked exceptions would have worked better if Java also had nullable and non-nullable types, because nullability is such a common source of errors.

3. You're right that you can drop an error on the floor with sum types as well, just like an empty catch block with exceptions. But that just doesn't happen nearly as often in practice, because result types form a closed set. With checked exceptions, in practice you often end up with a method throwing both checked and unchecked exceptions, and the same syntax is used to handle both. I think checked and unchecked exceptions are fundamentally very, very different and mixing the two is a mistake.

Once again, thank you for your response.

Can anybody explain why the parent is being downvoted?

We can argue on the percentage. But the point on the direct and indirect damages makes a lot of sense.

At this stage I'm now convince you're trolling us all. Well done you had us all fooled :)

Not trolling. Entirely serious.

Also - "I refuse to use most languages that have been used to solve a shit ton of problems".

Or, "I will not use any language which made software eat the world"

Does the Either type from the vavr library for Java cover this? https://www.baeldung.com/vavr-either

I wouldn't say no, because it's built with the right spirit in mind. But at the same time, it's different from languages have native support for sum types. Advantage of sum type is that it can be matched exhaustively like an enum, but at the same time it's flexible to contain any data like a data class.

Having a type available in an optional library is not the same thing as having them baked in from the beginning. The absence of sum types warps a language in grotesquely terrible ways, such as Go's err != nil patterns or Java's exception system and visitor patterns.

C has unions

What more do you need?

Are unions used for error handling and null checking? No? Then they're not very useful.

Improving a dominant (but broken) language is called "innovation" and "improvement". There's no reason all your magic bells and whistles couldn't have been added into Java. Creating new languages just made life worse for everyone.

>There's no reason all your magic bells and whistles couldn't have been added into Java.

Because it's designed in a way that doesn't always allow these bells and whistles.

If I were to tell you that we should have kept using horse-drawn carriages, and that any of the fancy bells and whistles that cars have could be added to horse-drawn carriages, you would probably look at me with confusion.

> Improving a dominant (but broken) language is called "innovation" and "improvement"

Sure? But modifying an existing (and for most of its history proprietary) language can be a difficult, potentially-political move. If I have an idea on how to do, I don't know, linear-types checked at compile-time, I wouldn't have any idea where to begin adding that to the javac compiler. It might be easier to build my own little language to build it, and then hope that maybe the Oracle devs decide to pick it up.

The horse-drawn carriages analogy is not applicable because I'm using Java in my current project, like most other large corporations, I don't find it antiquated, I find it "state of the art".

There are some improvements that can be made however (any language can be improved on), that would require minimal breaking changes (like fixing Type-Erasure), and I'd even be fine with minimal breaking changes that break backwards compatibility every 5 years or so.

The problem is when people say "Let's burn it all down and start over, so zero existing code is salvageable."

Sure, great, but you must understand that adding language features to basically anything that isn’t Lisp moves glacially at best.

I mean, let’s go with your example with type erasure; people have been complaining about it for more than a decade, and Oracle still hasn’t fixed it. The Java language designers aren’t stupid, and I’m sure they’ve read the complaints, but it still is almost universally agreed upon to be a broken feature of the language.

It’s almost never clear if “language feature X” is a good idea until it’s been implemented and battle-tested. If I have a new idea on how to build something in a compiler and I’m not sure if it’s a good idea, are you saying that the best path forward would be for me to make a PR to javac instead of building a proof of concept language?

Replying to my own post because it's too late to edit and I'd like to clarify a bit.

I actually do agree that as software engineers, we're often a bit too eager to reinvent wheels. While I am not a huge fan of Java, if I owned a company, I would probably be more likely to use a JVM language (probably Clojure) than I would to use something like Haskell or Idris, precisely for the reasons you've discussed.

My overall point, though, is that often times languages themselves lag behind the state-of-the-art; there's been a lot of progress made in language design, and Java (and a lot of other languages) can feel crufty in the process. Sometimes the wheel really does need to be reinvented...if we could somehow convince the entire industry to use Lisp, this would (arguably) be a non-issue, since they allow you to abuse macros relatively easily and add language features (see CLOS or core.async for examples), but Lisp hasn't really taken over the world like I wish it would.

Thanks for your two posts, I agree with pretty much all of what you're saying.

When you look at the millions of man-hours that have gone into the "burn it all down and start from scratch" languages (Go, Rust, etc) and you consider what if those guys had written new compilers for JAVA syntax? How great that would be. They could still accomplish many Go and Rust objectives without having to completely invent their own non-Java-like syntax. Even something that was "Java-like" is better than burning it all down every time something new is needed.

I don't think I agree with your last point; I actually think that the Java syntax isn't particularly great, even for the time. I don't think that Java's idea of object oriented design is ideal (I'm more of a fan of the ObjectiveC/SmallTalk model), and that version of OOP is all Java really contributes from a syntax perspective...otherwise it's largely just C/C++'s syntax.

However, in a sister thread I think you mentioned that you are basically alright with languages targeting the same VM, which I think is probably a better path forward for a majority of use-cases. Clojure and Kotlin and Scala all benefit from being more-or-less fully interoperable with each other; as a result, one can feel free to experiment with language design to their heart's content without too much fragmentation.

That said, I don't know that it's entirely fair to completely criticize Rust on this; Rust exists specifically to address issues with C and C++, languages without garbage collection, and whose design doesn't quite allow the same level of compiler safety and goodness that Rust does, though to be fair Rust does have C FFI so it's not necessarily always reinventing the wheel either. I mean, I agree with the blog post we're chatting on top of; Rust might be super awesome for systems-ey stuff, but for anything TCP-or-higher, I think a managed language is kind of better.

Languages can't be changed substantially once they become popular. Python broke compatibility significantly once and people are still complaining.

My dislike for Java aside, you fail to realise there have been hundreds of programming languages created before Java too.

The same would be true if all the car companies in the world just cooperated on a single car model to rule them all, right?

Oh, you think I'm just pushing for Java. I'm not. I'm saying having one language is better than 100. People can't share code very well if there's so many languages.

Languages themselves don't need to be completely reinvented like things in the real world (cars, etc). For example C/C++ has been around for decades and no one ever said "Burn it all down and start over."

I am a noob and I am happy to be corrected.

Every language is designed with a specific design decisions and tradeoffs intended for hopefully wide audience. I think C and unix culture reflects this in some way. It is home grown environment by handful engineers working initially their own sake. You cannot objectively say, "Everything as file" is good concept, but if you are just handful of people tackling myriad of problems, it should have been liberating to have a too simple of an abstraction. It might be pile of hacks on pile of hacks but, it worked for the time.

Whether it is good or bad, depends on what you want to achieve. I think more communities can benefit from more focus on what they are and how they want to do things than trying to be "be all, do all" thing. I might not want to solve problems the way somebody else would solve the problem and I would use a tool to best fits my way of thinking.

Even if there is only one language, fragmentation is inevitable. Because, all people might not have the same way of working or thinking. Even if it is written in same language, one might not understand idioms of somebody else.

It is easier to read a language with community adopted idioms, than a language that is made for all people. I have been using Java, but the erlang concurrency primitives looks great. But, it would be hell, if single code base has all possible primitives and style.

Asking people to have one language to work is not different from asking people to think in one single way.

Edit: added couple more rants.

I think this one of the important, good reasons. Others range from NIH to runtime considerations to strategic ones.

> Languages themselves don't need to be completely reinvented like things in the real world

Why not? And why things do "in the real world"?

The fact that languages should evolve (and that they do) is not in opposition to a need or desire for new languages.

Dude, we’d writing in COBOL if anyone followed your logic.

And it would still be better than java. :-)

Twenty years I predicted to various peers that Java would become the new COBOL, the lazy enterprise’s default choice of our time, and I’m very sorry to have been proved right.

lol. A generation of script kiddies too lazy to learn Java invented NodeJS, so they could run the toy version of Java on the server side. Then they have the audacity to claim the shoulders of giants upon which they stand should've been strong enough to comprehend JS rather than Java...even though those giants invented BOTH JS and Java before you were even born.

Here's a newsflash for you: if the Netscape inventors of JavaScript had been capable of making Java run in the browser then all you kids would be running Java instead of JS today.

The only reason JS exists at all is because early browsers had limited memory and CPU back in 1990s, so they cobbled something together over a weekend and named it JavaScript. Now that JS is running server side, these kids claim that's the way it should've been from the beginning. No, sorry JS is a train wreck compared to Java, which is why MSFT had to come to the rescue with TypeScript.

Oh, it’s you again.

Yep. "Java is the new COBOL" was simply irresistible. If you want to troll a Java developer, that was absolute perfection.

JavaScript and even modern TypeScript has syntax that is extremely similar to Java, so you can't really say that when I claim Java was already "mostly" everything we needed (WAY before "Go" and "Rust" were invented) that somehow that means I would have therefore said the same about COBOL.

There is such a thing as "finally getting it right". We don't need to replace English with something "new" every couple of years, and writing instructions for machines is the same. The syntax of Java was "almost perfect" and is STILL extremely similar in TS/JS so there was no need to "burn it all down" like Go and Rust did.

Why do you think JavaScript has the word "Java" right in it. lol. Must have been something in there that was good to this very day.

> Why do you think JavaScript has the word "Java" right in it. lol. Must have been something in there that was good to this very day.

Eh, no. From the mouth of Brendan Eich himself [0]:

> InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?

> Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

It was completely down to marketing. I've heard it described as riding the coattails of Java, which Sun was dumping huge amounts of money into marketing to begin with. Allusions to "something in there" notwithstanding.

[0] https://www.infoworld.com/article/2653798/javascript-creator...

As http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m... put it, “Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.”

Eich started work at Netscape Communications Corporation in April 1995. Eich originally joined intending to put Scheme "in the browser", but his Netscape superiors insisted that the language's syntax resemble that of Java. As a result, Eich devised a language that had much of the functionality of Scheme, the object-orientation of Self, and the syntax of Java.

From day one, Eich was told to make it "Java-like". Netscape first tried to get Java itself running in the browser, even before developing JavaScript. JavaScript looks like Java not by accident but on purpose.

If that argument were valid wouldn't it apply to any language? Would Forth be 1000x better if nobody used anything else?

I don't mean Java was perfect from day one and forevermore. I mean it was the language that was perfectly dominant and acceptable at the time, and could've been extended and kept backwards-compatible, rather than restarting new languages from scratch.

JavaScript is particularly hideous, and was cobbled together over a weekend, and because of that misstep the industry got stuck with it and had to invent TypeScript to "fix it" and create something tolerable in the modern world.

> I don't mean Java was perfect from day one and forevermore.

Neither do I. My point was that your comment didn't use any features specific to Java, so if you replaced "Java" with literally any other language you'd have the exact same argument. The details you added here like that it was "perfectly dominant and acceptable" help in that regard (not that I agree with where you're going), but your original comment would have been equally valid with literally any programming language.

> I mean it was the language that was perfectly dominant and acceptable at the time

No. Java never was what you're claiming.

If you don't think Java was ever dominant (and frankly I think it still is), then probably we just disagree about the definition of the word "dominant".

It was a dominant language. But you said "perfectly dominant", which I took to mean "the one dominant language". Java was not that - not overwhelmingly more popular than C++, for instance.

Java was perfectly dominant in it's realm only. Obviously Java is not competing in the realm of machine code generation at all, and assembly language should always exist too.

C/C++ is the perfect example of a language lasting multiple decades without each new generation trying to throw it all out and start from scratch, but simply evolving it.

Sounds like you think you know best, too.

No, Java would not be the "only" language in any set of circumstances, however fictional. No language will be, ever, because no language is better than all other languages at everything.

Go is to backend what React is to Frontend and what Kubernetes is to infra.

Everyone wants to have fun.

And when things get complicated enough just switch jobs.