"no harm to them"
No harm, perhaps, but likely considerable expense (in time and labor, which are not free).
Still, doing so is a public good, and I support the idea when feasible.
2,045 karma · joined August 14, 2007
No harm, perhaps, but likely considerable expense (in time and labor, which are not free).
Still, doing so is a public good, and I support the idea when feasible.
Really? That's the opposite of my impression. It seems to me that they promote it as co-equal to C# as primary focus in their constellation of supported and encouraged application programming languages.
But yes, when distribution networks are stressed, bigger players will obviously have more pull and smaller businesses will have more trouble getting in what they need and/or delivering their products, at anything beyond a very local scale.
And because their designs make windowed use problematic (both because of the title bar issues, and because space is used poorly in the name of "clean design"), they encourage even full screen use.
Add to that the fact that more than a few applications default to full screen at first run, and ...
This is why we can't have nice things.
Partly C19 related, but I was moving away from them in the before-times, as well.
Oracle chooses to build with only ZGC enabled.
How is continuing development not "support"?
Also, even in unsafe code, Rust offers more guarantees than many (most?) languages.
Some of the blame for that probably lies with his headline choice, but he clearly states at the end of this post:
""" This is not the best that Java can do: Java can ingest data much faster. However, my results suggest that on modern systems, Java file parsing might be frequently processor-bound, as opposed to system bound. That is, you can buy much better disks and network cards, and your system won’t go any faster. Unless, of course, you have really good Java engineers.
Many firms probably just throw more hardware at the problem. """
It's not about this piece of code. It's not even about Java In the previous post he mentions at the start of this one, he pointed out:
""" These results suggest that reading a text file in C++ could be CPU bound in that sense that buying an even faster disk would not speed up your single-threaded throughput. """
So, I take his point to be that one shouldn't make assumptions about performance. Rough performance scales -- such as have been posted here many times (e.g. [1]) -- make great rules of thumb for implementation choices or as a guide for where to look first for bottlenecks. To optimize in the real world, though, you're best served using real measurements.
[1] https://www.prowesscorp.com/computer-latency-at-a-human-scal...
As someone who runs Windows and Linux about equally, in differing proportions over time, I do find it disappointing that some (b)leading edge JVM and Java features don't support Windows yet.
Oracle has open sourced (or deprecated and removed) the remaining commercial elements in the JDK -- OpenJDK now is truly the complete open reference implementation of the JDK, JRE, and JVM.
Back in the day, many better mail order catalogs cost money to receive. Mostly to offset the cost of mailing them out, but partially as a form of filter, on the theory that someone sufficiently interested in a catalog to pay to get it would be more likely to actually order something.
Also, regarding "pull not push", people sometimes don't know there is a solution to their "problem" (where "problem" might not be a real problem, per se, but maybe simply not even knowing that a given option exists).
Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance).
On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.
What about Eclipse?
Love it or loathe it, it's certainly been successful.
" can allow for remote code execution provided that the application is using a vulnerable version of Electron (version < 1.7.13, < 1.8.4, or < 2.0.0-beta.3) , and hasn't manually opted into one of the following:
* Declared webviewTag: false in its webPreferences.
* Enabled the nativeWindowOption option in its webPreferences.
* Intercepting new-window events and overriding event.newGuest without using the supplied options tag. "
AOT Java compilers certainly exist, but I don't recall Microsoft having one -- I fully admit my recollection of their Java dev environment is quite foggy at this point, though.
Regardless, the Java AOT compilers I've tried didn't seem particularly fast in relation to their level of optimization.
Admittedly I didn't start with Pascal, but rather with BASIC and several assembly languages (1802, Z80, & 6809 were among the first I used). I learned Pascal after C, actually. I like things about both, but often wish that Wirthian languages would have won out.
FWIW, these days I primarily use Java, C, C++ (when I must), and a smattering of other languages, with libraries and such chosen to match the problem at hand and the environment in which it must be solved.