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

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

321–330 of 797 posts

Re: Hard Rust requirements from May onward

#321

Post by Someone »

kstrauser wrote: post #225
allisdust wrote: post #204

Earlier quoted context omitted.

Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…

I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…

That’s not a good example. Wrapping an integral value into a struct works exactly the same in C and (https://stackoverflow.com/questions/40629989/pros-and-cons-o...)

In C++ you can even add overloaded operators to make using math on such structs ergonomical.

Compilers know of the idiom, and will optimize the struct away.

Re: Hard Rust requirements from May onward

#322

Post by davemp »

zozbot234 wrote: post #234
davemp wrote: post #177

Earlier quoted context omitted.

Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay. I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are a…

The safety guarantees of Rust the language around unsafe are just as good as C or Zig if you use the appropriate facilities (raw pointers, MaybeUninit, UnsafeCell/Cell, Option for nullability, Pin etc). Sometimes this is made unnecessarily difficult by standard library code that expects all the guarantees of ordinary Safe Rust instead of accepting more lenient input (e.g. freely aliasable &Cell 's), but such cases ca…

My point is that it’s easier to write correct Zig code than correct unsafe Rust. Raw pointers can be null in rust so you should use NonNull but there’s aliasing rules that are easy to mess up. And difficultly with the stdlib as you mentioned.

I don’t actually mind Rust when I was able to write in safe user land, but for embedded projects I’ve had a much better time with Zig.

Re: Hard Rust requirements from May onward

#323

Post by scott_w »

StopDisinfo910 wrote: post #281
scott_w wrote: post #272

Earlier quoted context omitted.

How has a language specification and multiple viable compilers helped C developers write security-critical code?

Considering the number of provers and statistical analysers and given C is the only mainstream language with a formally verified compiler, I would say fairly well thank you. Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members t…

All those things didn’t stop Heartbleed or numerous other CVEs from happening, though, did it?

Re: Hard Rust requirements from May onward

#324

Post by arccy »

hypeatei wrote: post #273
StopDisinfo910 wrote: post #261

Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.

Ferrous Systems donated their language specification ("Ferrocene") to the Rust foundation[0] who is working on integrating it but that takes time, obviously. 0: https://rustfoundation.org/media/ferrous-systems-donates-fer...

Their spec just happens to describe whatever the compiler decided to implement, it's not a source of truth.

Re: Hard Rust requirements from May onward

#325

Post by estimator7292 »

wk_end wrote: post #301
thesuperbigfrog wrote: post #138

Earlier quoted context omitted.

Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…

There’s hobbyists using m68k Macs, Amigas, and Atari STs. Definitely a small niche, and those running Linux on those machines more so.

Sure, but almost nobody uses or wants modern linuxes on those machines. It's almost always described (in their own words) as "some ancient crusty version of Debian"

Re: Hard Rust requirements from May onward

#326

Post by 0x000xca0xfe »

nicce wrote: post #139
0x000xca0xfe wrote: post #110

Earlier quoted context omitted.

What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.

Some people don't have actual understanding of the meaning of security. Security is there to keep the features usable without interruptions or risks. E.g. plugging the computer off the network is not about security if the service needs to be accessible.

But many users were relying on these features. Hence the bug report.

This is literally the same as helping a relative to make their computer more secure by turning it off. Problem solved I guess?

If you made a mistake by shipping insecure defaults you could fix it e.g. by including a banner to use the minimal version to users that don't use the extra features. But simply rug-pulling everybody for "security" and doubling down by insulting the affected users? I really do not understand people that act like this.

Re: Hard Rust requirements from May onward

#327

Post by cmrdporcupine »

krater23 wrote: post #284
Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

I'm from embedded too. We tried to use rust in one of our projects and came to the conclusion that it makes no sense to convert our team from experiences C++ developers to beginner level Rust developers. Additionally to that, it was nearby impossible to control the amount of packages that come in with Cargo. We had for a small tool three versions of the same library as dependency in our binary. Additionally to that,…

You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.

Re: Hard Rust requirements from May onward

#328

Post by procaryote »

UncleEntity wrote: post #201
mirashii wrote: post #172

Earlier quoted context omitted.

> I think this is the wrong way to promote rust This is entirely the wrong lens. This is someone who wants to use Rust for a particular purpose, not some sort of publicity stunt. > I know nobody that programms or even thinks about rust. I’m from the embedded world a there c is still king. Now’s a good time to look outside of your bubble instead of pretending that your bubble is the world. > as long as the real money…

> This is entirely the wrong lens. Telling people they need to take their ball and go home if they're incapable or unable to maintain an entire compiler back-end seems like a, shall we say, 'interesting' lens for a major distro such as Debian. Just to parse some files?

Just to parse some files there are already tools and libraries for, for added security, without specifying a threat model

Re: Hard Rust requirements from May onward

#329

Post by [deleted] »

the__alchemist wrote: post #141
Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined. I think th…

[deleted]

Re: Hard Rust requirements from May onward

#330

Post by krzyk »

StopDisinfo910 wrote: post #281
scott_w wrote: post #272

Earlier quoted context omitted.

How has a language specification and multiple viable compilers helped C developers write security-critical code?

Considering the number of provers and statistical analysers and given C is the only mainstream language with a formally verified compiler, I would say fairly well thank you. Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members t…

Doesn't Java have also a formally verified compiler?
Post reply on HN