Also, IntelliJ runs on Java, for all the bashing that Java gets on HN, it’s an example of how “what technology you pick is less important than your focus on user experience”. It’s amazing that their products are so performant on Java
It's got a few bells and whistles, although I can't think of a single one that wasn't stolen syntax and all from C# at least two years after the fact, except for the aforementioned modules. But 'var' is the only thing I can think of that's actually improved the Java experience since lambdas. They've committed to a six month rolling release cycle without actually having anything to put in the releases.
That said, Java devs think C# is slow, C# devs think Java is slow, and people who are neither think both are slow. It is no longer 1995 where bytecode is interpreted; the slowdown relative to C++ is 2.5x-3x for both. Any leftover 'slow' opinions are bordering on superstition at this point.
Java just moves a lot slower, and has a different philosophy for adding features, and the core team seems averse to introducing new forms. An example I ran into the other day is applying first-class functions in Java: in C#, this looks like
lambda(arg1, arg2)
lambda.apply(arg1, arg2)
It's hard to appreciate how addictive the sugar is if you never had it.
Frankly, language level auto properties -alone- would get rid of 25-33% of the pain I feel writing Java.
Of course, there is always Scala on the JVM Side; which gives you all sorts of sugar, but in some ways -too much-.
I've never used Scala but it seems to go much further in the syntactic sugar and semantic complexity direction, more akin to F# than C# (though with less elegant syntax, to my eye).
Also, auto-properties are binary compatible with computed properties, whereas public fields aren't, and you can use 'ref' on a public field whereas you can't make a ref to a property.
public int Foo { get; set; }
public int Bar;
You might also look at the JDK flight recorder, which is an amazing feature that .NET doesn't have. The Java perspective is adding complexity to the runtime fiest instead of the language.
There have been many useful improvements between Java 8 (the lambda release) and Java 11, I haven't looked beyond 11 as I haven't worked in Java in over a year and that was the last version I wrote code with. I don't even consider var to be that useful of an improvement, the biggest pains of lack of type inference were solved in the Java 7 era with the diamond operator which eliminated the need to specify often times deep nested generic arguments on both sides. Now var was basically a bikeshed problem. Between 8 and 11, they improved Strings under the hood to move away from being backed by char arrays. This has huge implications on web services and data processing apps in reducing the memory foot print as most of them wrangle a large amount of json. Also they added an HttpClient to standard library somewhere between 8 and 11 greatly eliminating the need to depend on 3rd parties. They also added the FlightRecorder (although I haven't had a chance to personally use it yet) which improves the the instrumentation story. Not every release is going to have sexy language features but they do contain improvements with direct impact on production software- the String class compaction improvement is the best example, it is not sexy, I doubt it even had a thread on HN but in the real world it measurably improved the performance profile of a large category of applications for free. Release cycles are just numbers, most people in the real world are not keeping up with latest release and instead opting to upgrade to just the LTS releases which are on a much slower cadence of 3-4 year cycles.
I hate to be that guy but 1) java does not go neck to neck with c++ unless you mean it can be in the same order of magnitude and 2) C++ is not slower than C or Go or Rust
Note: by c++ I mean c++ compiled by a decent compiler e.g. gcc/clang/msvc
I don't know why, but I got a good laugh from that statement. Those "kids" are all the same age or older than Java; PHP, Ruby, and Java were introduced within a few months of each other in 95 and Python dates back to 91.
I would seriously contest the speed of Java compared to modern PHP. The JIT puts PHP at near-C performance levels with competently written code. Which shouldn't be surprising if you realize PHP is largely a "wrapper" around C.
Vertx framework which is based on Java is at 8th position and PHP is 18th.
But the larger point is performance is only one aspect while considering which programming lang. or framework to use
From the page above The bottomline: PHP 8 is still slower than PHP 7.
This is a realistic comparison of running Magento on php7 vs php8.
In Java you will have to deal with an array with a million pointers to a million objects and in C++ you will deal with a sequential segment of memory that is a million times the size of your object - and mostly in your CPUs cache. That alone will be much, much faster.
But you can't do that in Java at all.
When you want, for example, an array of (float x, float y) “objects” in Java, you just keep them as two arrays (float[] x, float[] y) — and I guarantee it will use the same amount of memory and will have nearly the same speed as C++ (depends on what cache locality you need for a specific task, it might even be faster to have two separate arrays for some tasks).
So yeah, depending on the language, a slightly different implementation is more efficient, so one has to know its tools.
Also, as far as I know, when project Valhalla extension goes live, you will have an option to do packed structs the same way as C++ or C# does.
Edit: Oops, there was another reply about the same in the thread. I should remember to refresh the threads before answering in the morning.
And if you are doing something like nearest cluster mapping, or anything else where you process your data in linear order you are not going to get the optimized cache locality. Plus you can't read the file with mmap if your data is from there.
I would go further and say that if your job is analyzing terabytes of memory-mapped binary files, maybe C++ is not optimal either, and investing in specialized languages like Shakti/K would pay off quickly.
yet every time I try a Jetbrains IDE every action seems to take 10x the time to be processed than it takes in QtCreator
The main issues people assume with Java are that it has slow runtime and it's verbose.
But the JVM is actually rather fast. Especially compared to JavaScript and Python, which aren't even compiled (and which I still agree with the "it's crap" hivemind). Anything that needs real performance you should be outsourcing to C/C++ FFI calls, and as long as you do that your Java app's performance should be OK. And a key cause of Java's big slowdown are checks e.g. for null-pointers and casts, which are much better than C++/Rust's approach of being unsafe-by-default.
Java is verbose, but JetBrain's awesome IDE single-handedly fixes this problem - writing POJOs and using long-named functions and classes is fast, and IntelliJ will hide excess boilerplate so that even reading code is easier. And if verbosity is still too much of an issue, there are JVM alternatives like Kotlin.
Nitpick: Rust is safer than Java by default. You can't ever dereference a null pointer (only raw pointers can be null, not references) or make a cast without dipping into unsafe code.
It's a total memory hog though.
A billion dollars is a ludicrous sum of money. No one on the face of the earth deserves that level wealth.
If you ever seen an actual billion dollar product or even a product hundreds of millions of dollars (in cost, not revenue generation) it is always built by hundreds of people. Your physical two hands, strength and intelligence limits you to a lifetime gdp output of well less than 1 billion. Therefore whenever you see a billionaire, the billionaire achieved his wealth off the backs of others.
A more fair distribution of wealth for jetbrains is one where the wealth is more evenly distributed among everyone who works at the company. There is a term for this... it's called communism/socialism and it has a set of downsides but I don't want to walk to far down that road.
Suffice to say capitalism works, but it works because it's not fair. No billionaire ever deserves to be a billionaire because he simply does not have the physical or mental ability to produce that much wealth. It always must be taken from the hard work of others.
People are the same -- just another kind of resource, a black box that lets you make $5x. And the thing is, you deserve the $5x -- you took a system where nothing was being put to its best use, and now it is.
What I'm trying to say is I've worked on many projects that sucked because no one had the vision and hiring skills the IntelliJ people do, and if society could give someone a billion dollars to make every project work that well, it would be a good deal.