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

421–430 of 797 posts

Re: Hard Rust requirements from May onward

#421

Post by throwawaymaths »

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…

How does this scheme of yours work with m/s and seconds.

IIUC, rust would NOT let you do a type checked m/s * s => m, so using the type system for these kinds of games is silly and dangerous (I presume you would have to do the dumb thing and typeconvert to the same type -- e.g.

    (m) (speed * ((m/s) seconds))
to do multiplication which means you're inserting unscientific and reader-confusing type conversions all over the place)

Re: Hard Rust requirements from May onward

#422

Post by fweimer »

throwaway2037 wrote: post #413
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…

Is X11/KDE considered part of the "base system"? If yes, then: > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years ... isn't so surprising.

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.

Re: Hard Rust requirements from May onward

#423

Post by dang »

gpm wrote: post #275
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.

Flagged for deliberately spreading disinformation under the name StopDisinfo. As this user is aware, rust has a specification https://github.com/rust-lang/fls , which they have previously commented on: https://news.ycombinator.com/item?id=44927141 (and which I probably wouldn't have remembered if not for the rather remarkable name they are saying false things under). Rust also has multiple compilers (rustc, mrustc, a…

Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.

https://news.ycombinator.com/newsguidelines.html

Re: Hard Rust requirements from May onward

#424

Post by Too »

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.

Large share of C programs also (accidentally) depend on holes in the specifications, aka undefined behavior. Putting them under the mercy of the compiler to remain consistent.

Re: Hard Rust requirements from May onward

#425

Post by cmrdporcupine »

1vuio0pswjnm7 wrote: post #419
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.

Any recommended pointers to examples of how to use rustc without cargo I dislike the tone of the evangelism and the anti-C attitude but I'm not anti-rust. I purchased a computer with an oversized amount or RAM in part so I could experiment with rust. But determining how to write, edit and compile small programs, from the ground up, without cargo appears exceedingly difficult, and feels like going against the tide It…

Definitely going against the tide; but possible

e.g. Chrome & Fuchsia both build included Rust bits using their existing build system.

Bazel and Buck2 both work well with it, relatively.

One can also just be really disciplined with Cargo and not add superfluous deps and be careful about the ones you do include to monitor their transitive dependencies.

IMHO this is more about crates.io than Cargo, and is the biggest weakness of the language community. A bulk of developers unfortunately I think come from an NPM-using background and so aren't philosophically ... attuned... to see the problem here.

Re: Hard Rust requirements from May onward

#426

Post by larusso »

I really like to write programs in rust. But my stance has changed a bit over the years ever since other languages caught up a bit. On top of that I’m very skeptical if the rewrite of an ancient tool brings more less security. I don’t know the apt source code or how it actually works behind the cli interface so I leave this judgement to the pros. But there seems to be a very strong move to rewrite all core systems in rust. My issue with that is the fact that these tools don’t even invent anything new. Or change / improve the status co. I understand that it’s hard to introduce a new system without breaking other stuff. But our systems are still based on decisions from the telegraph age. Layers on top of layers on top of layers.

Re: Hard Rust requirements from May onward

#427

Post by jeroenhd »

tmtvl wrote: post #245
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…

> 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. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under https://github.com/pop-os/cosmic-applets >), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreuti…

> pretty much unreadable

I disagree. Both seem perfectly readable, assuming you know their preferred coding styles. As a non-C programmer, I absolutely despise running into #ifndef SOME_OBSCURE_NAME and `while (n) { if (g) {` but C (and in the latter case Go) programmers seem to love that style.

Comparing a bunch of small, barely integrated command line programs to a UI + calendar widget doesn't seem "of similar complexity" to me. Looking at a C clock widget (https://gitlab.freedesktop.org/xorg/app/xclock/-/blob/master...) the difference seems pretty minimal to me. Of course, the XClock code doesn't deal with calendars, so you have to imagine the extra UI code for that too.

Re: Hard Rust requirements from May onward

#428

Post by cbmuser »

gspr wrote: post #382
bluGill wrote: post #169

Earlier quoted context omitted.

m68k is used in a number of embedded systems today. It is unknown (to me) how many of those run linux (as opposed to some other embedded OS), but I would guess at least some do. I also don't know how many run (or want to run) debian vs something else (a custom yacto distribution is my first guess), but that might be non-zero. It is possible someone is running a non-debian distribution and using debian packages to pro…

Well, we are on a mission to create The Universal Operating System. So maybe. But I'm not sure. I think the new Rust dependencies are good. In an ideal world, the people who care about niche systems step up to help Rust target those systems.

> In an ideal world, the people who care about niche systems step up to help Rust target those systems.

I’m actually the person who added the m68k target to the Rust compiler and was also one of the driving forces of getting the backend into LLVM.

Generally speaking, getting a new backend into the Rust compiler is not trivial as it depends on LLVM support at the moment which is why asking someone to just do it is a bit arrogant.

Luckily, both rustc_codegen_gcc and gccrs are being worked on, so this problem will be resolved in the future.

Re: Hard Rust requirements from May onward

#429

Post by gpm »

josefx wrote: post #416

Is this the end of Debian as GNU/Linux? The main Rust toolchain isn't GNU, gccrs is still incomplete and most Rust rewrites of existing GNU libraries and tools use MIT or other non GPL licenses.

The main python and perl toolchains were never maintained by GNU either. Python has never been distributed under a GPL license. I'm not 100% sure of the licensing history of perl but I think it's always been available under a non-GPL license (as well as being under a GPL license - at least recently - not sure if that was always the case).

This doesn't seem like a noteworthy change to the degree to which GNU/Linux is an accurate name... though there are lots of things I'd put more importance on than GNU in describing debian (systemd, for instance).

Edit: Looks like Perl 1.0 was under the following non-commercial license, so definitely not always GPL though that now leaves the question of licensing when debian adopted it, if you really care.

> You may copy the perl kit in whole or in part as long as you don't try to make money off it, or pretend that you wrote it.

https://github.com/AnaTofuZ/Perl-1.0/blob/master/README.orig

Re: Hard Rust requirements from May onward

#430

Post by viraptor »

fweimer wrote: post #165
viraptor wrote: post #121

Earlier quoted context omitted.

Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

Interesting bit about SH-4. I thought that Renesas had previously promised parts availability until 2029?

Sh-4 is on the Product Longevity Program https://www.renesas.com/en/support/product-longevity-program... but what it actually means, I really cannot easily figure out. It's marked as "Last Time Buy" right now.
Post reply on HN