Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

APT Rust requirement raises questions

lwn.net

Post reply on HN
Print view View original

371–380 of 508 posts

Re: APT Rust requirement raises questions

#371

Post by josefx »

steveklabnik wrote: post #180
dboon wrote: post #98

Earlier quoted context omitted.

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something yo…

This is just a variation of the "skill issue" argument. If it were correct, we wouldn't see these issues continue to pop up. But we do.

I think it is more a matter of convenience. There are countless string implementations for C, some tiny projects, others part of larger frameworks like Glib. At the end of the day a C developer has to decide if they are going to pull in half of gnome to handle a few lines of IO or if they are just going to use the functions the C standard conveniently ships with. Most people are going to do the later.

Re: APT Rust requirement raises questions

#372

Post by razighter777 »

antonvs wrote: post #309
travisgriggs wrote: post #243

Earlier quoted context omitted.

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel s…

Much of the drive to rewrite software in Rust is a reaction to the decades-long dependence on C and C++. Many people out there sit in the burning room like the dog in that meme, saying "this is fine". Most of them don't have to deal at all directly with the consequences involved. Rust is the first language for a long time with a chance at improving this situation. A lot of the pushback against evangelism is from peop…

> I'd rather see over-the-top evangelism than the lack of it, because the latter implies that things aren't going to change very fast.

No new technology should be an excuse to engage in unprofessional conduct.

When you propose changes to software, you listen to feedback, provide analysis of the benefits and detriments, and make an informed decision.

Rust isn't special, and isn't a pass to cause endless heartache for end users and developers because your code is in a "safer" language.

New rust code should be held to the same standards as new C and C++ code that causes breakage.

Evangelism isn't useful here, let the tool speak for itself.

Re: APT Rust requirement raises questions

#373

Post by crote »

pjmlp wrote: post #336
razighter777 wrote: post #172

Earlier quoted context omitted.

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…

I fully agree, and in what concerns command line utility applications I see no benefit of using Rust's borrow checker. At most if a rewrite would happen, it makes much more sense in a compiled language with automatic resource management.

Command line utilities often handle not-fully-trusted data, and are often called from something besides an interactive terminal.

Take for example git: do you fully trust the content of every repository you clone? Sure, you'll of course compile and run it in a container, but how prepared are you for the possibility of the clone process itself resulting in arbitrary code execution?

The same applies to the other side of the git interaction: if you're hosting a git forge, it is basically a certainty that whatever application you use will call out to git behind the scenes. Your git forge is connected to the internet, so anyone can send data to it, so git will be processing attacker-controlled data.

There are dozens of similar scenarios involving tools like ffmpeg, gzip, wget, or imagemagick. The main power of command line utilities is their composability: you can't assume it'll only ever be used in isolation with trusted data!

Re: APT Rust requirement raises questions

#374

Post by mystifyingpoi »

inetknght wrote: post #355
surajrmal wrote: post #209

Earlier quoted context omitted.

Integration tests are still tests. There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests. I've written a lot of code generation tools this way for instance.

> Integration tests are still tests. I didn't say they're not. Integration tests definitely help towards "being tested". > There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests. Very strong disagree. I think there are no cases where a strong integration test regime can allow a software project to forego unit tests. Now, that said, we're probably talking the…

> I think unit tests with mocks are practically useless

IMO that's on the extreme side too. I've seen a fair share of JUnit monstrosities with 10+ mocks injected "because the project has been written this way so we must continue this madness", but mocking can be done right, it's just overused so much that, well, maybe you're right - it's easier to preach it out than teach how to do it right.

Re: APT Rust requirement raises questions

#375

Post by steveklabnik »

renewiltord wrote: post #364
steveklabnik wrote: post #337

Earlier quoted context omitted.

> Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Where are you seeing this happen? I'm curious because I never have, which means that I'm missing out on discussions somewhere.

Sure, it's on Reddit /r/rust. I'll provide links at the end, but it happens every time there is a donation. > > > Multi trillion dollar conglomerate invests a minuscule fraction of a fraction of their monthly revenue into the nonprofit foundation that maintains the tool that will save them billions > > 115 Billion / 365 days / 1440 minutes = ~ 220k > > So they make around 220k per minute, 350k in under 2 minutes. Sti…

Thank you! I read the Rust subreddit less these days, I know I missed at least some of those threads. Maybe I should pay more attention again...

I agree those people are being pretty ridiculous.

> And if you think I'm some guy with an axe to grind

Nah, I was just like "hmm, I don't remember really seeing that, interesting." An actual honest question, no shade implied.

Re: APT Rust requirement raises questions

#376

Post by pxc »

SoftTalker wrote: post #190
pxc wrote: post #138

Earlier quoted context omitted.

What's wrong with R? I used it and liked it in undergrad. I certainly didn't use it as seriously as the users who made Python popular, but to this day I remember R fondly and would never choose Python for a personal project. My R use was self-taught, as well. I refused to use proprietary software for school all through high school and university, so I used R where we were expected to use Excel or MatLab (though I usu…

R is the most haphazard programming environment I've ever used. It feels like an agglomeration of hundreds of different people's shell aliases and scripting one-liners. I'll grant my only exposure has been a two- or three-day "Intro to R" class but I ran screaming from that experience and have never touched it again. It maybe worked against me that I am a programmer, not a statistician or researcher.

When I used it I was a computer science student. But I wasn't reading anyone else's code or trying to maintain anything complex, which is why I asked what I did. I'm sure there are quirks I never had to deal with.

So is it just that the stdlib is really big and messy?

Re: APT Rust requirement raises questions

#377

Post by maximilianburke »

adastra22 wrote: post #325
maximilianburke wrote: post #103

Earlier quoted context omitted.

In your opinion how does Rust compare to C++ for readability?

C++ is vastly more readable. I will never go back to writing or maintaining C++ projects, but drop me into a C++ file to review something and it is usually very easy to grok. Part of this is style and conventions though. I have implemented an STL container before, and that templating hell is far worse than anything I’ve ever seen in the Rust ecosystem. But someone following modern C++ conventions (e.g. a Google libra…

How do you handle understanding the semantics in the presence of custom overloaded operators?

Re: APT Rust requirement raises questions

#378

Post by razighter777 »

travisgriggs wrote: post #243
razighter777 wrote: post #172

Earlier quoted context omitted.

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel s…

Most of us sane people tend to be more quiet unfortunately.

I enjoy rust, but I enjoy not breaking things for users and making lives harder for other devs even more.

Re: APT Rust requirement raises questions

#379

Post by ForHackernews »

razighter777 wrote: post #172
geerlingguy wrote: post #5

I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…

> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse.

They already have a Rust toolchain for every system Debian releases for.

The only architectures they're arguing about are non-official Debian ports for "Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4)", two of which are so obscure I've never even heard of them and one of the others most famous for powering retro video game systems like Sega Genesis.

Re: APT Rust requirement raises questions

#380

Post by ActorNightly »

WD-42 wrote: post #116
dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me. Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right t…

>Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime.

I feel like this sentiment is from people who haven't really took the time to fully see what the Python ecosystem is.

Any language can have shittly written code. However languages that by default disallow it means that you have to spend extra time prototyping things, whereas in Python, you can often make things work without much issue. Dynamic typing and attributes make the language very flexible and easily adaptable.

Post reply on HN