Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment Re: Nope (Score 1) 124

I have no idea what comment you are referring to. I see you linked to a "Unsafe Rust is harder than C". Harder != worse. Especially when the article is referring a specific use case in a heavily asynchronous application. I doubt anyone would even dare use C like that so the author's complaints about trying to pin lists in futures is kind of moot because you wouldn't dare use C that way without suffering a world of hurt on issues with (lack of) lifetime checking, borrow checking, move, sync+send, pinning etc.

Comment Re: Nope (Score 1) 124

Unsafe Rust is not worse than C. Even in an unsafe block the compiler does borrow and lifetime checks so it is still safer than C. The unsafe keyword enables access to pointer & memory manipulation / copy / transmutation functions. Programmers use an unsafe block where it's calling C, or dealing with hardware address memory or whatever where it needs to manipulate memory to deal with that external system. The rest of the time, the default for the majority of code, it is not in an unsafe block.

While I am sure you could abuse unsafe and make your code as liable to crash as C, best practice is to avoid unsafe at all costs and only use if it *must* be used. And if your code *does* crash, then the first course of action is grep for "unsafe" and most likely one of those blocks is the culprit.

Comment Re: Nope (Score 1) 124

And I expect even if the 20% claim were true we'd look at the crate in the majority of cases the usage is because the crate wraps some C function call. I can only think of one case where a popular high level crate was using unsafe beyond necessity which was actixweb for "performance reasons" and it received a lot of attention and almost all of the unsafe blocks were excised. I think there are about 7 unsafe blocks consisting of a few lines each left in quite a substantial codebase.

Comment Re: Nope (Score 1) 124

No it isn't. Unsafe blocks still do borrow & lifetime checks. In C or C++ it would be trivial to call a dangling pointer/reference or to inadvertently free something more than once. Also, the entirety of C and C++ is unsafe by default whereas Rust is safe by default. And even if you needed to use unsafe, when strictly necessary, those blocks stand out like beacons if there is an issue.

Comment Re: Nope (Score 1) 124

It's actually incredibly easy to avoid for the vast bulk of code. The only place it is typically seen is when Rust has to call some C library, or has to do something low level. For example, some C function wants to take an address to something and Rust has to use unsafe to do that work.

And if you're seeing unsafe in packages then most likely it is because that's what they're doing. Even a few unsafe blocks is infinitely preferable to everything being unsafe. As an example I developed a project over 3 years with tens of thousands of lines and a couple of unsafes. It crashed once. That was due to me calling an openssl function with the wrong arguments. Since I only had a few unsafe blocks it was very easy to identify the issue and fix it.

Comment Re:Nope (Score 1) 124

Rust by default does not let you manipulate pointers or memory. When you enclose something in an unsafe block you can do that stuff. It's basically like a superuser command granting you extra powers. Using unsafe strongly discouraged and most Rust code doesn't need or use it. Where you have to use it is where you're interacting with external code (e.g. a C library), or hardware.

One misconception is that unsafe is throwing away all the safety guarantees that normal Rust provides, but it doesn't. You still get borrow & lifetime checking within the unsafe block. So unsafe Rust is still safer than C or C++.

Comment Re:Python is BASIC (Score 0) 42

In fairness, Python is somewhat better than BASIC given that it's portable, supports functional programming like lambdas, has decent slicing and other conveniences.

But at the same time it's also a very poor choice of language to actually write anything substantial in. Performance blows and it doesn't scale. Multithreading is especially bad and even if they fix that, code is liable to break in all sorts of racy ways due to the body of code out there. Package management is a disaster with workarounds using virtual environments and other nonsense to get around the globalness of packages. Typing (or rather hinting) is an afterthought and a lot of code barely bothers with it. Lack of strong types bleeds into truthy/falsely, e.g. empty arrays being considered False.

What gets me is Python being most popular for LLM programming when it is possibly the slowest mainstream language in existence. AI is probably bolstering Python's popularity but really something like Rust would be far more suitable for that purpose.

Comment Re:Good for her! (Score 1) 154

Pointing a phone camera in someone's face without consent also gets people upset. There are plenty of clips on YouTube in various contexts where it escalated into violence. Having a camera constantly perched on your face will too and it's an entirely self inflicted situation when people start throwing punches.

Comment Re: Good for her! (Score 2, Interesting) 154

He didn't need them to see and he certainly didn't need to have a camera attached to his face with no means to remove it. He learned the hard way that people have opinions about that. Especially in Europe where the concept of privacy and violating it are more prone to prompt a reaction.

Slashdot Top Deals

The trouble with the rat-race is that even if you win, you're still a rat. -- Lily Tomlin

Working...