Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 2024 the Year of Everywhere?

smallcultfollowing.com

Post reply on HN
Print view View original

141–150 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#141

Post by hither_shores »

ilovecaching wrote: post #98
woodruffw wrote: post #48

Earlier quoted context omitted.

I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs. It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engi…

I've heard this argument many times from Rust enthusiasts, most of whom do not work in C, C++, or even write system level software. Of the kernels that I have worked on, the Linux kernel core is very high quality C (even if many of the drivers are not), and other large parts of the stack like grub and systemd are also written in C and yet the sky isn't falling for users around the globe (and on other planets).

> the Linux kernel core is very high quality C

The Linux kernel core is the product of decades of effort by thousands of people, many of them world-class experts in the relevant domains. Very, very few software projects receive anything close to that.

No one is claiming that writing safe C code is impossible; the problem is that writing unsafe C code is easy.

Re: Rust 2024 the Year of Everywhere?

#142

Post by up2isomorphism »

No matter how you think your language will be whatsoever, it is just your crowd. For the rest of the world, it does not matter at all. It is just a tool, if I need I will use it otherwise I won’t spend a single minute to look at it.

Also if you think memory safety is the hardest problem in programming, you probably haven’t written any non-trivial program anyway.

Re: Rust 2024 the Year of Everywhere?

#143

Post by chlorion »

ilovecaching wrote: post #98
woodruffw wrote: post #48

Earlier quoted context omitted.

I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs. It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engi…

I've heard this argument many times from Rust enthusiasts, most of whom do not work in C, C++, or even write system level software. Of the kernels that I have worked on, the Linux kernel core is very high quality C (even if many of the drivers are not), and other large parts of the stack like grub and systemd are also written in C and yet the sky isn't falling for users around the globe (and on other planets).

The Linux kernel has a constant stream of fairly severe, exploitable bugs caused by memory safety errors, not to mention non-exploitable bugs that lead to system instability or even data loss.

Just a few months back there was a bug that allowed any completely unprivileged user to elevate straight to root using a combination of unprivileged user namespaces and cgroups. Other than RCE or severe data loss, I would say this is one of the most severe forms of bugs possible in a kernel. For some period of time the kernel's basic security features were completely ineffective, and this is possibly one of the most widely used kernels in the world!

Severe security related bugs are really common with our OS's and user space software, and we just pretend that it's not a problem. When your kernel can't even offer basic security isolation between users in a reliable manner, when visiting a malformed website with your browser results in arbitrary code execution, or when a malformed message sent to you phone can completely own it, I would say there is a serious problem.

Re: Rust 2024 the Year of Everywhere?

#144

Post by Gibbon1 »

mikepurvis wrote: post #104
resonious wrote: post #44

Earlier quoted context omitted.

Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC .

I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.

> or return a pointer to a local variable that's about to go out of scope

I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.

Re: Rust 2024 the Year of Everywhere?

#145

Post by qalmakka »

aussiesnack wrote: post #73
nu11ptr wrote: post #66

Earlier quoted context omitted.

This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…

> Rust isn't really all that hard. You don't find it hard. Many do.

The point is, Rust is vastly easier than C++ when you start factoring in the complexity of debugging nasty design choices that comes to bite you in the back and you can't really fix without tearing the whole application apart.

Yesterday I was fighting the borrow checker because it wasn't allowing me to pass a reference in an async function. After a while it dawned me that if that thing I was attempting to write would have been accepted, it would have caused a crash in some rare, but not impossible, circumstances.

It saved me potentially countless hours of debugging and wrapping my head around the fact that my smart abstraction crashed every once in a while, something that happens to me everyday with C++.

Rust is hard, but it's less hard than it's alternatives.

Re: Rust 2024 the Year of Everywhere?

#146

Post by nyanpasu64 »

Gigachad wrote: post #126
BatFastard wrote: post #46

Earlier quoted context omitted.

I am relearning c++, much has changed in last 12 years! I tried Rust, but when doing a data driven app, I found myself using unsafe way too much!

Why are people always more afraid of unsafe than C/++? Using C++ because you had to use unsafe is throwing the whole house out with the bath water. It’s like Rust forces people to acknowledge when they are taking things in to their own hands while C/++ let’s them live in blissful ignorance.

Because unsafe Rust has at least as many footguns, and a narrower happy path (second-class support for shared mutability, raw pointers are a pain to use and encapsulating in a handle struct might help though I haven't tried writing code this way, Pin violates SB, Box may or may not disable aliasing raw pointers), than C++.

Re: Rust 2024 the Year of Everywhere?

#147

Post by pjmlp »

qalmakka wrote: post #145
aussiesnack wrote: post #73

Earlier quoted context omitted.

> Rust isn't really all that hard. You don't find it hard. Many do.

The point is, Rust is vastly easier than C++ when you start factoring in the complexity of debugging nasty design choices that comes to bite you in the back and you can't really fix without tearing the whole application apart. Yesterday I was fighting the borrow checker because it wasn't allowing me to pass a reference in an async function. After a while it dawned me that if that thing I was attempting to write would…

Dunno, maybe it is Stockholm syndrom from using C++ since 1993, but I definitly find easier to understand template metaprogramming than the upcoming GAT, or the whole Pin and PhatomData stuff.

Re: Rust 2024 the Year of Everywhere?

#148

Post by goodpoint »

andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

You want Nim.

Re: Rust 2024 the Year of Everywhere?

#149

Post by Ygg2 »

pjmlp wrote: post #147
qalmakka wrote: post #145

Earlier quoted context omitted.

The point is, Rust is vastly easier than C++ when you start factoring in the complexity of debugging nasty design choices that comes to bite you in the back and you can't really fix without tearing the whole application apart. Yesterday I was fighting the borrow checker because it wasn't allowing me to pass a reference in an async function. After a while it dawned me that if that thing I was attempting to write would…

Dunno, maybe it is Stockholm syndrom from using C++ since 1993, but I definitly find easier to understand template metaprogramming than the upcoming GAT, or the whole Pin and PhatomData stuff.

Sure, but you are comparing meta programming facility to a type/lifetime feature that serves as Higher Kinded Type replacement.

In Rust same thing holds, macros are easier than GAT

I don't get why PhantomData or Pin are that hard to grasp?

PhantomData is just a type marker that has no purpose other than help compiler. See https://doc.rust-lang.org/nomicon/phantom-data.html

Pin is a way to create self referential structs, by pinning memory and preventing moves.

PhantomPinned is a marker type to ensure your type is not Unpin (it is by default). Unpin it thing that shouldn't be pinned, like bool, i32, etc.

Re: Rust 2024 the Year of Everywhere?

#150

Post by qalmakka »

pjmlp wrote: post #147
qalmakka wrote: post #145

Earlier quoted context omitted.

The point is, Rust is vastly easier than C++ when you start factoring in the complexity of debugging nasty design choices that comes to bite you in the back and you can't really fix without tearing the whole application apart. Yesterday I was fighting the borrow checker because it wasn't allowing me to pass a reference in an async function. After a while it dawned me that if that thing I was attempting to write would…

Dunno, maybe it is Stockholm syndrom from using C++ since 1993, but I definitly find easier to understand template metaprogramming than the upcoming GAT, or the whole Pin and PhatomData stuff.

I've seen people picking up C++ from scratch recently and rest assured, that's not so obvious for a novice like it is for a person that's been using it for decades. I think the level of complexity is similar, but at least Rust features feel like they were designed on purpose.

C++ metaprogramming, to be fair, is a happy little accident that turned out being a blessing, more than something that was well designed from the start...

Post reply on HN