> Good grief. Java and C# both allow for multiple interfaces, which is very closely related. That's the majority of use for multiple inheritance in C++. It's more or less nonsense to talk about that in JS anyway since it's fully dynamic and duck typed. You can completely smoosh two objects together. You can fuck with the prototype chain (even at runtime).

The other option here is to use nested, or even anonymous, classes, at least in Java. It can be ugly but objects of the class can have methods that return different representations of themselves that can all access the same underlying object's private variables and methods. In Java this is done quite elegantly (that's not a phrase you hear very often), Alas AFACS it's not implemented directly in Rust, so you'd need a lot of glue code to achieve the same thing.

Are nested classes better? *shrug* I guess it's more explicit and there's less risk of a name clash if the objects you're inheriting have similarly named methods/properties that do not work the same way? And from that point of view it could be argued it's a superior option to regular multiple inheritance, if the language supports it as well as Java does.

I'm half way in agreement with OP about MI. I don't think it's an anti-pattern so much as something easily abused and hard to do well. So I rather like Java's approach here. There's probably some edge cases where C++ will allow something that Java wouldn't, but I don't know enough about C++ to comment. Can you specify the type of a parameter to require two different classes? It's about the only thing I can think of.

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.)

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://fil-c.org/ 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?

You're confusing C++ with C. C doesn't have "smart pointers" and any attempt to graft something onto C that makes pointers trackable makes it exceptionally inefficient.

There is a C compiler out there, Fil C, that makes use of the UB that exists because of the desire to support capability architectures (it doesn't use capabilities, but early versions emulated them in software, the language evolving over time) that tracks pointers and includes block/length information with each pointer. It works, can superficially compile any C program (but the program can't rely on conventional assumptions about UB) but it's slow, it's obviously very inefficient with memory too, you wouldn't want to use it as a replacement for Rust. It both proves you can implement memory safety in C, but also that it should seriously only be used for that legacy C project that costs too much to rewrite.

I'm not really seeing much of a reason for dumping Rust in favor of grafting Rust-like crap onto existing unsafe languages other than smug dislike of any restrictions on code, and the implied "You make mistakes", that Rust's handholding does. It works, and attempting to graft more crap onto C and C++ isn't going to make them more useful.

This is not to say Rust is perfect. Arguably it needs a "C#" to Rust's "Java", a language that's learned from its mistakes and implemented something cleaner. Perhaps even a language that's not so ideological, allowing GCable objects but with the flow of object creation/destruction more explicit so those cases where a millisecond of unexpected stop-the-world object marking would cause timing issues can be avoided.

I'm in agreement this is generally where Rust needs to head. "unsafe" needs to be something 99% of projects will never ever use. It should be so rare that even third party crates that use unsafe code, or are dependent on unsafe crates, have to be explicitly loaded using a "extern unsafe crate" command.

To get there what Rust actually needs is a proper, Java-level, basic system library. Not just for system calls and multithreading and singletons and whatever, but also implementations of secure algorithms and protocols like SHA hashes and TLS sockets. The kind of thing you want to be able to trust, and not have to worry that the third party wrapper around OpenSSL might contain some bug or even in intentional exploit that hasn't been properly vetted.

That, alas, is very, very, very much what the Rust community opposes. Nonetheless, I think they need to take a second look at that.

> The Rust people are learning this lesson too. You don't break code that works. You don't rewrite adequate code just for the new shiny. If you want to stay in business, that is.

OK Rust critics, you can't have it both ways, either Rust people are rewriting everything in Rust or "you can't rewrite adequate code just for the new shiny". Pick one.

Truth is Rust is being adopted for new projects where memory safety is necessary, and for the most part that's good enough, especially as major systems do tend to get rewritten or obsoleted-and-replaced every five-ten years for the most part.

Whether this is good or bad depends on how far you trust the Rust ecosystem - I'm seriously bothered by the crates.io system and the lack of any curation or oversight right now, given that the unsafe keyword isn't considered a dealbreaker (and is often actively encouraged for situations that could be safe code.) In the light of the XZ utils breach (thankfully not crates.io, but show me why crates.io isn't vulnerable to the same kinds of attack, perhaps even more so), developers need to be a little more conscious of the need to vet third party dependencies, and Rust is hurtling in the wrong direction on this.

Rust is a good idea, but this roadmap shows little understanding of where Rust's weaknesses are. Indeed, it demonstrates, to me, the serious problem there is with the community around the language, as there's no way this drivel would have been announced had its community had any self awareness.

It's a black hole, the diameter is 0. You can safely assume it's mass.

EDIT: Yes, people who are wrong all the time, I know some report the diameter as being whatever the diameter of the event horizon or Schwarzschild boundary is, but scientists don't, that's not actually the diameter, they'll tell you the event horizon or Schwarzschild boundary diameter if you ask, but they won't claim it's the diameter of the black hole, so shush.)

EDIT2: Yes, I also know it's generally the "Schwarzschild *radius*", but "the diameter of the Schwarzschild radius" just looks bad to me. Again, shush.)

EDIT3: Yes, I know Slashdot doesn't have an edit button... or does it? Could I be testing a hidden feature? Maybe I'm a beta tester for a revision of Slashcode? Or maybe I just right clicked, inspect element, found the edit button, and removed the style="display: none;" tag on it? You'll never know.

> I think you underestimate how far the country has moved and how quickly. You underestimate the degree to which sexism is a thing of the past and you underestimate how accustomed to a total lack of professionalism in governance we BOTH the first Trump administration and the following Biden Clown show complete with its klepto-cross-dressers had made us.

I think you're trying desperately to pretend the world is something different to what it is because he's right and you're wrong.

Sexism is not a thing of the past. And I've literally heard people say they were voting for Trump because they didn't think the country was "ready" for a female president. On top of that, after decades of the country moving towards equal rights, we now have a regime that many Gen Z men literally voted for because they were told women had too much power and needed to be taken down a peg. Sexism, homophobia, and racism have been so obviously coming back as major movements I'm surprised anyone with a straight face would claim that sexism is a thing of the past.

As for your complaints about Clinton and Harris, both were highly qualified for the job, and as unlikeable as Clinton might have been, how could she possibly be considered less likeable than Trump?