I'd have loved to, but because of its nature as a live game show with cash prizes, it required that the user signs up with their phone number, as a way to make botting and multi-account a bit harder. I know that wouldn't go over well with the audience here.
The game is no more, but maybe I could put together a little post talking about the more interesting problems I had to tackle, and showing the animations I am the most proud of. Maybe some day!
I was discussing this with a colleague; Java is supposed to be some of the most performant runtimes and yet, every time when someone introduces anything in Java, literally everyone tech in the company goes 'aw shit no Java please'. You can show me a running top processlist without the names of the processes and i'll point out the Java processes to you. And it seems that companies can make viable businesses around porting to Rust/Go/C++ of (Apache) Java projects because they are so resource intensive and slow (unless you spin up 10000 nodes). Why is anyone using it still outside legacy?
Not sure if correct, but I'll tell you my point of view.
Many people nowadays are programming not in Java, but in Spring. And it is slow, resource intensive and in the long term - development speed is badly affected too. You have simple tutorial service? Easy. You have real business case and want to do something a little bit skewed from "the best way" - you are screwed, in the debugger, deep into Spring code, praying to find workaround.
JVM is fast, but raw Java is not seen so often in corpo-rat world. And if for single endpoint getting data from database and encoding to JSON you have to schedule 2 cores and 4G of RAM for every few hundred QPS - something is wrong.
> The ecosystem of Java is so huge. Most people who use Java barely have any idea what the rest of the software industry is doing.
I think herein lies the problem. The Java enterprise software (usually spring) world and the everything else under the sun world are very separate. Java devs usually have minimal visibility of other ecosystems and their patterns, and are very reliant on extremely mature (and heavy) tooling that other languages don't tend to use. Other devs hate how bloated the Java ecosystem feels, and that they can't use any of their usual tools. Neither tends to understand that their approach isn't the only way.
Even inside Java, projects like quarkus don’t receive fast adoption because Spring is the “professional” way to work.
Spring developer experience is awful, I miss hot reload.
> Most people who use Java barely have any idea what the rest of the software industry is doing.
Not sure this is really true any more, but it definitely brings back memories from when I was learning OO programming (let's say, a couple decades ago, pre-github).
At the time, it seemed to be an industry-wide assumption that "software engineering" is exclusively done in Java. Every learning resource I could find at the time was deep, deep into inheritance and OO design patterns. Things seem better these days!
Well, give me a real world software example (so not a hello world thing) I can download and test and compare. I have dev & devops experience with Java, so let's take something that's used a lot; Zookeeper; Clickhouse ported it to C++ for a reason; the original sucks resources, CH Keeper you don't even notice. Maybe you will say it's written badly, but if a Apache posterchild is written badly, what does that say? Same for Apache Cassandra; even starting it for dev is a crime, let alone use it unless you have many nodes. Scylla, the C++ implementation, runs circles around a cluster of it on one box. But again, you might say it was badly done. ElasticSearch... Best not mentioned as it's a very well known resource hog vs native implementations search engines. As others said; anything Apache Spring for any real life application.
So what's a good example so I can compare it to a non Java version?
Just starting up the trivial Spring application I work on takes multiple seconds. Firing up other services for an integration test can take 30+ seconds. It's ridiculous.
The latency makes integration testing unnecessarily tedious. Don't even get me started on Maven -- dev tooling has to reimplement the build system rather than invoking it because the performance is so poor.
Is it actually, in practical applications? Just firing up the JVM can take seconds, while Go is often used for CLI programs that only run for milliseconds.
Can you how me some evidence that Java uses 3x the memory? Sure OO heap spam with Java is certainty possible, but the same code written the same way in both languages wont have that much memory difference.
That just notes the max amount of memory used, but not the actual memory it needs. If Java has memory available it makes sense that it uses it instead of spending time cleaning up unused objects.
In addition I have a feeling that these benchmarks are comparing short lived processes. Java does take a bit longer than some other languages to start unless you use native. But that doesn't matter much when you are running long lived services.
> You can show me a running top process list without the names of the processes and I'll point out the Java processes to you.
This was quite eye opening when thinking about this, I am aware of how underappreciated the performance of JVM is, but I never thought about how widely deployed it is
The contrast ratio of an old CRT (and amber and green were considered more comfortable than white-on-black) is radically different from a modern LCD/IPS/OLED screen. It's so different that there's no comparison. Dark mode might be ok for more people if there is some brightness to the background instead of being completely black, but then you lose most of the benefits of OLED.
The "true black" OLED displays have their part of the display off where there are black pixels, if I am not wrong. So, wouldn't dark mode suit well for those types of displays?
GP is arguing that exactly because there is no backlight, the contrast between on/off is uncomfortably high on modern screens compared to the CRTs where Windows 2/3 was running.
I agree. Most websites with a dark color scheme use a dark grey background and even off-white text.
It's very possible that they did, it's very feasible and to some degree a simple matter. However, I still believe that it's more likely that the US did than that the Ukrainians did. My initial assumption, right after it happened was Ukrainians or the US, but I have always leaned to that the US is more likely, and there's at lot of reasons for that.
However, I mostly think you did it because you said you would, and I kind of trust you when you do things like that. When your leaders try to communicate their intentions, they usually mean what they say and it's not terribly complicated.
The US talk about agreement with the EU view that this is somehow a brazen and dangerous sabotage is pretty funny though, because this kind of thing is absolutely legal-- completely, not like 'Oh, this is disputable', but completely. The useless German arrest warrant that was issued was funny too. Neither of these two mean anything, but I get the impression that everybody knows it's legal and wish it weren't. They know that the Armenians can blow up Turkstream and the Georgian pipelines, even with the slightest provocation, since there's no ceasefire agreement and all their big investments can be destroyed in an instant with unhappy Brits as a likely result.
You don't even need an order. If your country is occupied by another country or at war, and you can damage infrastructure useful for the enemy war effort, whether in export of energy or the electrical grid or anything like that, you don't need an order, you should just do it. Attacks on things in international waters is obviously permitted. If it belongs the enemy and you can attack it, you probably should. It's more complicated if it's in a neutral country, and then it might actually be illegal, but otherwise-- do the work and put on some distinctive marking for the attack itself, and there's nothing to complain about.
It's something that anyone who has lived in a smaller country with a neighbour that could possibly make war upon them drills into their own heads when they first read their grandparent's old 1950s military manuals.
Of course, if the US really did warn, then it may be as you say-- after all, why warn of what one would oneself plan to do, but people can be tricky, so there isn't a guarantee there either, especially if the explosives are pre-planted.
I'm reminded of the weird US accusations against Russia right after the event though, now that I read the article again, and that's another reason to suspect the US. Imagine that you're in an Agatha Christie novel and somebody says stupid things to you. There's only one conclusion-- he wants you to think stupid things. The article also contains some of this kind of stupid about 1/3 in and it's right when it starts discussing this kind of thing, so, no it's 100% the US. You don't talk like this, or reason like this, unless you did it. It even has one of those 'how did you know the parts you weren't there for' problems.
We agree on the cause, but not the solution described in your last paragraph.
If it was truly a free market, the federal government wouldn't be involved at all and I could buy insurance from any company in any state. It's because of the government's involvement that I can't buy insurance of my choice and preferred pricing from any insurer in any state.
As you'd find if you drove a motorcycle fast enough in the rain, a motorcycle with
a fairing and windshield will sweep the rain (or dust) over and past you and you only get wet when you stop at a light. Perhaps that's the case here as well.
