Yes, it's called "D-K Posterboy-itus".

Congenital, I think.

Meet Pop.

It wouldn't avoid any of the hassle of Rust, it'd basically be Rust but with fewer features and a slightly more C like syntax.

100% of the problems C people have adapting to Rust are to do with getting their head around the borrow checker/lifetime model. Everything else is very straightforward.

(I'm not saying Rust is without flaws, it has plenty, but they're nothing that's not in C too.)

These sorts of theatrics exactly.

...not because it does.

It's all about gatekeeping the skill, time, and budget floor and propping up the wall between "producers" and "consumers". I worked hard to get where I am, therefore it shouldn't be made easier. I worked hard to make $20/hour, therefore we shouldn't raise the minimum wage. Etc.

The reason there aren't legions and legions of programmers protesting AI on twitter is because programmers are accustomed to change and we've learned to embrace it, yet every time there's a technology that changes how art is made (cameras, digital painting, 3d rendering, even pre-made pigments), there are a group of artists who flip their shit and say that the new technology is going to kill creativity and ruin art as we know it, then fifty years later all of the things that those people insisted are "not art" are in museums and art history books.

I hope a company in China gets ahold of the database and trains a good music generator AI on it and releases it for free.

Smart devices have been spying on you for years now. Don't buy a fridge that spies on you.

To be honest, what I've described above doesn't really have to do with that or involve jumping through hoops. C++ programmers would program in a similar way (use references as function arguments, return whole objects). It's different from Java where almost everything is a pointer, but it's what you'd expect from a language that's trying to be as C-like as possible.

What they generally mean if they say that is that with Rust you're constantly having to tell the compiler what the lifetime of a reference to an object is, so it can verify and make sure the object pointed to really will last that long or longer, and if you want objects that aren't owned by the function or object that created them, you have to explicitly tell Rust how you want them stored. The syntax to do all of these is ugly, though the lifetime syntax is similar in some ways I suppose to generic typing.

A lot of learning Rust, for me, was trying to get my head around its memory model, which TBH is usually what I learn programming. I have no problems maintaining C# code because I learned Java a long time ago, but Rust was very different. C++ programmers wouldn't have a problem with it because it's doing things the way they're used to, but someone coming from a more liberal language like Java or a modern scripting language is going to feel like it's restricting.

But ultimately if you had to port a Java program to Rust and keep the logic as is, you can actually allocate objects on the heap if you really want to return things. The syntax is ugly, but you can continue to use the same algorithms and code structure you used before. It's uglier though.

Neither Flatpak nor Snap, for all their faults, are distro specific. Indeed that's half the fucking point, every app installed using them comes with its own copy of a stripped down operating system.

So perhaps advocates for this crap could start again and explain how it differs from Flatpak and Snap?

Aw bless your heart.

> The logic is that the receiver of an object is normally the one that wants to manage its lifetime, so it must receive the entire thing as an object - that is, the entire object, the entire block of memory containing the individual characters. Conversely, a function that receives a string isn't managing it and doesn't (usually) need a copy of it, so you'd want to point it at the string to have things happen to.

This is ugly, let me see if I can clean it up a bit:

The logic is that the receiver of a fresh new object is normally the one that wants to manage its lifetime, so it must receive the entire thing as an object - that is, the entire object, the entire block of memory containing the individual characters.

Conversely, a function that uses a string (ie is passed in as a parameter) isn't managing it and doesn't (usually) need a copy of it, so you'd want to point it at the string (that is, pass a pointer), rather than pass the entire string object or a copy thereof, to it.

The question I have for you is what makes you think, once you've added features to C to deal with the issues related to what you removed, you'd end up with a less complicated language than Rust or Java?

To be quite honest, ownership and lifetimes are what makes Rust feel complicated to a new user. The rest of it is pretty straightforward. It adds some OOPS stuff which is straightforward and ignorable if you don't like OOPS for some reason.

The complex stuff though? Those are what lifetimes and/or the borrow checker forces Rust to have. Plus closures, which are necessary if you're going to replace function pointers. You forgot about those huh? ;-)

I think people asking for a "safe" version of C are ignoring the fact that Java, C#, Rust, and Go, all are ultimately different groups of people saying "How can we make something like C safe". The reason those languages are often more high level is because making them high level allows you to make them safe without impacting speed. Java/C# are oddballs, they require an OOPS development mindset, but nothing stops you from programming in a subset of Rust and Go if you don't want to go OOPS. Just be aware that's where the complexities are - the non-OOPS stuff.

Unfortunately the person responding to you is a fucking asshole and precisely the reason sites tech people get a bad rap.

I agree it's fairly confusing, especially as &str would seem to be better as &String. But there's a logic to it.

& is, obviously, a reference (same as in C.) str is essentially the base type of Rust's string types. And String is the main Rust implementation of strings. ie it "extends" str.

As a general rule, things that return things return Strings (or strs.) Things that need parameters OTOH usually need &strs. The logic is that the receiver of an object is normally the one that wants to manage its lifetime, so it must receive the entire thing as an object - that is, the entire object, the entire block of memory containing the individual characters. Conversely, a function that receives a string isn't managing it and doesn't (usually) need a copy of it, so you'd want to point it at the string to have things happen to.

Like Java, the language has some behavior that's confusing to newcomers because how it acts reflects the underlying model. Java newbies often get confused by what they think is "pass by reference" for function calls (PBR is something slightly different, but...) because Java deals entirely in pointers to objects (with the exception of the base types int, char, etc), and you pass pointers (or aforementioned base types), not objects, to and from functions. Rust's model is a little more complex: you are in some cases actually handling raw objects, and in others passing pointers to and from. Obviously passing full strings to functions is ugly and inefficient and Rust doesn't encourage it, but it nonetheless exposes that way of thinking.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Ffil-c.org%2F does this (no, really! They made use of UB's "We might end up wanting a C compiler to run on a System/38" justification, but the issue you're going to have is its all immensely inefficient with both memory and speed. And ten to one I'll bet the people arguing they "just want a safe C" are arguing that because they think C is the most efficient programming language ever and don't want to program in something "less efficient".

Truth is hardening C is hard, it's like trying to harden assembly or FORTH. You need to bite the bullet and admit that you need a different approach, one that's higher level, if you want an efficient language that's also hardened. The secure languages that are "We had C, what would eliminate whole categories of problem" ended up being Java/C#/Rust/Go for a reason, just as the secure language that was influenced by FORTH was PostScript.

Fil-C exists if you want to harden your existing C code (as long as it's not dependent on UB), but it's relatively slow.

There's also a new language called Trap C, covered by Slashdot in the past, that is supposedly a hardened version of C.

So, you really have two choices: you can inefficiently use the language you know (Fil C), or you can learn a new language (Trap C) that looks a bit more like C than Rust does. I know ahead of time you're going to reject the first one - Fil C is great for legacy code, but the performance overheads are a dealbreaker for new code. The second though... what's the point? What possible advantage do you have learning a new language that looks like C but isn't compatible with most existing code, when Rust has more features?

And before you complain about bloat or anything like that, remember that C isn't an OOPS language. You're using lots of hacks using it in its natural form, many of which rely upon unsafe behavior. A big part of why languages like Java, C#, Rust, Go, etc, are safer isn't that they implement memory safety, it's that, for example, a closure managed by a language is a lot more secure than a function pointer. The functions that modify a data structure are a hell of a lot more secure implemented as methods on an object than a module working with a single block of memory or, worse, pointers passed in to each function.

Languages that allow you to express precisely what you're trying to do at a high level are inherently more secure than languages that require you to micromanage the assembly instructions the compiler will output. We can have an argument over whether C++ is more secure than C, as the former's complexity and multiple ways to do the same thing undermines that to an extent, but the same cannot be said for Java/C#/Rust/Go which are largely minimalist in comparison.

What are you trying to achieve here that wasn't the goal of the creators of Java, C#, Rust, and Go, and can you be sure you wouldn't ultimately make the same decisions that lead to them creating languages you've rejected for some reason?