The wicked flee when none persueth.

Maybe she really worked at Carl’s Jr.

The first rule of the road is “right-of-way won’t help you when you’re dead”.

“Lefty Loosey righty tighty”

One arrow points up to the left, one points down to the left.

Thanks, I’ve save your comment. I haven’t heard of any of these.

It also has real type safety and thread safety.

Do tell.

Here’s some of my personal complaints. I don’t in general know how to fix them.

1. proc_macros need their own crate

2. generics cause problems. Many useful macros can’t handle them. Try using a generic that’s a complex async function, then pass a closure to it.

3. There’s this kind of weird mismatch where sometimes you want an enum wrapping various types, and in others generics. I find my data flows switching back and forth.

4. async in rust is actually really good, but go does it better. I don’t think rust could match go without becoming a different language.

5. Traits are just a big mess. Trait implementations with generics have to be mutually exclusive, but there aren’t any good tools to make them so. The orphaned trait rule is necessary to keep the language sane but is incredibly restricting. Just today I find certain a attribute macros for impls that doesn’t work on trait impls. I guess I have to write wrappers for every trait method.

6. The “new type” pattern. Ugh. Just make something like a type alias that creates a distinct type. This one’s probably easy to fix.

7. Cargo is truly great, but it’s a mystery to me right now how I’m going to get it to work with certain packaging systems.

To me, Rust is a bunch of great pieces that don’t fit together well.

Rust. It’s a qualitative improvement over the old ways.

The future won’t belong to Rust itself, but one of its descendants. Rust is too clunky to be the ultimate expression of its best ideas.

deleted by creator

There are also video games in libraries, and there are books in libraries with components that are unusable these days. Nobody is required by law to support these components in perpetuity. Nor is any publishing company required by law to maintain support for a book in perpetuity in any way.

Nor is anybody required by law to help you fix your classic car. People with classic cars spend tons of money to find spare parts or even get them manufactured. This is despite the fact that cars are much more of a necessity than video games.

Likewise, if you paid a video game to keep their servers open, or paid them for their source code, they’d give it to you. If you paid a smart person to reverse engineer the network protocol and write an equivalent server, you’d have your part.

Yes, and if you don’t like it you don’t have to buy them. It’s why I prefer not to use Steam.

If games have to be playable in perpetuity, then you can’t buy a game that isn’t playable in perpetuity.

But what is also unreasonable is needless, always online DRM that shuts down one day.

There are lots of video games without forced online DRM, and video games aren’t a necessity. You can simply stop buying games from these services and let people who don’t care about such things continue to buy them.

So you want to legally require game companies to “preserve history” in perpetuity, unlike every other kind of company in existence?

’

The second sentence isn’t true.

What SKG does is mandate that your purchased product be technically possible to be usable in perpetuity, or refund the cost of it.

That’s a ridiculous requirement. If you want to buy games that are playable in perpetuity, buy games that are playable in perpetuity.

But the whole market isn’t shitty rip offs.

You don’t need to be protected from video game sales, you need to be protected from fraudulent game sales, that’s it.

If you want to buy a game that runs on proprietary servers that will shutdown one day, you should be allowed to do that.

Washington’s roads could degrade significantly and still be better than all its neighbors.

https://m.youtube.com/watch?v=DIsOHWkUfkg&t=9s&pp=2AEJkAIB