Google Supports Getting Rust Into The Linux Kernel

[sn99]

You should try taking your own advice.... but you can't because you don't have any projects.

Next!

I have more than you think kid

[60Hz]

I honestly do think that C++ is a trash language

I agree that C++ is trash, but it's at least somewhat usable trash, unlike Rust.

and anyone who defends it as blindly as you is a fool.

I didn't defend it.

Likewise, the only place I use C is retrocomputing hobby projects

That's because you're an incompetent amateur.

[ssokolow]

Rust is in a pretty sad state of affairs when even its biggest shills don't use it.

I know you're trying to troll but, since I honestly didn't clarify, I'll respond for the benefit of others before I start ignoring you.

TL;DR: It's not that Rust is bad at those things. It's that no language but Python has PyQt and Django and I consider memory-safe bindings to the QWidget APIs and Django's ORM and ecosystem of reusable apps to be non-negotiable.

Here's my attempt to get some fun out of the message I'm not going to respond to: I honestly do think that C++ is a trash language, and I'd pick Rust before C++ for any project, anywhere, and anyone who defends it as blindly as you is a fool. Likewise, the only place I use C is retrocomputing hobby projects and only when Free Pascal produces binaries that are too large. It's technology from half a century ago in an industry where hardware innovation has advanced faster than any other industry in history.

...and before you come back with "The QWidget APIs are written in C++ and CPython is written in C", the MythBusters used dorodango techniques to make shiny spheres of shit. Skill can make pretty damn shiny things out of turds but they're still turds.

[60Hz]

I'll readily admit that, at present, for GUIs, I stop at using PyO3 to write my frontend GUIs in PyQt and my backends in Rust... though, granted, my #1 reason is because there aren't any memory-safe QWidget bindings for Rust yet.

Likewise, if I were writing games, I'd probably just grab Godot and stick to GDScript until I run up against performance bottlenecks that require me to use GDNative+Rust to speed them up.

Rust is in a pretty sad state of affairs when even its biggest shills don't use it.

[ssokolow]

I'm saying Rust is a shitty trade-off for me (and like 99% gui desktop app and games devs, among many others), I'm surprised it isn't clear to you by now.

Well, if you hadn't XY Problem'd the message, maybe I'd have gotten it sooner.

I'll readily admit that, at present, for GUIs, I stop at using PyO3 to write my frontend GUIs in PyQt and my backends in Rust... though, granted, my #1 reason is because there aren't any memory-safe QWidget bindings for Rust yet.

Likewise, if I were writing games, I'd probably just grab Godot and stick to GDScript until I run up against performance bottlenecks that require me to use GDNative+Rust to speed them up.

[cl333r]

So you're saying you want a magic programming language that will hold the universe ransom until it changes its mind if it tells you that your request is unsatisfiable?

Rust gives you three options:

• Structure your code so the compiler can prove that your request is infallible
• Assume the request is infallible at runtime and halt the program if that assumption is violated
• Report the success or failure of the request to you so you can choose how to handle failure

Four if you count "Use primitives like unsafe and UnsafeCell to overrule the compiler and get tarred and feathered in the media when Miri's data race detector screams that, no, you aren't some special genius who knew better than the compiler".

I'm saying Rust is a shitty trade-off for me (and like 99% gui desktop app and games devs, among many others), I'm surprised it isn't clear to you by now.

[ssokolow]

I told you returning an error is not an option.

So you're saying you want a magic programming language that will hold the universe ransom until it changes its mind if it tells you that your request is unsatisfiable?

Rust gives you three options:

• Structure your code so the compiler can prove that your request is infallible
• Assume the request is infallible at runtime and halt the program if that assumption is violated
• Report the success or failure of the request to you so you can choose how to handle failure

Four if you count "Use primitives like unsafe and UnsafeCell to overrule the compiler and get tarred and feathered in the media when Miri's data race detector screams that, no, you aren't some special genius who knew better than the compiler".

[reba]

I told you returning an error is not an option.

Returning an error separate from the value is necessary if you don't want to mingle both, e.g. negative values mean error, 0 is error, 0 is success, positive values mean error, values with highest bit set are errors, etc.
These agreements are just this - agreements. And they vary very much between different coders, differnt programs and methods/functions.
And this is a biggie.

If you have a separate error functionality (for example exactly what exceptions were also made for!) you can cleanly separate ok from error conditions and make sure: when there is no error, every value is correct, as weird as it might be; when there is an error, every value is not to be used, regardless what is returned, and, according to the type or additional information of the error, handling of this situation can occur.

I think returning special values for error conditions comes from history, the return of these values through resierts or on the stack, where there is no such concept as a real "error" semantic. Later, in higher languages, the problem probably was that functions could ony return one value and of one type, not tuples. The more modern languages allow tuples to be returned, allowing more language constructs.

[cl333r]

That's what the non-try_* versions do. The try_* versions return a Result<T,BorrowError> for you to handle as you please.

I told you returning an error is not an option.

[ssokolow]

HTML is indeed sloppy but it is a necessary evil. There are (or maybe were) cases where an HTML document can be partially transmitted and then truncated due to network error. XHTML attempted to handle such cases as "invalid file" and show nothing to users. Meanwhile every other HTML engines fulfill users by showing the webpage as much as possible. It is human nature that users want the HTML way. We shall think of the design / implementation of HTML as a high-level ECC.

More formally, that attitude is referred to as the robustness principle or Postel's law.

"be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept".

Granted, the fact that it took HTML so long to get a standardized parsing algorithm is a mess, but it also refers to things like "Don't blow up if you encounter an unfamiliar HTML tag or JSON field or HTTP header".

...and, honestly, it's kinda necessary, given how HTML originated. There's just too much use of templating that's based on pushing around strings rather than using a proper SAX or DOM serializer to render malformed tag structures impossible.