Many organizations are stuck on Java 8 because Java 9 made breaking changes. (Java 11 also made breaking changes.) Many of these changes also broke some popular libraries at the time that hacked into the JDK internals, so it meant a significant refactor for software that might be in maintenance mode already.
To clarify Java made changes to things they never promised would be a part of backward compatibility. Libraries were using things from JDK internals/implementation details, things that were never guaranteed to be there.
It isn't that severe of a break. Most of the friction was with the libraries with transitive dependencies, like ASM, that depend on a particular bytecode version, using internal classes that were removed (e.g. sun.misc.BASE64Encoder), or the new module system encapsulating APIs that were intended to be internal-only (usually fixable with JVM runtime flags.)
A lot of organizations that use Java are very conservative with their tech changes, and didn't see a compelling reason to upgrade. This was especially true since Android Java still used Java 8, so many popular libraries continued to support Java 8 for their Android userbase.
Java's version history crawled along at a snail's pace until Java 10, when they switched from a feature-based to a time-based release schedule. The release cycle has been pretty quick after that, since that happened only after 2017 or so.
That, combined with some pretty large changes in the underlying security model, mean that a lot of places have been stuck on Java 8 for a real long time. It's much harder to move from Java 8 to Java 9/10/11 in a lot of places than it is to then go from 9/10/11 to 17, for multiple overlapping tech debt cleanup reasons.
On another note, I dislike how “Zero-Knowledge Proofs” are called proofs. It’s not a proof. You iteratively increase your belief that the result is true, like in experimentation, but that’s not a proof.
If someone has signed something cryptographically, wouldn't you say that the signature was a proof of someone with the private key signing it? (Even though it is possible to construct a valid signature without the private key - you just have to be very very very lucky)
I guess you also don't like the name Proof of Work.
It might help to think of the sense of "proof" that's synonymous with "trial", rather than a specific formal math sense of proving a theorem from axioms by formal transformations.
zero knowledge corroboration isn't the same thing as a zero knowledge proof. If the provided evidence isn't enough, then you keep iterating until it's proven.
COP or CoP means co-efficient of performance. An electric heater has a CoP of 1. New heat pumps usually have a CoP of 4 or higher. My 11 year old heat pumps have a CoP of 3. This means they can produce 3 or 4 times as much heat as an electric heater, assuming the same amount of electricity, or produce the same amount of heat with 1/3 or 1/4 of the electricity.
At a CoP of 3, they are more efficient than electric heaters down to -15C. At a CoP of 4, down to -25C. There are better heat pumps coming with a CoP of 5.
I’m sure it’s down to use case and circumstances but I frequently find it useful to be able to read and edit text based data formats (JSON/YAML/TOML). If you are concerned about data size you can easily use on-the-fly compression at little cost nowadays.
JSON can be translated into a structure of arrays, maps and primitive types.
It can be traversed with functional programming.
That matches 100% the skillset/mindset of developpers.
Whereas XML has too many quirks and tricks, that it requires a dedicated API [aka DOM API] that you must learn and master.
XPath is the tool of choice for XML traversal. VERY versatile and super readable, but it cannot beat the ultimate flexibility of the functional programming.
JSON is basically a subset of JavaScript. Parsing XML sucks, everyone rolled their own RSS and it was basically a nightmare having to deal with invalid XML. JSON has always been really strict and simple. If JavaScript in a browser couldn't parse it it just didn't work. libxml was also a nightmare, XSLT pages looked terrible and honestly there where just a lot of bad XML ideas out there despite gems like SVG. SOAP was horrible, and still is for people having to interface with a SOAP API like Netsuite.
But what was really the end of XML was the end of XHMTL and the HTML5 working group that said they weren't going to do XML HTML and it was funded by Google's large sums of money and involved talented people work at a hot new browser called Firefox and the web dev community went their way and everyone followed.
I don't know exactly when, but I think it had a lot to do with the fact that in 2004, Python, Ruby, and yes JavaScript were all fairly niche.
(This might be hard to believe for some, but it's true. GMail had just come out, and it was one of the first web APPS in JavaScript, certainly the first really good one. Paul Graham wrote "the Python paradox" https://paulgraham.com/pypar.html , and Ruby on Rails didn't exist yet.)
JSON maps well to core data structures of Python, Ruby, and (obviously) JavaScript, but XML doesn't.
XML seemed to be associated with Java. There was a lot more ceremony around the APIs. You didn't just manipulate data; you had to create classes and call methods.
So basically neither JSON nor XML are really convenient in Java. But JSON is very convenient in the dynamic languages. You don't need extra abstractions / layers / code generators -- it's just "there".
I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages.
I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...
We’d all been burned on enterprisey balls of mud like XMLRPC and then SOAP. When JSON-over-HTTP came along, it was a breath of fresh air. Look, it’s readable! It’s easy to parse! It’s trivial to generate! It only had like 5% of XML’s features, but that was the point. Mere humans could read it and there was no temptation to stick something in an attribute instead of a value.
Seriously, it was revelatory.
Edit: Also, lots of common computer interactions — I’d go so far as to say most of them — are only passing around a few values in a simple data structure. JSON’s good for that. I wouldn’t want to necessarily use JSON to represent an office document, but that’s not what I want to use it for. “Hey API server, give me information about song 1234.” “OK, that’s ’Hotel California’ by The Eagles.” You can definitely describe both question and answer with XML, complete with schemas and all, but does that get you anything over {“name”:”Hotel California”,…}? Not really.
Consider how much you can accomplish with POSIX, and it doesn’t even have named arguments. There are times when XML’s complexity is a benefit (I guess; I’ve never seen one but I don’t doubt they exist). Most of the time, it’s just overhead for the sake of overhead.
I think the reason that JSON won was that at least on the client-side, it was much easier to turn the response data into a Javascript object to interact with then XML.
+1 to this podcast, it sheds a ton of light on exactly how we ended up with JSON taking the wheel. Listened to it on a flight from Stockholm back to Helsinki and arrived a marginally better programmer as a result of it.
When I was writing an xbrl-to-json library I suddenly realized that they are not perfectly transferable.
XML comes from spreadsheets, and so it was the first mover. Whereas json came from key-value pairs. I think key-value pairs are much easier to picture in your mind, and for the vast majority of work people are doing, it's just simpler.
I think XML is wildly complicated for simply APIs.
My experience is a bit different.
I use Chameleon+xmldict to generate dozen of different JSON formats, my input being a XML template plus Chameleon templating instructions. And I have found that JSON can be 100% percent expressed from XML.
several things helped to damage XML as the format of choice.
1. mismanagement by w3c of associated standards:
The awful bloated XML Schema spec that can't even validate many types of common XML design patterns, obviously as shown by Schematron it would be better if they had leveraged XPath in making the validation format they pushed on everyone and made people think wow, XML is this big complicated bloated beast, we need something else.
The awful bloated SOAP spec which Don Box once said if only XML schema had existed we wouldn't have had to make SOAP - let me tell you that was the best darn laugh I had in that year! Which of course with the whole Rest movement - very loosely based on a member of the W3C's PhD dissertation - and W3C committed to SOAP that everyone resented it made everyone resent the W3C and XML in turn.
The tying of second versions of successful standards in to the questionable XML Schema spec made members of communities using these successful technologies - XSL-T, XPath - feel that maybe they weren't enjoying the new versions of the tech so much, there was some drop-off and complaints.
The creation of XHTML as an XML dialect did not suit very many people.
2. Continued increase of the Web as platform of choice.
The successful XML technologies were not well suited to making web sites that were not document based. If your site was say a thin navigation structure to allow you to get around a bunch of documents a top level programming language to handle serving documents, transforming documents to XHTML with XSLT, and then a thin layer of JavaScript on top was quite a decent solution.
But XSLT is not really suitable to making all sorts of sites with lots of different data sources being pulled in to build a frontend. So when you have a lot of languages in use what do you do? You drop the language that is least suited to most of your tasks and use some of the other languages to take care of the dropped functionality, thus easing cognitive load.
I'm serious about this, I was very good with XSLT and associated technologies and built many high quality document based websites for large organization, but the XML stack of technologies is sub-par for building most modern websites that often contain multiple app-like functionalities on every page.
I suppose that the programmers and technologists at the W3C did not realize this because they did not build websites, they were more Enterprise applications, data pipelines and many coming from the publishing world.
3. JSON was being pushed by Douglas Crockford. As the E programming language was shutting down https://www.crockford.com/ec/etut.html he started to focus more of his time on JavaScript and arguing for JSON which essentially he identified as existing as a potential data interchange format. As REST started to take away from SOAP and JSON got pushed by someone who did understand web programming the increasing web focused software development environment moved away from SOAP and XML which were seen as being essentially the same to REST and JSON (or really REST-like and JSON-like) because these were seen as being simpler and quicker to iterate with - which is essentially correct.
On the Web, especially web frontend simple wins because frontend development is in many ways more complicated than other forms of development - why so? Because a frontend developer potentially has to handle very many more types of complexity than are generally handled in other programming disciplines - this often leads Frontend developers to cut corners that other disciplines wouldn't so as to cut cognitive load but here I'm definitely getting off the subject - at any rate for the expanding web market XML and its related technologies were a bundle of complexity that could be replaced with a simpler stack, even if it meant that some of the things that stack was good at might be made slightly harder it seemed and probably nearly always was still a significant win.
Doesn't need to: You want into the EU market? EU demands this for the whole world. The EU can set any requirement it wants for market access. Such is the power of governments. And since someone will state that then other countries can do the same: Correct. And then companies will have to decide if the market in question is big enough to play by those rules.
> EU can set any requirement it wants for market access
One, as long as it’s a land with the rule of law, it can’t. Two, this would constitute starting a trade war over…browser engines. Good luck getting people who depend on popular votes to back you up on that.
No, the EU cannot dictate what companies do in other countries. They can only require them to meet standards for services and products that are sold in the EU (or maybe if the companies are headquartered in EU).
They can. Every country can.
And they do in other cases - USA is perfectly Ok to sanction Chinese/UAE bank for doing business with Russian military.
If it's ok to it with sanctions - why it's not ok to do it for market access?
Yes, this could create situation where things EU requires worldwide are in direct conflict with other countries but it's rather unlikely to happen.
You're being really obtuse, aren't you. The EU can say "If you do not implement that functionality on all iPhones world-wide, then you are not allowed to sell any iPhone at all in the EU".
And to the point of the discussion, there are no "limits" to what jurisdiction governments have. Governments--the United States especially but many others--does it all the time, especially as concerns financial matters. Many countries have declared that they have jurisdiction over crimes against humanity committed any time, anywhere, by anyone. China has penalized American companies for activities involving Americans in America.
However the EU probably has self-imposed limits (or imposed by the member states) and as a practical matter only large or powerful states can get away with it.
Mergers are a different thing, though. In this case, it also impacts the EU - and you can't just say we won't merge in the EU but will merge in the US, doesn't make sense.
A more analogues example would be e.g. if the EU would have said "Hey Adobe, if you launch this feature in the US, you can't do business in the EU".
> China has penalized American companies for activities involving Americans in America.
What are you referring to?
> Many countries have declared that they have jurisdiction over crimes against humanity committed any time, anywhere, by anyone.
This is a whole different topic, stop moving the goal posts.
mergers are different thing as the outcome, but the mechanism is the same> two companies based in US could not merge because EU said so. The fact that the outcome of the merge vs outcome of some implemented features are different are just details that are not relevant for this discussion. EU absolutely can impose it's will on foreign companies and if those want to be present in EU market, they'll follow the rules
Because two US companies merging has also a big impact on the EU market. A US company launching a feature in the US but not in the EU has no impact on the EU market. So no, it's not the same thing.
yes, as I said not the same thing as effect on eu market, but the final effect is the same: EU has the power to block a merger of two us companies at it's will even if for us govt the merger is totally ok and eu can bend this power in any direction including forcing a foreign company to implement a global policy
Nor do the US, but most legal impositions (no accounts under 13 years, dmca, etc) get replicated around the world because services want to work in the US market.
I kind of see the EU legislation similar to California. After CA passes laws, eventually, the other states do as well. I'd imagine that the EU hopes that their legislation will influence others at some point too.
What CA laws do the other (presumably most or all) states pass?
Some CA laws only have an effect outside California because the state has so many people (with money). So if you are designing a physical product to sell, it is cheaper to just make one that complies with California.
Exactly, with automobiles being the most obvious. At one point, if you bought a car outside of CA, you might have needed to make physical modifications to it before it could be registered in CA with the catalytic converter being an example that jumps to mind. Eventually, all of the other states required them as well, and the auto manufacturers just made all of there cars compatible with the CA reqs anyways.
There are non-physical product laws as well. CA was a leader on medicinal cannabis, minimum wage, etc
What happens when markets have opposing requirements?
Ex: China, Russia, KSA, EU? No, they cannot dictate rules world-wide. Each market can dictate market requirements but they can't have them imposed in other jurisdictions they have no control over.
Then the company in question will have to decide which market is more important to them and follow the rules of that market, while not being present on the other.
Others have already noted the risk of a trade war following from that, but that doesn't preclude the EU/US/China/.. from still doing it. It's just a matter of how important they think the rule is.
> Because it hurts EU customers by not applying the rules worldwide.
It’s an entirely expected outcome for wanting to enact one-of-a-kind laws that force a foreign company into doing something they’ve obviously wanted to avoid.
If Apple maintains that it will only support new web engines in the EU, the EU will step in and force Apple to allow it worldwide. So it's a losing battle for them.
Well, telling is easy. You just tell them. What you're really wondering about is how they would compel Apple to do it, not just tell.
If this were found to be a violation of DMA, they could fine them for absurd amounts of money. If Apple paid the fines but didn't fix the underlying issue, they'd be fined even more. After suffient repeat offenses the EU would force Apple to make structural changes such as break up their businesses. If Apple chose to not pay the fines, break up, etc, they would need to stop operating in the EU, or run the risks of their assets being seized, their employees arrested, etc.
It's only at the point where Apple left the EU that there's no more leverage on them. And this is Apple, they're not going to leave a market with money. They didn't even leave China.
(But the real key question is whether there's a reasonable interpretation of the DMA where the companies need to comply even outside of the EU.)
Not sure what you're thinking it'd achieve. Apple already has a subsidiary like that[0]. And sure, that subsidiary is the only part that the EU can directly act on.
But the EU can definitely take into account the entirety of Apple when deciding what to do. For example, when Apple gets fined for violating the DMA, the maximum penalties are going to be based on their global revenue, not just the EU revenue going through their Irish subsidiary.
If you're proposing a fully independent public company rather than a subsidiary of Apple, it's true that the separate company wouldn't actually be able to fix any of their possible DMA violations. But that just means they'd not be complying, not that they wouldn't be breaking the law or that they're somehow immune.
How will that entity continue operating in the EU when its only business is selling devices that are infringing on EU laws, and it is unable to reach compliance? It can't. Either the company shuts down, stops selling Apple devices, or the proceeds of their illegal sales will be garnished before they can pay Apple. It is a plan that is functionally identical to Apple leaving the EU.
Apple can choose not to operate in the EU. That's a totally legit and acceptable outcome. But that means they have to actually give up that revenue. Any attempt at laundering it will just mean that the penalties apply to whatever entity they try to use for the regulatory evasion.
(Or I guess shrink their presence to do small that the DMA no longer applies. But again, this is Apple. They'll rather hand out user data to the Chinese government than leave China and all their juicy money.)
(As an aside, I think this discussion was about browsers, not about app stores. It matters a bit, because for browsers, the main complaint on Apple's proposal seems to be the geo-restriction, while for app stores nobody is complaining about that but there are plenty of other issues.)
If the EC decides to interpret the rules as requiring compliance globally rather than just within the EU, and the courts were to uphold it, it would be irrelevant that Apple's sales are being done via some shell company. If anything, it would probably be considered worse, since it'd be a clear attempt at circumventing the law. The products that the shell company would be selling would be found illegal, and one way or other the operation would stop. And the effect would be that Apple would have left the EU.
If your plan were actually a thing, every American company would already be doing it just to shield themselves against GDPR (which has fines based on global revenue, not EU revenue). But they don't do it, because it wouldn't work.
Indeed! They're doing the one thing I've said in each of my previous four messages in this thread is the way to avoid being bound by EU laws: by not doing business in the EU.
What they aren't doing is trying your plan of creating a shell company to break the laws on their behalf.
The EU lacks the power to do that kind of enforcement. It surprisingly quickly turns into a military and hard power question, which the EU lacks considering it’s the GDP of all these evil tech companies that’s paying for their national security and health care.
How quickly, exactly? Do you think the US military would step in to resolve a dispute regarding a consumer electronics company?
> considering it’s the GDP of all these evil tech companies that’s paying for their national security and health care
I find the logic of the article you linked highly questionable.
> Certainly it is more difficult than what drug companies do now, which is to set a high U.S. price, assuring profitability, no matter how thin the profit margin on European sales.
So there is a profit margin, right? Otherwise drug companies wouldn't sell their products in Europe. It seems that this article and the MFN legislation is worried about the high drug prices in the US. Fair enough, I suppose, but how exactly is that "subsidizing the European health system"?
> The goal of the MFN concept is to deliver fair prices to Americans without diminishing drug company profits.
So you are specifically protecting the drug companies' massive *profits*. Not research or production costs, profits.
> Since the introduction of the Medicare Part D prescription drug benefit, Medicare has been prohibited by law from using its volume-purchasing power to negotiate prices for the drugs it covers, while government-run European health authorities have used such volume-purchasing power to obtain drastically low prices.
What’s the website support of Firefox like? I tried switching to Safari last year and a small minority of websites didn’t work as expected. Even though it was small, it was a big enough problem that I switched back to Chrome.
Everything works. In some cases you have to disable the strictest security level, a bit like disabling your ad blocker. Even that is very rare. I do the remember encountering actual problems that would affect my experience.
In Rust it’s easier to leverage external crates/libraries that are more optimised than rolling your own. This can lead to performance increases
(I don’t know if fish is doing this)
It definitely makes a difference around threading; exposing thread safety in function API makes it easy to understand where/how you can add threading support, or what is preventing it.
This is only true for very simple single-threaded code. Once you’re doing anything the compiler can’t trivially optimize, you’re using libraries, getting left far behind by the Rust program, or both.
> Since most industrial software is in C and C++ an example would be more convincing.
Agreed- do you have any to back up your original claim?
> > doing anything the compiler can’t trivially optimize
> What does compiler optimization have to do with libraries?
One of the most common reasons to use a library is because it has optimizations you want to use. For example, performance-sensitive programs link against OpenSSL even if they’re just using a couple of hash functions because the SHA-256 function you copied into your codebase won’t have their assembly backend or use of processor intrinsics. Repeat for string searches, pattern matching, all kinds of math, etc. where people have written libraries with pricessor-specific assembly, SIMD intrinsics, etc.
> Plenty of C and C++ programs are multi threading using a system api like pthreads.
Yes - and the long history of bugs related to that is why many stayed single-threaded because it was more work than the author had time for to make the code thread-safe. Rust’s “fearless concurrency” talk isn’t just marketing but a reaction by people with a lot of experience in the area realizing just how much more they used concurrency when it was easy to do correctly rather than infamously hard.
When C programmers do crypto they also use OpenSSL, but more for security than performance. Do you have an example of a rust library which is a better substitute for commonly hand written C?
> fearless concurrency
Not related to the topic of discussion about performance gains of using libraries.
