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

641–650 of 797 posts

Re: Hard Rust requirements from May onward

#641

Post by pjmlp »

capyba wrote: post #478
kstrauser wrote: post #225

Earlier quoted context omitted.

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…

All you're doing is passing an argument of the incorrect type to your function. The exact same thing fails to compile in C: ``` #include typedef struct { int value; } Feet; typedef struct { int value; } Meters; void hover(Meters altitude) { printf("At %i meters\n", altitude.value); } int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ``` ``` error: pas…

People use header libraries as they treat languages like C and C++ as if they were scripting languages.

Re: Hard Rust requirements from May onward

#642

Post by emmelaich »

lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

They need to do this carefully and with adversarial testing. There are safety measures in e.g. gnu tar that really should be replicated. But they are not to do with parsing, but the semantics.

IOW, what's your specification?

Re: Hard Rust requirements from May onward

#644

Post by pezezin »

kortilla wrote: post #578
pezezin wrote: post #566

Earlier quoted context omitted.

If we are talking about embedded control systems no, you don't want new software, you want your machine to do what is supposed to do. At my workplace we have some old VME crates running VxWorks, and nobody is gonna update those to the latest Linux distro.

This is incorrect. Internet connections and 3rd party integrations have changed this view of “the software doesn’t need to change once it leaves the factory”. John Deere, Caterpillar, etc are leaning heavily into the “connected industrial equipment” world. GE engines on airplanes have updatable software and relay telemetry back to GE from flights. The embedded world changed. You just might have missed it if your view…

My experience is in big scientific experiments like particle accelerators, I guess other fields are different. Still, my experience is that:

1) The control network is air gapped, any kind of direct Internet connection is very much forbidden.

2) Embedded real-time stuff usually runs on VxWorks or RTEMS, not Linux. If it is Linux, it is an specialized distro like NI Linux.

3) Anything designed in the last 15 years uses ARM. Older systems use PowerPC. Nobody has used Alpha, HPPA, SH4 or m68k in ages. So if you really want to run Debian on it, just go ahead and use Armbian.

Re: Hard Rust requirements from May onward

#645

Post by localusr123 »

zahlman wrote: post #608
fweimer wrote: post #422

Earlier quoted context omitted.

The Debian base system is much, much smaller. I'm surprised that people consider Python to be part of it. However, APT depends on Perl and the C++ run-time library, so those two languages have been part of the base system for a very long time.

> I'm surprised that people consider Python to be part of it. However, APT depends on Perl Pardon? $ file `which apt` /usr/local/bin/apt: Python script, ASCII text executable

Which apt is that?

? file `which apt`

/usr/bin/apt: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=157631f2617f73dee730273c7c598fd4d17b7284, for GNU/Linux 3.2.0, stripped

Re: Hard Rust requirements from May onward

#646

Post by jacquesm »

mgh95 wrote: post #379
cmrdporcupine wrote: post #327

Earlier quoted context omitted.

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

Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc. Once you take out cargo, rusts development environment becomes quite poor.

This 'language requires an eco-system' is something that I really dislike. The linker is where it should come together, not in your choices about importing external dependencies, module packaging, source code hosting options, debugger and so on.

Re: Hard Rust requirements from May onward

#647

Post by alt187 »

hofrogs wrote: post #119
alt187 wrote: post #62

Earlier quoted context omitted.

People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable. Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community. From what I could piece together, the only group who ever cried wo…

Who are you talking about? Asking in good faith, I never heard of that controversy before

The (retired?) head of a project trying to port Linux on Mac. I avoid naming names, not to be cryptic but because a lot of people like to stumble on these kinds of posts via search. Or moderate them. I'm not agreeing, but I can see why it's easier.

Re: Hard Rust requirements from May onward

#648

Post by dataflow »

embedding-shape wrote: post #386
jcranmer wrote: post #316

Earlier quoted context omitted.

Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…

> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community. So say you're a C++ developer, contributed to…

> So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.

How is language relevant here? If someone just rewrote it in the same language instead of a different one, do you feel the reaction would be significantly better?

Re: Hard Rust requirements from May onward

#649

Post by bigstrat2003 »

lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

I agree that new software should be written in Rust or another, safer language. But I don't agree that it's wise to start retrofitting old software in this way. New code is almost always worse in quality than old code, and I do not believe that the safety gains from Rust are so advantageous that they will offset that factor.

Re: Hard Rust requirements from May onward

#650

Post by DaSHacka »

iknowstuff wrote: post #582
DaSHacka wrote: post #495

Earlier quoted context omitted.

Feel free to enlighten me. Nothing I have seen thus far indicates anything to the contrary.

Spend more effort on looking before posting then!

I'm not gonna waste effort on a fool's errand. So far, neither claim has been backed up whatsoever.

It's obviously more likely it's just fans of the language with a knee-jerk reaction of "ackshully you're totally definetely wrong, but uh... don't ask me how, you just are" than legitimate talking points.

Post reply on HN