If it happens all the time and it's positive, you shouldn't need a news story to confirm it. People should just be able to think of examples.
Certainly I'm able to think of plenty of terrible results from private equity take-overs from my own personal experience as an employee or as a customer.
Private equity gets a bad rap in large part because the stories they're most famous for are the "PE buys a failing company, and the company subsequently finally fails," with the "failing" word conspicuously absent in most retellings. I'm not sure I've heard one of those stories where the company failed after being acquired by PE where it wasn't already failing before the PE takeover...
For me, private equity gets a bad rep because they've bought up all of the local mom and pop shops for just about any service I need thats face to face. All of the plumbers, electricians, general contractors, vets, grocery chains, coffee shops, and other shit were bought and had every ounce of revenue squeezed out of them. The result? All of the things I need locally cost 3-5x they did and the service is far worse.
And as a quick edit: none of these examples I have were of failing businesses. Each of the owners had their reasons, but none was due to it being necessary for survival. PE on hackernews tends to focus on software/bigger purchases, but so much of the damage in my opinion is on the local and smaller scale.
What PE loves to do (and where I think a lot of the vibe comes from) is buying companies from owners who care about the craft and turning them into companies that care about nothing but money.
Let's say you make an app for first responders. Being a former first responder, you know exactly what your users need and what the workflows should be like. Your app becomes a brand name in the community. You charge enough to survive (if that), because your app is a labour of love more than anything else.
Eventually, family and other responsibilities get in the way, and you just no longer have the time or motivation to maintain the app any more. You sell to "we so swear we are not private equity" Applause.
As soon as you do that, the app gets taken over by financiers and developers who are experts at "revenue optimization", with little domain knowledge about what first responders need. They calculate (probably correctly) that they can milk their customers for a lot more if they move to a subscription plan, gate some features behind expensive premium packages, stuff the app full of upsell pop-ups and fill it with analytics SDKs that tell them which features are worth spending development time on, and which can safely be removed.
I didn't have any specific app in mind (I have stories but not with this specific industry); I brought it up as an illustrative but hypothetical example of the broader phenomenon.
Well, many things may be going wrong before PE gets involved, or the owners may be retiring and it just will never be the same again even if PE didn't buy. So it's more likely to feel like bad news even if it was still a reasonable outcome.
As a public, well-known example, Dell being taken private in 2013 seemed to work out.
I'd guess the majority of those success stories are invisible to the end user.
e.g. simply keeping the company afloat via PE cash.
If I recall correctly, this is what happened to Hilton Hotels. They were collapsing during the housing crisis.
A slightly different scenario but Hertz is a PE success story. It was owned by Ford and bought by a private equity firm. Now it's a standalone company making mint.
Were those roll-ups though? I see a poster below says the private equity fund was only involved for the last acquisition, but no one can deny Muse Group/Ultimate Guitar went on a shopping spree. They looked like they were trying to gain control over a whole segment and start squeezing (well, except for that open source projects aren't that easy to squeeze). No wonder people freaked out over the telemetry, it was reasonable to fear the worst. But everything went better than expected.
>If it happens all the time and it's positive, you shouldn't need a news story to confirm it. People should just be able to think of examples.
Most enshittification I am familiar with is because I read it in the news, therefore if non-shittification does happen it is likely I do not hear about it. I suppose the same holds true for other people.
If you were correct and people just had to hear about it then people wouldn't go around worrying about violent crime, because of always seeing on the news, despite it having fallen to historic lows. Instead people should be just walking around talking about how safe and non-violent the streets are nowadays.
Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.
It's not the same thing as allowing some AI contributions under strict guidelines.
Even worse. They don't even have AI review them. I fed the commits that introduced the problem to a few frontier models and they saw several problems, including the aforementioned security problem. Even Mistral saw it. I did have to instruct all models to look for security problems, though, but still.
It's not that we shouldn't use vibecoded distros. It's that we shouldn't use badly vibecoded distros with shitty or non-existent processes.
On Lex Fridman recently DHH was enthusiastically bragging about how he was letting AI generate C++ that he intentionally wasn't even looking at, he was treating it as a pure black box and just submitting the output.
It's not strange to ban chess computers at a chess tournament, and it's equally not strange to ban AI code on a code hosting platform.
The costs involved with hosting a bunch of vibe coded stuff that no one is really invested in or cares about would undermine the mission of Codeberg, so it makes sense for them. Other code hosting platforms can go a different route.
How much does it cost to host a few text files in the same way a bunch of other text files are already being hosted? Particularly if there's no investment - ie no significant traffic - in accessing said text files?
At large scale, it probably adds up.
Remember that they also need to ensure backup, etc.
Whether or not your code is being "used" or not, it has a cost.
Even GitHub has been struggling last year with the ramping amount of LLM produced code. I can imagine that it is a real issue.
They already encourage users to use 'agit' instead of doing 'physical' forks.
I imagine that the costs are sufficient enough to motivate them to follow through on this; on top of the ethical and legal concerns.
---
Why don't you host your own git for those dormant projects?
It's really easy, you don't even need a forge. Just a bare git repo on server via ssh and you off to the races.
I think their stance is fine; there are other providers if you don't agree with this.
They aren't doing anything "at large scale" that would matter as such. It's not like they're working with MBs of storage, and even then a single 1.44MB diskette can still store a heck of a lot of text (yes, I used to use those).
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".
You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.
Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)
Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.
I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)
Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.
I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.
A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification.
Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.
It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.
And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.
All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.
Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated.
I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could actually run or not vs crashing out part way through.
Andrew Kelleys original motivation for creating Zig was language that allowed precise low-level control for real-time audio processing.
"Kelley describes why he created Zig, when other options including C, C++, Rust, and Go already exist. He said he set out to develop a digital audio workstation. He tried Go, but found interoperability with C libraries difficult, and said the garbage collector caused audio delays. He tried C++, or coding C-style using a C++ compiler, but found that small mistakes led to memory corruption bugs that took weeks to fix. He tried Rust but "really struggled to write code that would satisfy Rust's rules," and spent a month trying to make font rendering work."
I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)
I do this in Unity because allocations/GC cause hitches.
it's pretty normal thing to do there's even the built in pooling libraries so you can pre-allocate 10,000 gameobjects when the game starts.
I haven't played with ECS/DOTS yet but I assume it does something similar.
I do. The only thing I need dynamic allocations for is queues of asynchronous events, and that's just because I'm too lazy to calculate an upper bound for how many there may be.
> Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs.
Give it a few years! I've noticed an explosion in interest in formal verification recently, especially since nowadays the bar to entry is so low: just ask your LLM agent to give it a go.
Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.
Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.
Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.
The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.
Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.
Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA
the buffer managemnt is just different pattern and style of code thats more low level. when you care about performance and cpu cache, you have to make sure that actual physical memory gets computed at same time as other memory near it so there is less latency.
the primary motivation isn't latency but complexity. People do in some applications free or allocate collectively because they have interrupt times in mind, but most of the time when you manually manage memory the issue is mental overhead, so people gravitate towards models they can keep in their head.
Allocating in large chunks is often not very performant which is why people came up with tools like the borrow checker, you often want to allocate and deallocate dynamically on a need-basis but that's exactly where bugs occur.
you only malloc only once at boot in that pattern, its not about performance at that point. after that you need a strict api and patterns to control and process the data that is where the performance matters...but its niche just like you couldn't want to code a ui from scratch in rust when u could just do a web ui w/ typescript,react tailwind or whatever
People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work. That's why newer languages, with the notable exception of Zig, prefer more advanced memory management methods.
> People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work.
Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the popular notion it can't be done is backed only by incomplete anecdotes.
Should everything be written in low-level languages? No, that would be absurd. Is it a simple fact of life that not every person/team/organisation is capable of meeting certain standards of rigour? Yes. That's not to say anyone in the Bun team could not become sufficiently competent in the future. For whatever reason, current experience, incentives, and personal motivations did not make for a conducive environment to make Bun watertight in Zig.
Yes, it's possible. It's also possible for experienced pilots to fly an airliner completely manually for the full duration of a transatlantic flight without crashing. Still, over the last decades, autopilots and other assistance systems with ever more sophisticated features have been developed, and I would argue that without this technology crashes would be much more frequent than they are today. Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
> Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.
Just people like the linux kernel, all major browsers, most of our popular webservers, etc and basically all non-trivial software projects written in C.
The good news here is that we have more than just anecdotes to support this, we have empirical evidence.
That's like saying that they should have used assembler but they just weren't capable of it. It's personal insult dressed up as a nonsensical technical argument.
It matters what software you're writing. When it's a JavaScript runtime, it's not as if you can get away with preallocating all the memory you'll need like some games used to do.
I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.
You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Could you actually? That seems like a bad fit for a JS engine to me. Predictable memory requirements are great when you can have them, perhaps you can avoid complexity then, but for a JS engine?
Swift is very weak outside Apple ecosystem, compared to Rust. Not sure nowadays, but Swift used to have breaking changes each major release, that's a non go for a big project.
Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.
Swift is one of the few toolchains that actually has some kind of builtin C++ interop, alongside Objective-C++, D, .NET (via C++/CLI), Carbon (eventually).
He just wanted to use LLMs for coding, and not enough training data on Swift code exists for his use case. Admitting to that would be rather silly, so here we have this sentiment now exist rent free in people's brains.
The C++ interop of Swift is perfectly fine, to such a degree that FoundationDB is now using it effectively alongside its C++ origins.
This reads like cope because you're re-inventing RAII from first principles.
I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.
That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.
This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.
I've argued elsewhere some things that are wrong with RAII and C++ objects in general.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?
I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).
You keep "asking" for evidence but the only evidence presented by yourself is that you have merely surface-level understanding of the subject matter, and are looking for arguments, not insight and critical examination.
It's your claim that destructors are harmful so the burden of proof is on you.
People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate, which require no explicit cleanup once the destructor is implemented.
This is the opposite of C where even though the resource cleanup needs to happen on scope end, it is not automatic, and so becomes a source of bugs. This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
This automation also removes boilerplate so there is less management that needs to be done when using data structures.
> It's your claim that destructors are harmful so the burden of proof is on you.
I have given a variety of arguments why I think the C++ RAII specifically has downsides. You can accept them or ignore them, but don't act like I didn't give arguments.
> People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate,
Once again you're explaining beginner C++ do me. Are you still doubting if I understand this argument? My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs. This is scripting and plumbing. It's not interesting to me. Systems programming is not so much about stack scoped lifetimes.
RAII systematicing object lifetimes and cleanup, thus enabling exceptions and implicit or uncontrolled control flow, may sound nice on paper, but turns out we shouldn't want them in the first place. What RAII leaves for me is a system that will automatically call nested object's destructors when I delete something. It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.
> This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.
If I were you, my response would be: The burden of proof is on you, show the evidence. But my answer is, yes that is right, but everything is a tradeoff, and the issues caused by manual cleanup are also somewhat exaggerated by C++ people, and the issues caused by blindly buying into the corset of C++ types are not well understood by C++ zealots (I've done my best at explaining them).
Issues caused by C approach are also a matter of design and approach to programming in general. It also depends on the actual problem you're solving. The linux kernel for example doesn't exactly have the easiest or most beautiful code to follow, but surely it's one of the most technical codebases out there, one that solves difficult problems (performant resource multiplexing for programs that it doesn't even know). On the other hand, the debugger code base I've referenced doesn't have any gotos for example, nor even early returns (or almost none, not sure).
Find me a single example of programs that run as fast and are as productively maintained as these two codebases in their respective areas? I believe there aren't any.
This should be plenty evidence to a reasonable mind, but that isn't you.
I have given a variety of arguments why I think the C++ RAII specifically has downsides.
I don't think you did, I think you just said it has downsides over and over.
Once again you're explaining beginner C++ do me.
Don't ask for basic knowledge then get upset when you get it.
My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs.
This is what the vast majority of values have. Some escape one scope and get cleaned up in another one. This also includes values inside data structures.
It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.
Again, this isn't an explanation, it's just you saying "I don't think it's good, I don't like it", but you aren't explaining why. This isn't evidence, it's just you restating "this is bad". Why is it bad? "I told you it's bad!!".
thus enabling exceptions and implicit or uncontrolled control flow
Exceptions aren't uncontrolled flow and you can also not use them. Something else being enabled doesn't mean the unrelated feature is bad. This also implies that every other language that isn't C is terrible because they have some sort of automatic cleanup. Now java and python are unstructured by your own definition?
If I were you, my response would be: The burden of proof is on you, show the evidence.
You don't have an explanation of why the burden of proof is on me. Everyone uses these techniques in system software now. You are the odd person out, that's why the burden of proof is on you.
I also gave you a very good explanation and you said "you're explaining basic C++ to me". I am, you asked for it and you didn't poke any hole in why it's wrong.
the issues caused by manual cleanup are also somewhat exaggerated by C++ people
It means memory leaks and crashes which everyone has been fighting for 50 years.
This should be plenty evidence to a reasonable mind, but that isn't you.
Someone running a marathon without shoes doesn't mean shoes are bad. Just because an old program is written in C, that has no bearing on if other tools are good or not. This is not a logical conclusion. Unix was written in C too, does that mean destructors are bad? No one said it's impossible to write a program in C now that C++ exists.
Why can't you give a single basic explanation instead of making the same claim over and over?
How about you do the following two Google (or AI) searches
"Please give me examples of great systems software written in plain C or C style procedural C++"
"Please give me examples of great systems software written in modern C++, as opposed to procedural C style C++ or plain C".
Why does it seem like the majority of core infrastructure, like Linux kernel (also vast parts of Windows/Mac OS), PostgresQL, Sqlite3, Git, OpenSSH, GCC, but also e.g. MS Office/Excel, are written in plain procedural code and not in modern C++? For the latter, I get stuff like "ScyllaDB NoSQL database" or "Envoy Proxy" or whatever, what is that even and why should I care or how do I know they're actually technically solid products and not just hype?
My claim: The arguments that I've given (but you keep insisting I didn't give them) play a huge rule in why that is so. You can use C++ RAII for plumbing and high-level stuff. But if you try to actually implement technically interesting things, it won't help you at all, it's just getting in the way.
How about you do the following two Google (or AI) searches
Why don't you do it so you can make your own argument.
Why does it seem like the majority of core infrastructure,
Why are projects started decades not using modern C++ that came decades after they were started?
This doesn't have anything to do with destructors.
The arguments that I've given (but you keep insisting I didn't give them)
You didn't give arguments, you made claims based on other people doing something different decades before modern C++ existed. Someone managing to dig a hole with their hands doesn't make a shovel a bad tool. Animals dig holes all the time, people are better at it.
But if you try to actually implement technically interesting things, it won't help you at all, it's just getting in the way.
This again is your claim which you haven't been able to explain in any way.
> I don't think you did, I think you just said it has downsides over and over.
Show evidence of your claim.
> Don't ask for basic knowledge then get upset when you get it.
Where did I ask for basic knowledge? You are hallucinating. I've repeatedly and explicitly told you to shut up explaining beginner things. You are trying to refute my criticisms of RAII with your silly explanations of how RAII works. That's not how an argument or "evidence" works.
> Exceptions aren't uncontrolled flow and you can also not use them.
I would rather call it _implicit_ flow but they also lead to losing control over control flow because of that. Yes, I can just not use exceptions, and also avoid gotos and use them in a principle way, and do cleanup in a principled way. And then I can also do without RAII and without all the baggage I'd have to buy into in order to use it.
> You don't have an explanation of why the burden of proof is on me.
Please p* off man. You're being ridiculous.
> It means memory leaks and crashes which everyone has been fighting for 50 years.
Like you have been on your Linux, Windows, or Mac machine? Maybe you are running a linux machine with an uptime of weeks, months, or even years?
> Someone running a marathon without shoes doesn't mean shoes are bad.
You claiming to run a marathon with a 25kg backpack doesn't mean you don't lie, and it also doesn't prove running without it isn't the better approach.
> Why can't you give a single basic explanation instead of making the same claim over and over?
The only person not giving explanation beyond basic boring introductory C++ RAII school, that's YOU my friend. I've been giving a lot of explanations what I think is problematic, somehow it seems you're mentally unable to acknowledge them.
> I don't think you did, I think you just said it has downsides over and over.
Show evidence of your claim.
That would be proving a negative, which is another logical fallacy.
Please p off man. You're being ridiculous.*
If that were true you could explain why.
I would rather call it _implicit_ flow but they also lead to losing control over control flow because of that
But it's just running something you need to run anyway and it's optional. Destructors don't need branching, they can just run a single function like free.
And then I can also do without RAII and without all the baggage I'd have to buy into in order to use it.
Again the "baggage" is the part you can't seem to explain.
Like you have been on your Linux, Windows, or Mac machine? Maybe you are running a linux machine with an uptime of weeks, months, or even years?
Are you trying to say people never write memory leaks or forget to clean up resources in C? Something being done with huge amounts of efforts doesn't mean a better way to do things is bad.
You claiming to run a marathon with a 25kg backpack doesn't mean you don't lie, and it also doesn't prove running without it isn't the better approach.
This doesn't mean anything. Now you're trying to say (without evidence) that someone is lying? Destructors don't add any size to a program.
Is this your only argument after dozens of messages? Running a function with no branching destroys control flow and running a tiny function that runs what you need to call anyway is bloat?
I've been giving a lot of explanations what I think is problematic,
No, you just said it's problematic over and over, that's not an explanation.
this is obviously bs, the lawn thing is mostly a north-american obsession. most people here in europe like shade and thus higher vegetation in their gardens.
European upper class was obsessed with lawns first. Like other forms of decorative gardens, it was primarily a status symbol. The intended message was something like "Look how we can afford this land we don't actually need! And look how we can afford to pay others to make it aesthetically pleasing!"
But once there were public lawns in cities, people found practical uses for them. Many popular ball games are still played on surfaces that resemble a lawn.
That same distinction makes sense for private lawns. Do you have a decorative garden, because your lot is larger than what you actually need? Or is the lawn a practical surface for open spaces you occasionally use?
OK, but that doesn't mean the comment I replied to is any less BS. What I pointed out is that if there was such a deep preference for short grass, you'd expect this globally. And this is simply not the case, empirically.
Zig is adding native vectors including operator support, there are some recent issues/prs about this topic.
The general technique of SoA is pretty useful both in games and other applications, but of course I cannot speak to the specific use-case you are describing.
Zig vectors force data into SIMD registers even if that would make the code slower. They're a specialty type. You should only reach for vectors if you would have used SIMD intrinsics in C for example.
Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for architectures that do not have SIMD instructions.
That being said, the parent commenter is actually referring to other recent proposals as opposed to existing `@Vector` functionality:
If a business legitimately needs such information to operate, isn't it borderline impossible to 100% prevent it from leaking? If the data is there, it can be compromised either by technical means or non-technical means.
The primary issues in my opinion are (1) businesses collecting and holding on to information they don't need and (2) businesses getting so large that they become prime targets by default.
In a world where pointless data collection was disincentivized and there were many small businesses instead of a few large ones, this problem would be much more localized and addressable. But of course this is a dream within a dream.
I'd also add a third issue to this list: data retention. Too many companies I've dealt with have privacy policies that state something to the tune of "we'll hold onto your data for as long as required" without giving much of an explanation as to how long "as required" is.
Which usually means until the financial incentives to remove the data outweigh the incentives to keep the data. Data is more valuable than database storage costs, thus there is no incentive to remove the data. Policies should therefore be in place to punish unnecesary data retention.
There is a vast difference between it not being 100% impossible and data holders not doing the absolute basics to keep it safe.
I could imagine if, after a data breach, there was a government-run cyber investigative task force that would come into an organization, and be tasked with investigating and fully understanding the nature of the breach. We already have forensic detectives for other crimes, why not this one?
And if it turns out that the failure occurred due to the company acting negligently, a la (whoopsie all the records were in an open S3 bucket) then humans would be found personally liable.
--
But in principle, i also agree with the other causes you list. These are very much what GDPR was aimed at improving. It really is a shame when you look at what GDPR could have accomplished if not for malicious compliance by American tech giants, and shitty enforcement (instigated by American tech giants)
It doesn't even need to be government-run, we just need the right incentives. I've seen proposals for making some kind of data loss insurance mandatory to compensate victims. The insurance companies would then conduct audits which determine the premiums for the company, and investigate for negligence after a breach.
Edit: Thinking more about it, this would probably also be positive for security investigators. If a company is stonewalling you and ignoring a legitimate bug report, you now have the option to escalate this to the insurer. Maybe they could even facilitate bug bounty programs for smaller companies
I've had a similar thought in the past. I was thinking about the feasibility of a law being introduced where each company making over a certain amount of money per year must begin a VDP (and optionally a BBP) so that security flaws can be reported to them easily. This can easily be done by simply opening up security@companydomain and using security.txt (https://securitytxt.org). Reports must receive a response in N days, where N is calculated based on available staff, resource allocation, and revenue of the company. If they don't receive a response after N days, this can be escalated to some government agency which can take action against the company for failing to respond to a report on time.
I can say at least for me at a small-ish company (~40 FTE) there has been a surge in internal productivity tools. Nothing to improve the end user product directly but a lot of tools to make processes easier and less error prone.
What would previously be janky internal dashboards or excel sheets are now actually nice to use tools. That said of course the maintenance cost of all that has yet to be discovered, and the ROI is questionable.
Yeah this seems to be a pretty widespread story, from what I've heard as well. The thing about those janky dashboards and spreadsheets though is that somebody understood them and built them with intent to solve a particular problem. Despite the rickety appearance, they're trustworthy tools. A polished single page app might look nicer but it's harder to debug than an excel sheet, and much less transparent in its internal workings--especially if nobody actually wrote it...
About the same ~40 FTE team. We're doing the same thing. Smattering of internal tools, but no net gain in external revenue. Who knows which of those tools will have any value or ppl are just doing it because it's cool now to make fancy dashboards.
I think they should both not use it and talk about why so that we can get a clearer picture of the diversity of Linux users out there.
The idea of enabling proprietary software in the default install is apparently verboten to some, and getting that viewpoint out there helps people understand why Linux on the desktop is where it is.
well, it is in the "thoughts" section of the author's website. maybe it doesn't belong on HN, but the person who posted it is not the author, so take it up with them. anyway, i agree with most/all of the complaints but if a valuable point were to be made it is probably the funding point. why does this need money?
To your point, I don't think the complaining and ranting by the poster makes sense, given what was ignored before the ranting began.
the poster seems to have skipped over the point that "Omarchy" is just the default configuration of Arch for 37signals internal use, and enthusiasm over it working well caught on, so it's shared as open source.
CachyOS is another set of UI configurations of Arch and is also just handy.
It's a blog post, a medium where people can self-publish their writing for no other purpose than expressing themselves. These things have been around for decades at this point.
Realistically, polarizing figures like DHH will have complaints pointed at their work for reasons other than the work itself. And when the complaints are grounded they’ll often be of higher amplitude than otherwise.
Certainly I'm able to think of plenty of terrible results from private equity take-overs from my own personal experience as an employee or as a customer.