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

291–300 of 797 posts

Re: Hard Rust requirements from May onward

#291

Post by tialaramex »

torstenvl wrote: post #283
tialaramex wrote: post #111

Earlier quoted context omitted.

> I think the spin that Rust is necessarily the way forward is what is wrong. I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust. If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and…

[flagged]

The word you omitted is key: Necessarily.

Re: Hard Rust requirements from May onward

#292

Post by tialaramex »

BobBagwill wrote: post #236
tialaramex wrote: post #35

Earlier quoted context omitted.

Right. I do have some nostalgia for installing Linux on a brand new PC which had less total RAM than my computer today has cache, but we need to be clear eyed about what makes sense for a maintained piece of software. I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025. A nostalgia-fuelled Linux distro, maybe using a deliberately slimmed down or retro kernel, and c…

> I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025. Solved problem: United States Patent Application 3127321 Date of Patent March 31, 1964 NUCLEAR REACTOR FOR A RAILWAY VEHICLE

Very Fallout

Re: Hard Rust requirements from May onward

#293

Post by brainwad »

onli wrote: post #166
superkuh wrote: post #157

Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…

I wouldn't see it that way. First, Debian is not a distro where users have to compile their software. The packages contain binaries, the compilation is already done. The instability of Rust would not affect users in any way. And second, as a developer, I never had a more unpleasant language to work with than Rust. The borrow checker back then was abysmal. Rust is not about developer happiness - Ruby is - but its memo…

> The instability of Rust would not affect users in any way.

Sure it would. Suppose a rust-based package has a security bug. Upstream has fixed it, but that fix depends on some new rust language feature that the frozen version of rust in Debian doesn't have yet.

Re: Hard Rust requirements from May onward

#295

Post by kstrauser »

cogman10 wrote: post #288
kstrauser wrote: post #277

Earlier quoted context omitted.

I don’t think that’s quite right. I haven’t written C++ since the 90s, and I use IDEs (Emacs and Zed), but I still sometimes reach a mental threshold where I look at my screen and see way too many names to have to hold in my mental buffer, then decide to make them more explicit.

IDK what the state of Emac/Zed is in terms of type information (I'm sure it depends on the language in question). For Jetbrains/Eclipse/Netbeans if there's a question about a type you can ctrl+click on the type and immediately pull all information about it. In java, I rarely pay attention to the `import` section (and I know most devs at my company). You can look up `using namespace std;` in google and you'll find a l…

All modern editors do that pretty well with language servers now. Specifically, Emacs and Zed do this perfectly with Rust.

I do think it’s down to personal preference. With the fully qualified names, I can look at the screen and follow the flow without having to mouse over the various names in play. For that matter, I could print it out if I wanted to and still have all the information.

I don’t think you’re objectively wrong. It’s more that we have different approaches to managing the complexity when it gets hairy.

Re: Hard Rust requirements from May onward

#296

Post by lambdaone »

cogman10 wrote: post #276
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.

Because there's so many PIC, MIP, and PS/2 systems out there running debian? The war is over. ARM and x86 won.

RISC-V is well on its way to be a challenger to both, with (eventually) full support for Rust.

Re: Hard Rust requirements from May onward

#297

Post by uecker »

crote wrote: post #61
uecker wrote: post #5

Earlier quoted context omitted.

I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interest…

> I think the spin that Rust is necessarily the way forward is what is wrong. Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that. C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad c…

While memory safety is important, I do not believe it is now suddenly so important that it needs now needs to be solved quickly at all cost. There are far more pressing issues. I also do not think at all that C/C++ are dead end. In fact, I think it would be far more cost effective to continue to improve safety of C and C++ code via gradual improvement than adding another language into the mix. The reason is that complexity and the burden of long-term maintenance is the main issue we have in free software, and Rust makes this worse rather than better. Case in point, the fact that I have limited security updates because of some Rust video codec in the dependency chain hurts my security far far more than the fact that it might prevent some memory safety issue: https://www.debian.org/releases/trixie/release-notes/issues.... I think this is what people are missing. They over-exaggerate the important of memory safety over rather mundane issues which are actually far more important. I have never known anybody who was directly affected by a security issues caused by memory safety, I know plenty who were affected because their software was not up-to-date.

Re: Hard Rust requirements from May onward

#298

Post by bitwize »

uecker wrote: post #5
CartwheelLinux wrote: post #2

The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…

I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interest…

Name me another language that offers the memory safety and deterministic runtime guarantees that Rust does, eliminating entire classes of bugs, the same integration with existing C code that Rust does, and enjoys the same community and pool of eager contributors that Rust does.

I'll wait.

Re: Hard Rust requirements from May onward

#299

Post by tmtvl »

codedokode wrote: post #43
noosphr wrote: post #13

I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences. They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.

How can lisp be fast if it doesn't have static typing and uses GC?

As a GC language Common Lisp is slow as molasses. However, in the realm of languages which are slow as molasses it's got quite acceptable performance. I suppose it's in part because it's alien technology from beyond the bounds of the multiverse, but also in part due to the fact that we had really interesting tech back in the '70s and '80s that kinda got lost during the so-called AI winter.

To add on to that, with declarations the programmer can tell the Lisp compiler that (for example) a variable can be stack allocated to help improve performance. The fact that Lisp code is just data is another benefit towards performance as it means macros are relatively easy to write so some computation can be done at compile time. There are also various useful utilities in the spec which can be used to help profile execution of a program to aid in optimization, such as time and trace.

Post reply on HN