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

681–690 of 797 posts

Re: Hard Rust requirements from May onward

#681

Post by mgh95 »

jacquesm wrote: post #646
mgh95 wrote: post #379

Earlier quoted context omitted.

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.

Unfortunately, that is the way rust set up their toolchain. In many ways, and for most if not all ecosystems, I do agree with you.

Re: Hard Rust requirements from May onward

#682

Post by uecker »

physicsguy wrote: post #666
uecker wrote: post #314

Earlier quoted context omitted.

I never found it hard to add a C library to my projects using pkg-config. And yes, when the package came from Debian I have some trust that it is not a huge supply chain risk. I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager man…

pkg-config isn’t the hard bit though, is it? Usually the hard bit with C libraries is having dependencies with dependencies all of which use their own complex build systems, a mix of Make, CMake, Autotools, Ninja, etc. Then within that for e.g. a mix of using normal standard names for build parameters and not e.g. PROJECTNAME_COMPILER instead of CMAKE_C_COMPILER

The package manager takes care of the dependencies. And one does not need to compile the libraries one uses, so how complicated this is does not matter. I install the -dev package and I am done. This works beautifully and where it does not the right move would be to fix this.

Re: Hard Rust requirements from May onward

#683

Post by drnick1 »

a-dub wrote: post #381
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 kinda ugly. i think i like zig better.

Actually I agree. I wish Rust kept the basic C syntax for function etc. I really hate def, fn, and other such keywords.

Re: Hard Rust requirements from May onward

#684

Post by julian-klode »

hunterpayne wrote: post #600
julian-klode wrote: post #514

Earlier quoted context omitted.

Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change. As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

All these changes requires work. Because of this, other priorities will get less attention. It would be ironic if bad security flaws are missed/introduced because of all the work switching to Rust. Its also very likely that all the new code written in Rust will be far less mature than the existing source bases. So the outcome might be (very probably actually) a lot of work to worsen security. Most of the academic res…

It's not like I'm in a hurry to switch to Rust and will spend full steam on it. It's amongst the lowest priority items.

A lot of the Rust rewrites suffer a crucial issue: they want a different license than what they are rewriting and hence rewrite from scratch because they can't look at the code.

But here we're saying: Hey we have this crucial code, there may be bugs hidden in it (segfaults in it are a recurring source of joy), and we'll copy that code over from .cc to .rs and whack it as little as possible so it compiles there.

The problem is much more there on the configuration parser for example which does in a sense desparately need a clean rewrite, as it's way too sloppy, and it's making it hard to integrate.

In an optimal world I'd add annotations to my C++ code and have a tool that does the transliteration to Rust at the end; like when the Go compiler got translated from C to Go. It was glorious.

Re: Hard Rust requirements from May onward

#685

Post by blub »

egorfine wrote: post #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 Pasc…

The general problem is that there’s a lot of activists online nowadays. I used to call myself an activist, but now it’s a dirty word which I associate with obsessive behaviour, harassment, cancellation attempts and being generally obnoxious with the purpose of achieving some goal.

I think it’s a combination of religion decreasing in importance and social media driving people mildly nuts. Many undertakings are collecting “true believers”, turning into their religion and social media is how they evangelize.

Rust is a pretty mild case, but it still attracts missionaries.

So, the people are different, Western society’s different and social media’s giving everyone a voice while bringing out the worst in them.

Re: Hard Rust requirements from May onward

#686

Post by drnick1 »

My main objection to Rust is how ugly it looks. Why did they have to change things such as how types and functions are defined? I really hate keywords such as def, fn, and other "explicit" function declarations. Also all the :: and from C++. Language-wise Java and C# did a much better job at introducing the features they needed without breaking the readability and familiarity of C.

Re: Hard Rust requirements from May onward

#687

Post by throwaway7356 »

perlgeek wrote: post #516
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…

> Shell (which probably means specifically bash) Debian has ongoing efforts to make many shell scripts (like postinst Scripts in packages etc.) non-bash-specific. A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.

> A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.

Please don't make up wrong facts that would be trivial to check first.

All minimal Debian installations include bash as it is an essential package. Where essential is used in the sense of https://www.debian.org/doc/debian-policy/ch-binary.html#esse...

Re: Hard Rust requirements from May onward

#688

Post by throwaway7356 »

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

Debian doesn't ship files in /usr/local.

You can of course add your own "apt" binary in /usr/local/bin/apt which can be written in any language you like, say COBOL, Java, Common Lisp or Python.

Re: Hard Rust requirements from May onward

#689

Post by _kidlike »

steveklabnik wrote: post #464
samdoesnothing wrote: post #440

Earlier quoted context omitted.

Oh please, in a decade Rust will also be technical debt and people will be wanting to write it in Brust or whatever is the trendy new language.

It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.

but we do... 4 years after Rust, we got a first glimpse at Zig. Even today, there's a lot of people that believe that Zig would have been a better choice for the Linux kernel than Rust.

And the answer to "why now" is quite simple - Because of the whole Rust in kernel debate, people started scrutinizing the situation.

Re: Hard Rust requirements from May onward

#690

Post by t43562 »

gspr wrote: post #506
t43562 wrote: post #483

I've been trying to build a debian package recently. I didn't have any crashes but I couldn't work out how to do it especially with the unbelievably contradictory and confusing documentation. I'm so glad I mainly use makepkg on Artix which is MUCH easier. I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.

Are you sure you're not conflating documentation with random people's writings on the web? Because that there seems to be a helluva lot of cargo culting on this topic.

When the primary documentation is of no use one looks for anything else that can possibly help and a lot of that is out of date.
Post reply on HN