Mond_

Not OP, but I've had the same conclusion. It's a bit cheeky to call it a puzzle game, but I don't think it's strictly wrong.

Imo it's better to approach Demon's Souls as an exploration puzzle game with RPG stuff and combat, not as an action RPG (such as Dark Souls 3).

No shade thrown, but I always preferred my game with some amount of story or artistic ambition beyond mere puzzling.

I'd take Void Stranger or probably even Deadly Rooms of Death: The Second Sky over Stephen's Sausage Roll any day, I imagine.

I don't think that's what that word means.

really?

So, where can I buy a handful for personal use?

I think that a "minimal viable baseline" type implementation should not break the ODR.

In Rust these types of proposals are common, in C++ less so. The incredibly tedious release process encourages everyone to put in just as much complexity as they can safely get away with.

Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations.

(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.

This is begging the question. Yes, but why did they do that over dedicated syntax?

(My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

This is such a silly response when "You've gotten better at using them and know how to work around their flaws now." is right there and seems a lot more plausible.

Manjaro sells itself as "Arch, but more approachable". In reality, you'll often end up with "Arch, but with additional weird package management upgrade issues that are a byproduct of Manjaro's own repositories interacting with the arch on your system."

Instead of just having to track the arch repos, you suddenly have those and Manjaro's own stuff (and own package manager tool etc.), which is another point of failure. Every new bit of technology is another part that can fail.

I used Manjaro for a few years.

That's how I learned a pretty important lesson about software engineering that still informs how I work to this day.

"A layer of abstraction on top of a stateful legacy system often doesn't result in a simpler system, it just introduces exciting new failure possibilities. This especially applies when the owners of the legacy system have no responsibility over the abstraction layer."

I think a lot of the really old school people don't care, but a lot of the younger people (especially those disillusioned with C++ and not fully enamored with Rust) are in fact quite happy for C to evolve and improve in conservative, simple ways (such as this one).

The tradeoff Go made is that certain code just cannot be written in it.

Its STD exists because Go is a language built around a "good enough" philosophy, and it gets painful once you leave that path.

Bad news, John Google told me they already quantized it immediately after the benchmarks were done and it sucks now.

I miss when Gemini 3.1 was good. :(

OpenAI has a whole history of trying to scoop other providers. This was a whole thing for Google launches, where OpenAI regularly launched something just before Google to grab the media attention.

why call him that when "saltman" is right there

It's worth pointing out that the two examples that you're writing are actually strictly different, and not just "better syntax for the same thing". (This is assuming `String | Int` works as in Python, and the second example works as in Rust.)

To understand the difference, `String | String` is just `String`. It's a union, not a sum type. There's no tag or identifier, so you cannot distinguish whether it's the first or the second string.

If this sounds pedantic, this has pretty important ramifications, especially once generics get involved.

Sounds like it might be an issue with your setup, considering that other people have no problems running it. Hard to tell what the problem is, but definitely a frustrating situation.

I love how the haters of Rust's syntax can be roughly divided into two groups:

(1) Why doesn't it look like C++?

(2) Why does it look so much like C++?

Strong +1, Void Stranger is amazing and has a spiraling depth that just keeps going and going.

Interestingly, Google already donated its own AgentToAgent (A2A) protocol to the Linux donation way earlier this year.

Pixel hardware is below average? Since when? That sounds like a flagship phone to me.

Huh? Rust is just an example here. What I am saying is that you're just redefining float to mean NonNaNFloat.

This is fine, I guess, but it will cause a bunch of problems since e.g. Division of two floats has to be able to return NaNs. At that point you either need to require a check to see if the value is NaN (inconvenient and annoying) or allow people to just proceed. Not sure I am exactly sold on this so far.

What exactly do you need that Zig doesn't have? Inheritance?

Meh, you also see algorithms that have subtle bugs because the author assumed that for every integer x, -x has the same absolute value and opposite sign.

I view both of these as not great. If you strictly want to rely on wraparound behavior, ideally you specify exactly how you're planning to wrap around in the code.

This is a bit confused. You're saying `float`, but a float comes with NaN by default. Any float can take NaN values.

If you actually want the compiler to check this on the level of the type system, it'd have to be `NonNaNFloat | NaN`. Then you can check which one you have and continue with a float that is guaranteed to not be NaN.

But (importantly) a NonNaNFloat is not the same as a float, and this distinction has to be encoded in the type system if you want to take this approach seriously. This distinction is NOT supported by most type systems (including Rust's std afaik, fwiw). It's similar to Rust's NonZero family of types.

Yes, and it's good that way.

Please, anything but a dependency injection framework. All parameters and dependencies should be explicit.

What is wrong with that guy in the comments shouting? Christ on a stick, this is the worst crash out I've seen over something like this

> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.

How does Rust not address use after free?