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

411–420 of 797 posts

Re: Hard Rust requirements from May onward

#411

Post by [deleted] »

JW_00000 wrote: post #195
cmm11 wrote: 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

To be honest I don't really read insults either in this e-mail or in the thread you linked. If I'm seeing it right, there's only one comment by the guy in that thread, right? That comment is direct and uses language that may be considered unprofessional ("crap"/"crappy"), but it's not insulting the users (they are not referred to as crappy). Same for the e-mail. Unnecessary drama as usual...

[deleted]

Re: Hard Rust requirements from May onward

#412

Post by ugh123 »

>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 software on retro computing devices.

Loved this statement on the state of modern software using the backbone of C (in linux and elsewhere)

Re: Hard Rust requirements from May onward

#413

Post by throwaway2037 »

jcranmer wrote: post #316
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…

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.

Re: Hard Rust requirements from May onward

#414

Post by dathinab »

JW_00000 wrote: post #195
cmm11 wrote: 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

To be honest I don't really read insults either in this e-mail or in the thread you linked. If I'm seeing it right, there's only one comment by the guy in that thread, right? That comment is direct and uses language that may be considered unprofessional ("crap"/"crappy"), but it's not insulting the users (they are not referred to as crappy). Same for the e-mail. Unnecessary drama as usual...

mainly people have issues with clear, precise and concise language about intend of action instead of idk. a request of discussion

now this is separate from being open for discussion if someone has some good arguments (which aren't "you break something which isn't supported and only nich used") and some claim he isn't open for arguments

and tbh. if someone exposes users to actual relevant security risk(1) because the change adds a bit of in depth security(2) and then implicitly denounces them for "wanting crap" this raises a lot of red flags IMHO.

(1): Copy pasting passwords is a very bad idea, the problem is phsishing attacks with "look alike" domains. You password manager won't fill them out, your copy past is prone to falling for it. In addition there are other smaller issues related to clip board safety and similar (hence why KC clears the clipboard after a short time).

(2): Removing unneeded functionality which could have vulnerabilities. Except we speak about code from the same source which if not enabled/setup does pretty much nothing (It might still pull in some dependencies, tho.)

but yes very unnecessary drama

Re: Hard Rust requirements from May onward

#415

Post by sesm »

the_duke wrote: post #391
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…

Anyone capable of programming and willing to invest enough time will be able to learn Rust, in my opinion. It might take some people months rather than days, but I think that is a desirable outcome. Important low level software should be written by competent developers willing to invest the effort.

The effort should rather be invested into learning how underlying hardware works and introducing redundancy and observability into the system.

Re: Hard Rust requirements from May onward

#418

Post by dokyun »

thiht wrote: post #116
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.

> I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. Not sure how that’s relevant when CL is basically dead and no one wants to work with it, while Rust is flourishing and delivering value

Rust isn't 'delivering value', people are just drinking the koolaid. CL has its niches, and it still fills them well: it's never been that successful as a general-purpose language.

Re: Hard Rust requirements from May onward

#419

Post by 1vuio0pswjnm7 »

cmrdporcupine wrote: post #327
krater23 wrote: post #284

Earlier quoted context omitted.

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.

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 stands to reason that the embedded programmer commenting was unable to determine how to avoid using cargo and pulling in unnecessary dependencies. Otherwise he would not have encountered this problem

Re: Hard Rust requirements from May onward

#420

Post by dang »

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.

Can you please make your substantive points thoughtfully instead of posting in the flamewar style? We're trying for the one and not the other here: https://news.ycombinator.com/newsguidelines.html.

(We detached this subthread from https://news.ycombinator.com/item?id=45782109.)

Post reply on HN