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

Rust vs C Pitfalls

garin.io

Post reply on HN
Print view View original

91–100 of 379 posts

Re: Rust vs C Pitfalls

#91

Post by steveklabnik »

zerofan wrote: post #89
steveklabnik wrote: post #61

Earlier quoted context omitted.

How would you have gone about making Strings be "as comfortable as integers"? Arrays are indexed by usize, so if you're on a 64-bit machine, then you shouldn't need a cast. It's _unconstrained_ numbers that default to i32, not anything without a suffix.

> How would you have gone about making Strings be "as comfortable as integers"? I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer. I'm fairly certain I understand why Rust made the choice they did. I've read the forum threads at HN, Reddit, and users.rust-lang, and I've seen previous replies by you and other Rusties, so I hope you won't try to ed…

> so I hope you won't try to educate me

No, I'm interested in what tradeoffs you would have made differently. I now understand. Thanks! (I disagree, but at least I understand.)

> why this line hangs:

It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug?

> I think the uncommented line shows a similar complaint.

Yes, there's no constraint on that literal, so it's going to be an i32. When we made this decision, we did some analysis, basically no numbers in real world programs weren't constrained, it was often tests, toy programs, and documentation. It should be a rare thing. YMMV.

> why is that a sensible default?

Your assertion about the speed was the opposite of what was asserted while we had the discussion, basically. And not everybody is running on 64-bit hardware, so it's a broader default.

Re: Rust vs C Pitfalls

#92

Post by pornel »

lacampbell wrote: post #6
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust.

It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime.

Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningful improvement in safety/concurrency/expressiveness.

Re: Rust vs C Pitfalls

#93

Post by zerofan »

steveklabnik wrote: post #62
zerofan wrote: post #56

Earlier quoted context omitted.

I'd like to see if Rust is still around in 10 years and then look before we declare the winner on this.... All software has bugs.

It's been around for roughly six or eight already, depending on how you count. Of course, pre-1.0 was a different thing, but still. Ten years is not that long a time. (I still agree that results at that point will be more interesting then speculating today.)

> It's been around for roughly six or eight already, depending on how you count.

I don't think you get to play on both sides of that fence. Some of your team has been working on Rust for that long, but I doubt any code with sigils compiles, and I doubt there were many large projects using it then. I started my stopwatch at May 2015.

> Ten years is not that long a time.

Totally agree.

> I still agree that results at that point will be more interesting then speculating today.

We'll see on May 2025. :-)

Re: Rust vs C Pitfalls

#94

Post by steveklabnik »

groovy2shoes wrote: post #90
lacampbell wrote: post #6

Earlier quoted context omitted.

C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanw…

There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc.

> In the meantime, I'd settle for an "LTS" release or something. That could work.

This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.

Re: Rust vs C Pitfalls

#95

Post by steveklabnik »

zerofan wrote: post #93
steveklabnik wrote: post #62

Earlier quoted context omitted.

It's been around for roughly six or eight already, depending on how you count. Of course, pre-1.0 was a different thing, but still. Ten years is not that long a time. (I still agree that results at that point will be more interesting then speculating today.)

> It's been around for roughly six or eight already, depending on how you count. I don't think you get to play on both sides of that fence. Some of your team has been working on Rust for that long, but I doubt any code with sigils compiles, and I doubt there were many large projects using it then. I started my stopwatch at May 2015. > Ten years is not that long a time. Totally agree. > I still agree that results at t…

Yeah that's why I said it depends. :) periodization is tough. 18 months, four years, six years, and 9ish years are all valid, depending on how. What I mean to say is that it's already been quite a while, and now that it's making its way into distros and required for building Firefox and all that, I think it has even more of a chance of sticking around for a long time, given that it was around for quite a while when it wasn't even a viable "real" language. I don't mean to insinuate that today's Rust is mega mature because those old Rusts exist.

Re: Rust vs C Pitfalls

#96

Post by zerofan »

steveklabnik wrote: post #91
zerofan wrote: post #89

Earlier quoted context omitted.

