nous @ nous @programming.dev

Posts

0

Comments

716

Joined

2 yr. ago

How do C and C++ try to restrict mutability?

IMO rust does use OOP styles all over the place. OOP does not mean dynamic dispatch or inheritance - that is just what older popular languages used. Note that static dispatch and monomorphization (where the compiler generates a method for each type at compile time rather than using a runtime lookup) give you a lot of the benefits of dynamic dispatch at the cost of binary size in favor of runtime checks and performance.

And other aspects of OOP, like encapsulation, data abstractions and polymorphism are easily achievable in rust and often are. Just look at any object from the std library - they are all essentially written in an OOP style. Such as Vec or File - hidden internal state with traits that you can swap them around with other parts that make sense. The only thing it really likes - like Go lang (which claims to be an OOP style language) is inheritance.

And the only reason rust is not seen as or describes itself as an OOP language is because it does not force the OOP style on you. But instead lets you program in more of a functional or procedural style if you want to. You can pick the best methodology to solve the problem you have at hand rather than trying to fir everything into a single style.

But that does not make it bad at OOP style.

Inheritance is isn’t always a terrible choice. But it is a terrible choice often enough that we need to warn the next generation.

But also, when it is not a terrible choice for a problem it is often not the best choice or at the very least equally good as other options that work in vastly more cases.

Note that I am explicitly calling out inheritance here rather than OOP as a whole. There are many things about OOP that are not that bad or quite ok, like composition for instance. It is generally badly designed inheritance that leads to

require tons of internal knowledge about how the classes work

And it is very hard to create a good inheritance structure that does not devolve over time as new requirements get added. While there are other patterns that OOP languages have started to adopt in more recent years (like composition and interfaces) that solve a lot of the same problems but in a vastly more maintainable way.

I think a lot of people conflate OOP and inheritance to mean the same thing. And inheritance is what should get the bad rap. It does not solve any problem I have seen any better than other language features (in particular interfaces/traits can solve a lot of the same problems) but inheritance causes far more problems overall.

But building the code out of logical units with fenced responisbilities is in my opinion a good way to structure code.

This is encapsulation, which is one of the better ideas from OOP languages. Though also not unique to them.

And I have a hard time to wrap my mind around some design choices in the language that would have been very easily solved with a more OOP like structure.

What design choices would those be? And how would they better fit into an OOP like structure? Note that rust is not anti OOP - it uses OOP techniques a lot throughout the code base. It just lack inheritance and replaces that with other IMO better features.

It requires you model your problem perfectly from the start, then it can work alright. But in reality you cannot know the future and when new requirements come in that don't fit the model you created you are left in a crappy spot of needing to refactor everything or just cram it in however you can.

So the easy way is to inherit and extend to a custom type while keeping the original functionality intact.

You can do this with traits and interfaces in rust/go. You can add any methods you want onto existing types. Which IMO is better. No need to subclass, in just just create a new trait, implement it on the type you want and you have new behavior attached to that type without needing to convert the existing thing you got from something into a new type.

And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code.

It really does not. You can have implementation on traits that don't need to be re-implemented on every type - like the Iterator - it provides 76 methods of which you need to implement only 1 for new types. You can implement others for custom behavior which is great for specialization (aka using a more efficient implementation for types that have more info, like calling skip on an array which knows all its elements vs the default which needs to call next n times).

But it creates a vastly more flexible system. Take a very basic example - read/writing to something. How do you model that with inheritance? Basically you cannot. Not without painting yourself into a corner eventually. For instance, you can read/write to a file, to a network socket, to stdin/stdout but each of these is very different. Stdin for instance cannot be written to and Stdout cannot be read from. You might want to have a buffered reader/writer as well that wraps these types making read operation cheaper.

You cannot put these into a inheritance tree. Everything either needs to inherit from the same generic base that can both read/write and probably also close. But then for some types you need to implement these methods that don't make sense that do what? Nothing when called? or throw an exception? It is a poor way to model this behavior.

Read and Write are orthogonal ideas - they have nothing to do with each other except they might be useful on some of the same types. With interfaces/traits you are free to separate these and implement them on whichever types make sense for them.

I have not yet seen a problem that is solvable with inheritance that cannot be better solved with some other language feature in a better way. It sort of works for some things, but other solutions also work at least equally well. Which leave it in a state where what is the point of it? If it is not solving things better then other solutions we have these days?

Inheritance, which allows classes to reuse state and methods of other classes.

