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

181–190 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#181

Post by taylodl »

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…

The funny thing is Rust adds a lot of complexity to solve the main problem it purports to solve: memory management. I spent the first 20 years of my career doing C/C++ development and we were able to "solve" that problem with far less complexity. Rust changed so much in the early days (I really hate the mantra of move fast and break things when it comes to programming languages) that I got tired of all the breaking changes and total disregard for backward compatibility. Which is cool if you're into that sort of thing, but I'm not. Maybe Rust has added more killer features since then warranting the complexity? I really don't know.

I'd be interested in hearing are there other reasons for learning Rust other than just memory management? What other problems is Rust solving?

Re: Rust 2024 the Year of Everywhere?

#182

Post by pornel »

taylodl wrote: post #179
pornel wrote: post #177

Earlier quoted context omitted.

According to TIOBE, C has lost 60% of its popularity between 2015 and 2017, and then doubled next year. What's more likely: that a 40-year-old language C had such a massive sudden swing, or that TIOBE data is garbage and measures search engine's algorithms, not language relevance? https://blog.nindalf.com/posts/stop-citing-tiobe/ BTW: According to the TIOBE horoscope Rust is way ahead of TypeScript and Bash.

I don't see the 60% drop in popularity between 2015 and 2017 as you claim (see https://www.tiobe.com/tiobe-index ). C has never not been in the top 5 languages used since the index was created 35 years ago. There have been numerous cycles where it's been #1. There's been very little volatility in the top 10 for the past 10 years, as opposed to the 25-50 ranked languages where Rust resides which has considerably more…

The Ratings % line for C: Nov 7 2015 = 17.15%, Aug 2 2017 = 6.48%

C# has jumped from 0.77% in Mar 2020 to 4.75% in Apr 2022. One month, 6x increase.

Even if you just take relative rankings, they're also total nonsense: TypeScript is 40th, behind Prolog, Visual Fox Pro, Dart, and Rust.

Re: Rust 2024 the Year of Everywhere?

#183

Post by [deleted] »

Ygg2 wrote: post #149
pjmlp wrote: post #147

Earlier quoted context omitted.

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 stru…

[deleted]

Re: Rust 2024 the Year of Everywhere?

#184

Post by ridiculous_fish »

qalmakka wrote: post #152
Ygg2 wrote: post #149

Earlier quoted context omitted.

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 stru…

> Pin is a way to create self referential structs, by pinning memory and preventing moves. This, exactly. Pin works more or less like a C++ class with a deleted move constructor. Copies may be allowed if clone/copy (aka, the implicit/explicit copy constructor) are defined, but move and RVO are not. Lots of Rust's concepts can often be described in terms of C++'s techniques, but more often than not in C++ it tends to…

How does this work? I want to wrap POSIX semaphores. You call sem_init, passing it the address of an int; later you call sem_destroy and pass it the same address. So the location of the int must not change.

In C++ you would delete the move constructor:

    struct sema { 
        int v;
        void sema(sema &&) = delete;
    };
In Rust you might try this, but it doesn't work:

    struct Sema {
        v: Pin,
    }
there is no way to create a "Pin". The closest you can get is probably to malloc it:

   struct Sema {
       v: Pin>
   }
but now Pin is adding nothing at all (except perhaps a hint to the reader) and may be deleted. The real guarantee is provided by Box, not Pin.

It looks to me like Pin is created to support async, and outside of that use case is not very useful, and is a poor replacement for non-movable types.

Re: Rust 2024 the Year of Everywhere?

#185

Post by cercatrova »

buzzdenver wrote: post #16
Scarbutt wrote: post #3

Rust is so simple and elegant.

Was it simple and elegant from the beginning, or did it click at some point? I started learning it from the O'Reily book yesterday, and so far it's easily the steepest learning curve for a language.

I wouldn't recommend the O'Reilly book for a beginner, use the official book in the docs, and do Rustlings alongside that. That's how I learned. Rustlings especially smooths you into the concepts while the O'Reilly book starts off writing a Mandelbrot generator as the first project, which put me off of that.

Re: Rust 2024 the Year of Everywhere?

#186

Post by cercatrova »

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).

And the Linux kernel is introducing Rust code [0] due to the fact that even Linus Torvalds acknowledges that Rust solves issues that would be prevalent in C code.

[0] https://www.zdnet.com/article/linus-torvalds-rust-will-go-in...

Re: Rust 2024 the Year of Everywhere?

#187

Post by Gibbon1 »

mikepurvis wrote: post #174
Gibbon1 wrote: post #144

Earlier quoted context omitted.

> 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.

Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases. But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.

What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains.

The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.

Re: Rust 2024 the Year of Everywhere?

#188

Post by taylodl »

pornel wrote: post #182
taylodl wrote: post #179

Earlier quoted context omitted.

I don't see the 60% drop in popularity between 2015 and 2017 as you claim (see https://www.tiobe.com/tiobe-index ). C has never not been in the top 5 languages used since the index was created 35 years ago. There have been numerous cycles where it's been #1. There's been very little volatility in the top 10 for the past 10 years, as opposed to the 25-50 ranked languages where Rust resides which has considerably more…

The Ratings % line for C: Nov 7 2015 = 17.15%, Aug 2 2017 = 6.48% C# has jumped from 0.77% in Mar 2020 to 4.75% in Apr 2022. One month, 6x increase. Even if you just take relative rankings, they're also total nonsense: TypeScript is 40th, behind Prolog, Visual Fox Pro, Dart, and Rust.

Yeah, that's why many people treat everything beyond the top 25 as noise. There's a lot of churn there.

Re: Rust 2024 the Year of Everywhere?

#189

Post by drogus »

taylodl wrote: post #181
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…

The funny thing is Rust adds a lot of complexity to solve the main problem it purports to solve: memory management. I spent the first 20 years of my career doing C/C++ development and we were able to "solve" that problem with far less complexity. Rust changed so much in the early days (I really hate the mantra of move fast and break things when it comes to programming languages) that I got tired of all the breaking c…

I’m genuinly curious - how did you „solve” memory safety issues in C/C++?

Re: Rust 2024 the Year of Everywhere?

#190

Post by bsder »

kibwen wrote: post #120
bsder wrote: post #118

Earlier quoted context omitted.

> You don't find it hard. Many do. The question at the end of the day is whether that "hardness" is required or accidental. My gut feel is that Rust does have some accidental complexity--poor support for static/globals, poor support for placement new and alternate allocators, inability to transmute equivalent types well, etc. However, my gut feel is also that a lot of Rust's "difficulty" is the fact that people reall…

*> poor support for static/globals I'll agree with your other things, but discouraging global state is an aspect that reduces ultimate complexity, rather than increasing it. :P

As in all things--sometimes.

One thing in particular that is gratuitously difficult in Rust is to do some very expensive runtime initialization, place the result into static memory, and then do read-only things to that memory after it is initialized.

Rust really does not like that pattern (it always wants you wrap that and takes locks to it with the associated performance hit) and yet it is an extremely common thing to need to do (embedded communication stacks, graphics card shaders, etc.).

Post reply on HN