1,650 karma · joined August 8, 2020
* not everyone has “two codebases” many people have one codebase and two different application distributions, one for server and one for client.
* you will still have “two codebases” you have just removed the rendering logic from you client codebase.
* What is the distribution of latencies of rendering json into html on the client? Are there numbers to suggest this takes more than 100ms for many people? If not the proposed efficiency advantages are being overstated.
If the article were suggesting removing client side logic completely these arguments would be stronger.
“We work to ensure the internet remains a public resource that is open and accessible to all.”
I guess by “all” they mean only people with political opinions they support.
The GTk developers aren’t ordinary people. They comprise an organization of trusted individuals and leaders. Not to mention, Many of them are employees are large companies like Red Hat and Canonical. They have resources. The likelihood of a random strangers contributions being upstreamed are low, let alone them setting project direction around backwards compatibility.
Hundreds if not thousands of apps have been left behind in GTK2 and GTK1 before that. Those are all apps that could be part of the current GNOME ecosystem, now they will look like bad foreign apps. Tens of thousands of man hours completely wasted.
This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.
If that’s the case then you have failed as a library developer.
At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.
I see people tend to write C89+designated initializers but this is a code smell IMO. Initial data should always be 0, especially data that lives in BSS/data section.
Without going all the way with server push, the logic behind the transition from http1.1/tls/tcp to http3 seems a bit dubious to me. If they aren’t going to go all the way, things already worked well enough IMO. Seems like google is just arbitrarily deciding what they want the web stack to look like.
Dereferencing null optionals is UB for consistency with dereferencing pointers. All uses of operator* should have the same semantics and the C++ standards committee did the right thing by ensuring that with optionals. Checking for null in operator* would break consistency.
If you want to dereference an optional that may be null, use the .value_or() method. For the times when you absolutely know the optional has a value use operator*.
If you’re wondering why you would use an optional over a pointer. The idea is that optionals allow you to pass optional data by value. Previously if you wanted to pass optional data, you’d have to do it by reference with a pointer. This is part of c++’s push towards a value-based style, which is more amenable to optimization and more efficient in general for small structs (avoiding the heap, direct access of data). Move semantics are a part of that same push.
Example is myself. I am a child of poor immigrants. I am neither white nor wealthy. I do not care about involving myself in your politics, I spend my time focused on working and being productive for the sake of supporting my family. Frankly your politics destroyed my country.
Also false. Many fair minded people simply don’t have time to concern themselves with politics.
Not to mention that in many cases political actors who justify their actions on the premise of “structural inequality” end up reducing fairness.
Inspiring but simply false
You can be apolitical at work while still opposing the so called status quo with your vote. Or you can oppose the status quo in an explicitly political organization outside of your job.