The absolute state of web storage protocols
-
..
-
@Arantor said in The absolute state of web storage protocols:
My stepdad wrote an entire "paint program" in QBASIC (not even QuickBASIC) with mouse support (hooking into assembly).
I wrote (what I'd now call) an IDE in BBC BASIC when at school. It was one of the most awful things ever, requiring swapping code from floppy disk all the time, close to doing a large switch statement in ZX Spectrum BASIC (the computed GOTO... from the bowels of HELL itself! It formed the guts of an assembler I wrote.)
Anyone telling me that OO is the worst thing ever has really seen absolutely nothing yet.
I really liked TurboPascal once I got my hands on a copy. It was beautiful! It worked the way I thought programming should be done (once I got over the worst of my bad old BASIC habits) and it was just so nice and fast to use.
Anyway, yes, you can do a GUI without OO. It's just very difficult to do and the code is very confusing. BTDT. You need the complexity once you go past simple things like basic text output with maybe some simple menus driven by number input.
-
@Benjamin-Hall said in The absolute state of web storage protocols:
Yeah, except we're dropping the sockets because they don't really serve much of a purpose except to get in the way. There are a lot of really stupid abstractions here that make it way more painful to disentangle, but we're trying to move in that direction. If product lets us...
Digging in further...it turns out the socket implementation isn't actually some battle-tested websocket library. No, like SO MANY #@%#$% things in this POS code, it's a hand-rolled, pure javascript thing that the R&D guys threw together and tried to make "compatible" with Express.js out of convenience. Basically, I see zero reason this was ever done over sockets in the first place.
-
@dkf I even realised I still had a copy.
29KB of QBASIC and 378 bytes of machine code. It's a bit obtuse to run because it stores every operation in an array and replays them (so it has perfect undo, by way of stepping back through its array, but it means that actual drawing is janky AF)
Drawing a line for example is left click on line, click on one end point, click on other to lock in the coordinates, then right click on line.
But I think that makes your point for you about state management...
-
@Mason_Wheeler said in The absolute state of web storage protocols:
@Bulb said in The absolute state of web storage protocols:
@Mason_Wheeler said in The absolute state of web storage protocols:
In the 21st century, OO is table stakes. And Rust just looks ridiculous for not including it.
Actually, in the 21st century, OO is dead as a doornail and language designers are realizing how big of a mistake it was.
Most of the languages designed in 21st century don't have inheritance. Just some of them have some delegation crutch to cover the “simple” cases, but in Rust they never agreed on which cases are simple enough for a generic tool while being non-trivial enough to actually need it.
Don't be ridiculous. There's a reason OOP conquered the world while languages without it remain relegated to minor niches: The class/inheritance model is the single best tool we've ever developed for managing complexity.
Is it perfect? No. But it's significantly better than anything else out there, and people pointing to problems and saying "we should be using my preferred language because it doesn't have this problem" reek of sour grapes. OOP has triumphed decisively in the marketplace of ideas.
Uhm, no. It's not the worst, but definitely not the best and the triumph was not that long-lived. It is better than the critics see it, but sadly most people have (or at least had, in my generation) very wrong idea how to actually use it.
Which stems directly from the "Simula brainworm": the idea that OOP Objects are model of the Problem Domain (or even Real-World) entities. Which is a very, very bad idea. With some exceptions like GUI, I suppose.
-
@Kamil-Podlesak I dunno if it’s a “brainworm”, but there are definitely cases where it feels like the appropriate way to sanely reflect the behaviours you’re trying to embed into the code.
Not that it should always do that, mind, I just think it can be a useful approach, just not the only approach.
-
@Mason_Wheeler said in The absolute state of web storage protocols:
Don't be ridiculous. There's a reason OOP conquered the world while languages without it remain relegated to minor niches: The class/inheritance model is the single best tool we've ever developed for managing complexity.
I'm not being ridiculous. The class/inheritance model turned out to be bad tool for managing complexity, because it is inherently complex—by combining mostly orthogonal aspects of polymorphism, encapsulation and code reuse to one tool, classes—and is on the way out. Modern C++ code avoids inheritance everywhere, strongly preferring the static ad-hoc polymorphism of templates instead, Go does not even have inheritance, and all the newer advice for Java or C# says to avoid inheriting classes. Because inheritance hierarchies may look nice and logical to the guy designing them, but for the next guy that comes to the project they are utter pain in the arse.
You still have most of the tools OOP brought (except inheritance), but they are now separate tools used independently, not as one unified concept.
-
@Arantor said in The absolute state of web storage protocols:
@Gustav It's not learning from PHP, I can tell you that.
Thank
for that.
-
@Kamil-Podlesak said in The absolute state of web storage protocols:
It is better than the critics see it
Because the critics talk about the narrow sense of trying to match the problem domain, or of the specific realization that class is the one and only concept used for all the purposes.
- Polymorphism and generic code are great. Nobody says they are not.
- Encapsulation is absolutely essential for sanely handling large codebases. Nobody says it is not.
- Code reuse is, of course, desirable.
It is trying to tackle them all with the one tool, class inheritance, that is being criticized. And the critique is being applied.
- Polymorphism is usually only used with interfaces these days, often small interfaces of just one or a few methods.
- Encapsulation is often at the level of modules or packages using the
internalaccess modifier. - Code reuse, where it does not match the polymorphism, mostly returned to plain old functions. Of course where polymorphism is applicable, it uses (statically or dynamically) generic functions and provided methods in interfaces.
But it's not one “OOP” concept now.
-
@Mason_Wheeler said in The absolute state of web storage protocols:
In the 21st century, OO is table stakes. And Rust just looks ridiculous for not including it.
No, that's the 90s of the 20th century you're talking about, when people thought everything would be running Java at some point.
@Mason_Wheeler said in The absolute state of web storage protocols:
Don't be ridiculous. There's a reason OOP conquered the world while languages without it remain relegated to minor niches: The class/inheritance model is the single best tool we've ever developed for managing complexity.
There's actually different implementations of OOP, the class-based inheritance model is just the most common one. And it conflates subtyping, code reuse, encapsulation and access control.
"Prefer composition over inheritance" is a common principle because of the problems with inheriting implementations instead of interfaces (i.e., sub-typing only), and Java acknowledges it enough to outright not implement multiple-inheritance. Whereas Python or C++ allow you to do that just fine. You want MI clusterfuck? Here's MI clusterfuck. Virtual inheritance? Go right ahead.
But single inheritance still has problems, just to a lesser degree.The main advantage inheritance has over composition is (often?) that it's just much less work to implement, depending on how much syntactic sugar your language provides.
-
@Gustav said in The absolute state of web storage protocols:
@dkf said in The absolute state of web storage protocols:
If you say "but we have that, we just don't do inheritance/derivation" then I'd observe that inheritance is by far the least important part of OO
...except in GUI, where it's the single most important feature of the entire language that single-handedly reduces total code that needs to be written by somewhere around 99%.
But outside GUI, yes, inheritance is the least important feature, if not an anti-feature. But so is the entire OOP. I believe the real problem is people trying to use the same coding style for both GUI and non-GUI code. OOP is amazing for GUI and terrible for anything and everything else. It's impossible to do GUI without OOP and inheritance, as opposed to every other type of code, where shittiness of the code is directly proportional to amount of OOP (it even continues to x=0 - no OOP at all is better than minimum amount of OOP).
You don't really need inheritance to write a GUI framework. It works well for it, but it can be replaced by using policy pattern. That basically means you have a “widget” object that has a bunch of sub-object implementing the various parts of the interface, and you match them up either at compile time or at runtime.
Most of the OO frameworks already used it in the form of signal handlers anyway—e.g. while a button is derived from widget, you don't derive button to make an “ok button”, you just bind the click callback to appropriate function.
Some frameworks go full Entity-Component System, an approach where you have a set of “entities” that are composed of “components”, which can be combined fairly liberally, and are basically policies again. That pattern's been very common in game development and some other simulations.
-
@Benjamin-Hall said in The absolute state of web storage protocols:
@Bulb said in The absolute state of web storage protocols:
@Benjamin-Hall said in The absolute state of web storage protocols:
Really, the workers could basically manage themselves, as long as they can ask someone for a list of channels they're supposed to handle and be able to ask "is this person valid". And those two bits of state are already stored very much in a database, so any number of replicas could respond to those requests without any need to "manage" specific nodes.
If the reconnect logic stored the “waiting for the client to reconnect since X” status in the shared storage, and then the redistribution read that from the shared state, I think it should be refactorable to handle both the client reconnecting, in the timeout, via another server node, and also redistributing the channels to workers connected to different server node at the time (with proper transaction handling).
Probably. In the long term, we're moving away from this particular server code because it does lots of screwy things (never trust code you get from the R&D folks, especially when they didn't actually have requirements and made it "flexible"...by which we mean "over-abstracted but not actually flexible in any useful way, just hard to deal with"). When we do, the sockets aren't staying as such.
That's a noble goal. But changing too many things at once will mean also testing too many things at once and that will make fixing the bugs made in the process harder. So I'd stillchange the reconnection logic separately, and the protocol separately.
-
@Bulb what I see in GUI framework code more often than elsewhere (maybe it's prevalent in ECS too, I don't know) is downcasting. E.g. in Qt you want to get a QPushButton back from a QWidget or QObject, say through QObject::sender(). Polymorphic downcasting is usually a code smell, but definitely happens.
I don't know if you can get something similar in Rust.
-
@Benjamin-Hall said in The absolute state of web storage protocols:
The one concern is needing to know if a node has gone AWOL (in which case the responsibility for those channels needs to go somewhere else). But that can be handled via a more dedicated heartbeat mechanism or via an outward ping.
Outward ping only checks the computer, but not the service, so a heartbeat is definitely preferable.
I probably used the wrong term. I meant that the workers would contact the server saying "hey, I'm still alive" instead of the server trying to contact the worker to determine that.
You sound like you used them almost exactly the other way around.
- Heartbeat is a periodically sent message, something like “it's 11 o'clock and all is well”, “it's 12 o'clock and all is well", “it's 1 o'clock and all is well”…
- Ping is a “are you there” (ping)/“yes, I am” (pong) exchange.
- Since the
pingcommand sends an ICMP ping that only verifies the network layer works, using the term suggests that's what you mean, even though the term is broader and does include ping messages at the application level.
-
@topspin said in The absolute state of web storage protocols:
@Bulb what I see in GUI framework code more often than elsewhere (maybe it's prevalent in ECS too, I don't know) is downcasting. E.g. in Qt you want to get a QPushButton back from a QWidget or QObject, say through QObject::sender(). Polymorphic downcasting is usually a code smell, but definitely happens.
I don't know if you can get something similar in Rust.You can downcast in Rust with the
Anyinterface, which any'statictype, i.e. type that does not contain any lifetime-restricted references, implements. With the restriction that you can only downcast to the specific type, not to a more specific interface that it also implements.But you generally don't need to, because the newer frameworks—in Rust, but also the web ones—stick much more to the MVC pattern (or similar like MVVC etc.). They have separate widget tree, which only defines the rendering, separate model objects that keep the state and the functions that modify the model and queue events to trigger re-render of the widgets. The widget and state trees may be connected or completely separate, but either way you shouldn't need to reference back to the widgets from the callbacks.
-
@Bulb said in The absolute state of web storage protocols:
You sound like you used them almost exactly the other way around.
- Heartbeat is a periodically sent message, something like “it's 11 o'clock and all is well”, “it's 12 o'clock and all is well", “it's 1 o'clock and all is well”…
- Ping is a “are you there” (ping)/“yes, I am” (pong) exchange.
- Since the
pingcommand sends an ICMP ping that only verifies the network layer works, using the term suggests that's what you mean, even though the term is broader and does include ping messages at the application level.
I've seen systems that responded to
pingbut where the whole of user space was dead. If you want to know if a service is up, you need to communicate with the service, and not just some proxy for it. Heartbeats are useful, so too are watchdogs (simple processes that observe heartbeats and restart things when the heartbeats aren't frequent enough) though perhaps more so in hardware...
-
@Bulb said in The absolute state of web storage protocols:
You don't really need inheritance to write a GUI framework.
As long as you can configure behaviours with callbacks instead, I'd totally agree. That matters more for things like setting up input validation and so on; basic buttons can get away with simple "send a message when clicked" stuff easily enough.
A bit of inheritance can help in toolkit implementations (eg, checkbuttons and radiobuttons are definitely related to ordinary buttons in many respects), but it really shouldn't be common at the user level.
-
@dkf said in The absolute state of web storage protocols:
@Bulb said in The absolute state of web storage protocols:
You sound like you used them almost exactly the other way around.
- Heartbeat is a periodically sent message, something like “it's 11 o'clock and all is well”, “it's 12 o'clock and all is well", “it's 1 o'clock and all is well”…
- Ping is a “are you there” (ping)/“yes, I am” (pong) exchange.
- Since the
pingcommand sends an ICMP ping that only verifies the network layer works, using the term suggests that's what you mean, even though the term is broader and does include ping messages at the application level.
I've seen systems that responded to
pingbut where the whole of user space was dead. If you want to know if a service is up, you need to communicate with the service, and not just some proxy for it. Heartbeats are useful, so too are watchdogs (simple processes that observe heartbeats and restart things when the heartbeats aren't frequent enough) though perhaps more so in hardware...Software watchdogs can still detect useful issues, and they are typically in a position where they can more immediately fix the problem. If a service dies a software watchdog can restart it immediately, while a watchdog in the hypervisor or on a different physical machine would probably need to resort to bouncing the container or even the host.
If you're working on the client end though, I'd prefer a heartbeat which runs over the application protocol over an out-of-band ICMP ping packet.
-
@Arantor said in The absolute state of web storage protocols:
@Kamil-Podlesak I dunno if it’s a “brainworm”, but there are definitely cases where it feels like the appropriate way to sanely reflect the behaviours you’re trying to embed into the code.
Not that it should always do that, mind, I just think it can be a useful approach, just not the only approach.
Yes, of course there are valid cases. And less valid cases.
The real problem, however, lies in the reverse direction: objects/classes that do not represent anything in the problem domain and exist solely to organize code. In my experience, majority of OOP-raised developers do not really grasp the concept. Even in the Java world, home of the (in)famous AbstractSingletonProxyFactoryBean. Which, TBH, is quite a bad name and it should be anonymous, or have a non-descriptive name. Like "Jeff" or "Laszlo" (for the fans of Hungarian notation).
-
"Prefer composition over inheritance" is gibberish. It makes exactly as much sense as "prefer drills over saws." They're different tools with different use cases, that might maybe be able to do each other's job if you squint hard enough, but do a very bad job of actually being useful for replacements for each other.
To be completely frank, in all the years I've heard people spouting this anti-inheritance nonsense, I've never once seen an actual example of the problem. When pressed, people say "fragile base class! Fragile base class!" which is just silly. There appear to be two different things called the fragile base class problem.
- "If
Barinherits fromFoo, and you change something inFoo, you might breakBarwhich was using it." Well... yeah, that's how dependencies work. Doing the equivalent thing with composition would not change this. - "If
Barinherits fromFooand it has aBar.Frobmethod, and then you later add aFoo.Frobvirtual method, suddenlyBar.Frobwill get called when you never intended it to." Thing is, this only happens if you're using garbage languages with no explicitoverridesemantics. It's not a problem of inheritance; it's a problem of poor (or missing) language design. (Perhaps this is why, as @Bulb said, modern C++ tries to avoid it? Joel Spolsky once pointed out that the entire history of the evolution of the C++ language is based on papering over bad design decisions from early on.)
- "If
-
@Mason_Wheeler said in The absolute state of web storage protocols:
I've never once seen an actual example of the problem.
Sounds like a you problemI've never seen an example of multiple inheritance being problematic.
-
@Kamil-Podlesak sure, that’s absolutely a problem. PHP is very enthusiastic about this and it bugs the hell out of me because quite often what I actually want isn’t a class but a procedural function, but there’s no other convenient way to get to what I need.
PHP frequently goes to the level of producing classes full of static methods as a crutch for “I don’t want this every time, but I also don’t want to manually have to remember to include it and any of its implicit/logical dependencies, and its a procedural function where I’m not handling state so it shouldn’t be a class anyway”.
-
..
-
..
-
@Mason_Wheeler said in The absolute state of web storage protocols:
- "If
Barinherits fromFoo, and you change something inFoo, you might breakBarwhich was using it." Well... yeah, that's how dependencies work. Doing the equivalent thing with composition would not change this.
It depends on what something, but in many cases it would. Because with inheritance, everything you add to
Foois automatically available onBar, but with composition it is not.- "If
Barinherits fromFooand it has aBar.Frobmethod, and then you later add aFoo.Frobvirtual method, suddenlyBar.Frobwill get called when you never intended it to." Thing is, this only happens if you're using garbage languages with no explicitoverridesemantics. It's not a problem of inheritance; it's a problem of poor (or missing) language design.
Yeah, that one is very theoretical; in practice it does not happen even in languages that are fully duck-typed.
(Perhaps this is why, as @Bulb said, modern C++ tries to avoid it? Joel Spolsky once pointed out that the entire history of the evolution of the C++ language is based on papering over bad design decisions from early on.)
It isn't, and it cannot be, because C++ now does have explicit
overridesemantics. And yet it is replacing inheritance with approach that does not have corresponding check.Modern C++ avoids it because of variance mismatch, and because it is usually inferior to concepts:
- Variance mismatch: few classes in the standard library have ever been designed for inheritance, because it never made sense, and a lot of people got burnt when they tried to inherit strings, maps, lists and vectors. The problem is that those represent mutable objects, and reading is covariant, but mutation is contravariant, so the result cannot be used polymorphically.
- C++ has single dynamic dispatch, which is opt-in (only methods marked as
virtualget dynamic dispatch), but multiple static dispatch (function overloading). - Functions can be overloaded to work with a type after the type is defined, which allows adding concepts to existing types. Virtual methods can't be added like that.
- Functions can be overloaded for primitive types and other types that are not
classorstruct, virtual methods can't. - C++ programmers like to avoid runtime cost, so they prefer static polymorphism over dynamic one (even though static polymorphism can end up being slower due to generating more code).
plus there is the reason that the one part of the standard library that does use inheritance, I/O streams, is the most hated part of it. The streams are designed quite carefully to make them as foolproof as possible, but they still prove tricky to extend correctly in practice. And they still involve, an inner policy class, so also composition, not pure inheritance, and that inner base class
streambuf, implements both read and write interfaces always, because aligning the inheritance hierarchy so thatistreamwould take read buf,ostreamwould take write buf, butiostreamwould take read/write buf proved impossible. It wouldn't have been a problem if they were just concepts, not base classes.Also, C++ has the “private inheritance” that is technically inheritance, but semantically composition and must be used in some cases, in particular when implementing custom streams, for tricky technical reasons. C++ is rather finicky to use.
- "If
-
@PleegWat said in The absolute state of web storage protocols:
If you're working on the client end though, I'd prefer a heartbeat which runs over the application protocol over an out-of-band ICMP ping packet.
ICMP ping does let you find out if there's a network connectivity issue. Unless one or the other end is in Azure, but you might then just claim that there's a connectivity issue anyway.
-
@Gustav said in The absolute state of web storage protocols:
@Bulb said in The absolute state of web storage protocols:
Modern C++ code avoids inheritance everywhere, strongly preferring the static ad-hoc polymorphism of templates instead,
Mostly for performance reasons, not usability. A lot of things in C++ stdlib could be improved with just a bit of pure virtual base classes here and there.
I strongly disagree. The best part of C++ stdlib rely heavily on concepts while the worst parts use inheritance.
@Bulb said in The absolute state of web storage protocols:
Go does not even have
A sentence starting like that is never a good argument. Remember that Go devs used to be vehemently against generics.
I have to give you that.
@Bulb said in The absolute state of web storage protocols:
and all the newer advice for Java or C# says to avoid inheriting classes.
While this is absolutely true, it doesn't apply to GUI. Because GUI is special.
In Java and C#, because those were initially built on inheritance, it remains special. But the frameworks for rendering to web view, I think most of them don't actually use inheritance. Or only kind of; TypeScript is generally a bit weird in that respect.
-
@Gustav said in The absolute state of web storage protocols:
A lot of things in C++ stdlib could be improved with just a bit of pure virtual base classes here and there.
You could have stopped at just:
A lot of things in C++ stdlib could be improved.
Or even used:
A lot of things in C++ stdlib could be improved with a good flamethrower and 80 gallons of commercial-grade disinfectant.
-
@Bulb said in The absolute state of web storage protocols:
It isn't, and it cannot be, because C++ now does have explicit override semantics.
Really? How did they manage to do that without breaking gazillions of lines of existing C++ code?
-
@Mason_Wheeler Thanks to the magic of warnings that can be turned to off, warning or error and don't apply to system includes.
-
@Bulb said in The absolute state of web storage protocols:
C++ programmers like to avoid runtime cost, so they prefer static polymorphism over dynamic one (even though static polymorphism can end up being slower due to generating more code).
There are two costs that "zero cost abstraction" tends to gloss over:
- Costs relating to having many more copies of the code.
- Costs relating to having to make more copies of values.
The result is that things in C++ are capable of being very good when done carefully, but frequently are much worse than their potential maximum, and getting to as good as they can be is often very tricky indeed because the places where you're actually paying for things unexpectedly can be highly non-obvious. The result is that what happens in practice is too often at variance with what you might think from standard benchmarks.
-
..
-
@Gustav said in The absolute state of web storage protocols:
The inheritance parts were developed before 2001. The template parts were developed after 2001.
The inheritance parts—the IO streams—use the template parts, and came with them from the SGI standard template library. So no, the parts I'm talking about are not older.
-
..
-
@dkf said in The absolute state of web storage protocols:
Or even used:
A lot of things in C++ stdlib could be improved with a good flamethrower and 80 gallons of commercial-grade disinfectant.
Or just remove C compatibility.
-
@Gustav said in The absolute state of web storage protocols:
@Bulb standard template library wasn't part of C++ standard until 2003.
I'm pretty sure that's wrong. STL came with C++98, 2003 was just minor differences.
-
..
-
..
-
@Gustav said in The absolute state of web storage protocols:
std::iostream is older than std::function, that's pretty much the entire reason why std::function was designed better than std::iostream, one using templates and the other using inheritance is just a coincidence.
I wasn't even thinking about
std::function. There is so little available design space available for it that talking about whether it is better or worse designed than something else does not even make sense. Besides,std::functionis based on inheritance. It could be based on interface implementation, but C++ does not distinguish the two.I talked about things based on concepts, which means mainly the algorithms library, which has been there from the start. It's not better overall—the lack of range object is a huge omission and limits the usability a lot—but it has better separation of concerns.
-
@Gustav said in The absolute state of web storage protocols:
@topspin you sure? IIRC C++98 had vector and a couple other things, but the STL as we know it, with <algorithm> and whatnot, was only added in 2003.
Side note: if vector was added in 2003 rather than 1998, the vector<bool> fiasco likely wouldn't happen.
Besides the Bubba Gump Shrimp value initialization, 03 was just Defect Reports.
@Gustav said in The absolute state of web storage protocols:
Or just remove C compatibility.
They already did.
Not in the sense that the worst sins of C++ are those inherited from C.
-
..
-
@topspin said in The absolute state of web storage protocols:
@Gustav said in The absolute state of web storage protocols:
Or just remove C compatibility.
They already did.
Not in the sense that the worst sins of C++ are those inherited from C.
Well, … yes, C++ defaults to everything being copyable because structs in C are copyable.
@Gustav said in The absolute state of web storage protocols:
True, but that would require C++ to drop compatibility with C++.
They tried their best with the way they bolted-on “move”.
(inb4
)Rust did the opposite sin of making everything movable, and then worked around it with the clever, but nevertheless really ugly,
Pin.
-
@Gustav said in The absolute state of web storage protocols:
True, but that would require C++ to drop compatibility with C++.
Yes, or introduce something like editions/profiles/whatever that allow compatibility with old code while removing cruft in newer code. Backwards compatibility is crucial to C++'s success, but also hinders forward progress. Many people are aiming at that in one way or another (Circle, Carbon, Cpp2, etc.) but they're probably unlikely to succeed. (They won't even break the fucking ABI, even though MSVC used to do that all the time. But apparently linux can't ship two different versions of libstdc++ even though their
.sos are versioned, or else RedHat will stay on the same version until the year 2525, if man is still alive. /r)But my original remark was rather aimed at: C language advocates are in no position to argue how terrible C++ is, irrespective of that being true in some sense or the other. C is the reason why C++ is terrible.
-
..
-
Is the takeaway that everything is crap, up to and including web storage protocols, because language design is hard, C is shit, C++ is trying to be less shit and everyone is awful at figuring this out but we’re getting better, honest?
-
..
-
..
-
@Gustav “we’re getting better, honest” wasn’t entirely serious.
It’s in the same camp as a criminal going, “it weren’t me, honest”
-
@Arantor said in The absolute state of web storage protocols:
Is the takeaway that everything is crap, up to and including web storage protocols, because language design is hard, C is shit, C++ is trying to be less shit and everyone is awful at figuring this out but we’re getting better, honest?
C's shitness is not closely related to C++ at all.
-
@dkf because C++ gives you at least some tools to avoid C's shitness, but not vice versa.