> How would you have gone about making Strings be "as comfortable as integers"? I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer. I'm fairly certain I understand why Rust made the choice they did. I've read the forum threads at HN, Reddit, and users.rust-lang, and I've seen previous replies by you and other Rusties, so I hope you won't try to ed…

> so I hope you won't try to educate me No, I'm interested in what tradeoffs you would have made differently. I now understand. Thanks! (I disagree, but at least I understand.) > why this line hangs: It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug? > I think the uncommented line shows a similar complaint. Yes, there's no constraint on t…

> basically no numbers in real world programs weren't constrained, it was often tests, toy programs

The fact that C and C++ compilers generally chose to leave int at 32 bit on 64 bit platforms, combined with the standards requiring "usual promotions" for smaller types to go to int bites me all the time. I'm very happy that Rust dodges the promotions problem altogether, and I'm sorry if I'm wrong about the array subscripting thing (does the snippet I provided panic at 1> And not everybody is running on 64-bit hardware, so it's a broader default.

That argument could be used to justify 8 or 16 bit integers... :-)

Re: Rust vs C Pitfalls

#97

Post by steveklabnik »

zerofan wrote: post #96
steveklabnik wrote: post #91

Earlier quoted context omitted.

> so I hope you won't try to educate me No, I'm interested in what tradeoffs you would have made differently. I now understand. Thanks! (I disagree, but at least I understand.) > why this line hangs: It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug? > I think the uncommented line shows a similar complaint. Yes, there's no constraint on t…

> basically no numbers in real world programs weren't constrained, it was often tests, toy programs The fact that C and C++ compilers generally chose to leave int at 32 bit on 64 bit platforms, combined with the standards requiring "usual promotions" for smaller types to go to int bites me all the time. I'm very happy that Rust dodges the promotions problem altogether, and I'm sorry if I'm wrong about the array subsc…

> (does the snippet I provided panic at 1Overflow is a "program error", and in debug builds, is required to panic. In other builds, if it does not panic, it's required to two's compliment overflow. Rustc currently just overflows, but in the future, we'll see.

That's true except our 16 bit support is nonexistant at the moment :)

Re: Rust vs C Pitfalls

#98

Post by zerofan »

steveklabnik wrote: post #97
zerofan wrote: post #96

Earlier quoted context omitted.

> basically no numbers in real world programs weren't constrained, it was often tests, toy programs The fact that C and C++ compilers generally chose to leave int at 32 bit on 64 bit platforms, combined with the standards requiring "usual promotions" for smaller types to go to int bites me all the time. I'm very happy that Rust dodges the promotions problem altogether, and I'm sorry if I'm wrong about the array subsc…

> (does the snippet I provided panic at 1 Overflow is a "program error", and in debug builds, is required to panic. In other builds, if it does not panic, it's required to two's compliment overflow. Rustc currently just overflows, but in the future, we'll see. That's true except our 16 bit support is nonexistant at the moment :)

> That's true except our 16 bit support is nonexistant at the moment :)

If you pay attention to your usage statistics, I'll bet you drop 32 bit support before the May 2025 deadline we were discussing in the other thread.

Re: Rust vs C Pitfalls

#99

Post by tptacek »

empath75 wrote: post #36
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

It's very rare that any programmer switches computer languages. You're probably going to retire as a c programmer. What are they going to teach in school? What are new systems programmers going to start with? I suspect it'll be rust and go, not c.

Not even a little bit true.

Re: Rust vs C Pitfalls

#100

Post by steveklabnik »

zerofan wrote: post #98
steveklabnik wrote: post #97

Earlier quoted context omitted.

> (does the snippet I provided panic at 1 Overflow is a "program error", and in debug builds, is required to panic. In other builds, if it does not panic, it's required to two's compliment overflow. Rustc currently just overflows, but in the future, we'll see. That's true except our 16 bit support is nonexistant at the moment :)

> That's true except our 16 bit support is nonexistant at the moment :) If you pay attention to your usage statistics, I'll bet you drop 32 bit support before the May 2025 deadline we were discussing in the other thread.

We'll see!
Post reply on HN