Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

181–190 of 797 posts

Re: Hard Rust requirements from May onward

#181
post #31

Earlier quoted context omitted.

I find that languages with a high intellectual barrier to entry are much more pleasant places to be since people like the OP can't understand them and we never have people try to bully us into doing things _the right way_. This is someone who says things like >It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern…

> since people like the OP can't understand them and we never have people try to bully us Yes well, glad to hear there’s no one bullying people there!

I don't normally upvote snark, but... Bravo.

Elitism is it's own form of bullying and needs to be treated as such.

I don't particularly like large swaths of humanity, but I also try hard not to be elitist towards them either. I'm not always successful, but I make a strong effort as my family raised me to be respectful to everyone, even if you don't personally like them.

Re: Hard Rust requirements from May onward

#182

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…

[flagged]

> it's factually just better, am I right?

so cool to see people getting it!

Re: Hard Rust requirements from May onward

#183
I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go.

What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate?

I remember C vs Pascal flame back in the day but that wasn't serious. Like, at all. C/C++ developers today don't have any need to prove anything to anyone. It would be weird for a C developer to walk around and insult Rust devs, but the opposite is prevalent somehow.

Re: Hard Rust requirements from May onward

#184
post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

The HN post doesn't seem very confrontational to me, but some folks see it so, weird.

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

Re: Hard Rust requirements from May onward

#185

Earlier quoted context omitted.

Aren’t m68k computers only a few models from the 1990s and 1980s, and some more recent hobby projects? That’s squarely in the retro computing enthusiasts category. I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on…

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…

All I find searching for “embedded m68k Linux distro” is people looking for, or coming up with, alternatives, as Debian was already “too big” fifteen years ago.

I don’t get the fuzz around the “retro computing” verbiage. I doubt anyone is actually running Debian on these devices out of necessity, someone who plays baroque music in reconstructed period instruments won’t balk at being called an “early music” enthusiast.

Re: Hard Rust requirements from May onward

#186
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 know nobody that programms or even thinks about rust.

I think it isn’t reasonable to infer that nobody uses something because you don’t know anybody who uses it in your niche. I know lots of embedded programmers who use Rust.

Re: Hard Rust requirements from May onward

#187
> This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem.

By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification?

I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.

Re: Hard Rust requirements from May onward

#188

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…

[flagged]

While I get your view, I think examples would help to move the conversation along in a more constructive manner

Re: Hard Rust requirements from May onward

#189
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.

Many programmers feel the same way about Lispers. It's best to set aside your gut feelings about the community and think primarily about the technical and organizational merits and disadvantages of the technology.

I have similar feelings about the go community. I like go on the whole, but certain aspects are atrocious. The 'go community' is strangely cult-like and complaining about the language is generally poorly received. As a result I very rarely interact with them and just do my own thing.

Re: Hard Rust requirements from May onward

#190
post #34

Earlier quoted context omitted.

Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.

One of the most iconic lisp saying is literally about how every other languages are supposedly inferior to lisp, so I don't think it's a particularly good example here.

You mean the one that all languages eventually converge to Lisp? That's a fact though :)
Post reply on HN