maybe it would be a little better to use ints rather than longs, as Java lists can't be bigger than the int max value anyways. Saves you a cache line or two.
Fair point, but it is possible this isn't a list but rather some sort of iterable. Those can be boundless.
Practically speaking, that would be pretty unusual. I don't think I've ever seen that sort of construct in my day to day coding (which could realistically have more than 1B elements).
public int parseOrDefault(String value, int defaultValue) {
if (value == null || value.isBlank()) return defaultValue;
for (int i = 0; i < value.length(); i++) {
char c = value.charAt(i);
if (i == 0 && c == '-') continue;
if (!Character.isDigit(c)) return defaultValue;
}
return Integer.parseInt(value);
}
Is probably worse than Integer.parseInt alone, since it can still throw NumberFormatExceptions for values that overflow (which is no longer handled!). Would maybe fix that. Unfortunately this is a major flaw in the Java standard library; parsing numbers shouldn't throw expensive exceptions.
Good catches from several of you. The original fix dropped the try-catch entirely which was a regression for overflow and edge cases like a bare "-". Updated the post to keep a try-catch around the final parseInt as a safety net. The pre-validation still avoids the expensive path for the common cases, which is the core point. Appreciate the feedback.
Unfortunately, Wikipedia doesn't seem interested in this. Their revenue is more than enough be able to invest and sustain the site forever, but they just increase expenses on non-core outgoings https://en.wikipedia.org/wiki/WP:CANCER
Am I misssing something or is Wikipedia net positive 200M? If this is true, that's eye opening. Weird given how much they beg for money on every article.
The amount of money moving through Wikipedia is absolutely mind blowing, and next to none of that is even being used to sustain the site. Hope those still donating to it feel smart about what they're supporting...
Because that's how you build up a foundation that will be self-sustaining when the donations run out.
It's not a bad strategy. I've looked at Wikimedia's financial statements and have no problem giving a small monthly amount to them considering how much value I get from the site.
I certainly prefer my money going to them than to Zuckerberg or Altman or MSFT shareholders.
You pay for Wikipedia because you want it to prosper. The political part of Wikipedia is vital to make it succeed. Even though everyone uses Wikipedia not everyone knows why it succeeded and why it is important.
The fluff is important to have a engaged super users. It is also important to get acceptance in certain circles.
Yes, last time I checked, Zig's comptime was 20x slower than interpreted Python. Parsing a non-trivial JSON file at comptime is excrutiatingly slow and can take minutes.
I would argue that it's not meaningful to do so for larger files with comptime as there doesn't seem to be a need for parsing JSON like the target platform would (comptime emulates it) - I expect it to be independent. You're also not supposed to do I/O using comptime, and @embedFile kind of falls under that. I suppose it would be better to write a build.zig for this particularly use case, which I think would then also be able to run fast native code?
You’ve got a monopoly on lemonade because you pay all the grocery stores to be the default lemonade.
So we’re going to force you sell your car.
I don't think this is an accurate anaology. It's more like, you own the vast majority of grocery stores, and you make lemonade, and you force all the other grocery stores to only sell your lemonade.
To put it another way, the problem is not so much that Google shouldn't be paying to be the default search engine, but that it shouldn't own both the browser and the search engine.
I think this harkens back to the anti-trust court case, United States v. Paramount Pictures, where the court ruled that the film studios cannot hold monopolies over the movie theatres, and that theatres must remain independent.
Similarly, browsers and search engines being independent is good for competition because the internet is too important to let a single company dictate how it is used.
> To put it another way, the problem is not so much that Google shouldn't be paying to be the default search engine, but that it shouldn't own both the browser and the search engine.
If this is the real crux of the case, then is divesting Chrome going to negatively affect DuckDuckGo and Kagi?
My hunch is “no”, and also that search+browser isn’t the crux of the case. I think the real crux is Google owning browser+ad/surveillance-network.
It's the scale. You can do all kinds of integrations at tiny scale that are not permissible at grand scale. I can own my store and sell my own-brand products in it but if I own most of the stores and use that leverage to force other stores to sell my own-brand products, that's a concern for competition and an opportunity for anti-trust regulation to step in and attempt to fix things.
> I don't think this is an accurate anaology. It's more like, you own the vast majority of grocery stores, and you make lemonade, and you force all the other grocery stores to only sell your lemonade.
Yep. The rest of the article is equally disingenuous, desperately making up arguments and bad analogies.
Using notifyAll and wait in Java is tricky to do correctly, you'd have a much easier chance using concurrency primitives that wrap these functions, like CountDownLatch[1] for one offs, or Condition[2].
System.currentTimeMillis is also not guaranteed to be monotonic, and System.nanoTime should be used instead. This would of course be obviated if a better concurrency primitive were to be used.
Getting OT here, but I've tended to prefer Gnome apps with a KDE desktop. The latest UI pessimizations in Gnome may having me switch completely away from Gnome, with the "You must click on sub menus to open them" being the final straw.
I concur, KDE applications tend to be more traditional. I don't mean necessarily in style, I think they can look quite good, but rather in form. Personally, I think Desktop software UX peaked maybe 10 years ago so to me this is a good thing. Assuming a typical experience of mouse, full-size keyboard, and monitor. Things do change UX wise when you switch to a laptop IMO.
Thanks. I actually managed to run the quick example with Temurin Java 22. Maybe that is what they mean by "OpenJDK": java.vm.name=OpenJDK 64-Bit Server VM, java.vendor.version=Temurin-22.0.2+9
reply