This is the absolute worst feature of typical OOP languages. I don't know of any case where it is the best way to solve a problem and very often becomes a nightmare if you don't get the exact hierarchy of types right. It becomes a nightmare once you have something that does not quite fit into the assumptions you original made when you started out. Which happens all the time.

The examples given with the logger can be solved just as well if not better with interfaces/traits with solutions that don't have that problem.

Oh they care. They care a lot. Particularly that you don't have any so they can sell all your details to any bidder.

This is irrelevant with Steam though. Steam offers a runtime with preconfigured versions of everything that is needed to give the devs a consistent environment for their games to run no matter how fragmented the linux install base might be. This runtime is also what proton uses for ship its different versions.

It is not just WINE. The Steam Linux Runtime is a stack of linux native libraries, binaries and tools designed to give game devs a consistent version of things to develop games against. Recently they moved this to be container based and I believe proton (which contains wine) is run inside this runtime as well.

I don't think data races are generally considered a memory safety issue. And a lot of languages do not do much to prevent them but are still widely considered memory safe.

How are they not memory safe in a multi-threadded context?

You missed an important part of that quote:

Send/receive of subvolume changes, efficient incremental filesystem mirroring and backup

This is explicitly talking about a different feature that can incrementally sending changes to the filesystem to another filesystem as a backup. Not at all about how snapshots work.

Linux makes up exactly one package on a so-called Linux system.

True, it was a poor proxy for what I really meant - which was the amount of code that my system runs. Linux as a project is growing quite fast these days and is getting bigger and bigger. But the number of GNU tools I use (and thus their code that I use) is growing smaller and smaller.

Musl, systemd, Freedesktop, etc. were never OS projects. GNU and Linux are OSes.

What the hell makes a project an OS project? What even is an OS - that is a debate as old as computers. What makes GNU more of an OS than systemd or musl or anything else? GNU is not a complete OS on its own. It has failed to meet that goal for decades. Is it just because it claims that title? Are the other projects just not ambitious enough? Hell why are we not raising pitchforks at GNU for being a all encompassing project that wants to consume everything like everyone complains systemd is trying to do?

The lines drawn here are meaningless and arbitrary. GNU is no more important to my systems as any other project mentioned here and makes up no more of my system then they do. I don't see why so many are obsessed with singling out GNU and explicitly excluding everything else. It is a pointless distinction created by a guy that was pissy that his pet project was not getting the attention he thought it deserved.

Not sure I would call them incremental. Nor each snapshot (or even the first) being a clone of the system (which is contradictory to being incremental).

All snapshots 'contain' all data relevant to that snapshot. It is just that multiple snapshots can point to the same underlying block of data and when new block of data is written it is copied to a new location so old snapshots can still see the old blocks of data but newer ones see the newer blocks. If you delete a snapshot that is the only thing pointing to some blocks then those blocks are now considered free and can be overwritten. But other blocks that still have other snapshots pointing to them will remain.

So you can delete any snapshot you want and no other snapshots needs to change or incorporate any other changes - they all already point to all the data they need.

Why not also recognize systemd, or musl, or kde or gnome or any of the other millions of non GNU packages that are needed to make up a complete OS.

Fuck if I am going to rattle off all my installed packages every time I want to mention what OS I am running. Linux is good enough. People know what you mean when you say it. And these days GNU makes up less and less of the core packages that most distros run anymore.

Also the copy pasta that this all stems from explicitly calls out eliminating nonfree programs which most popular distros do not do these days:

Making a free GNU/Linux distribution is not just a matter of eliminating various nonfree programs. Nowadays, the usual version of Linux contains nonfree programs too. These programs are intended to be loaded into I/O devices when the system starts, and they are included, as long series of numbers, in the “source code” of Linux. Thus, maintaining free GNU/Linux distributions now entails maintaining a free version of Linux too.

And they even link to a vanishingly small number of approved free GNU/Linux distros. Of which non of the mainstream distros are listed. So can we really label anything not on that list as GNU/Linux?

Not sure this type of thing is useful to a broader audience. It is specifically for those that own chisels and/or planes to help with setting things up for sharpening. Anyone in that space who owns a honing guide and set of sharping stones will find it fairly obvious how this functions from the given details and pictures. For anyone that wants to sharpen a chisel or plane blade and does not yet know how there are a lot of guides out there that will go over those details where this device is only one small optional part of the picture - at which point the intent for this device becomes more obvious.

It is about WPEngine not contributing enough back to Wordpress, in terms of development effort or money. Apparently the trademark is the only legal grounds they have to go after WPEngine to try and get them to contribute back more.