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

471–480 of 508 posts

Re: APT Rust requirement raises questions

#471

Post by catlifeonmars »

pornel wrote: post #438
stonemetal12 wrote: post #42

Earlier quoted context omitted.

Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?

Cargo isn't satisfied with its own solver either. Solvers are a hard and messy problem. The problem is theoretically NP complete (a SAT solver), but even harder than that: users also care about picking solutions that optimize for multiple criteria like minimal changes, more recent versions, minimal duplication (if multiple versions can coexist), all while having easy-to-understand errors when dependencies can't be sa…

Go’s solver has been my favorite so far. But it relies on semver actually being meaningful.

Re: APT Rust requirement raises questions

#472

Post by eviks »

epolanski wrote: post #314
anarki8 wrote: post #133

Earlier quoted context omitted.

> The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. > There's lunatics ... I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite. Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/ Applying strict compile time rules makes software…

My point had nothing to do with languages. My point is against rewrites of critical software for the point of rewriting it *insert my favorite language*. Zig is also a safer language than C, so are many other alternatives, yet the Zig community is not obsessed in rewriting old software but writing new one. And the Zig compiler has excellent C interop (in fact it can compile C/C++), yet the community is more focused i…

> My point is against rewrites of critical software for the point of rewriting it

Because you're replacing a real point with a made up one, the reason for rewriting is to get the critical benefits for critical software, which battle testing has shown can't be had in the current language, not "my favorite"

> Zig community is not obsessed

They don't even have a 1.0 language? You're also ignoring the critical difference in the level of safety

Re: APT Rust requirement raises questions

#473

Post by xscott »

echelon wrote: post #464
xscott wrote: post #391

Earlier quoted context omitted.

> Rust isn't as hard or as bad as you think. I think this depends a LOT on what you're trying to do and what you need to learn to do it. If you can get by with the std/core types and are happy with various third party crates, then you don't really need to learn the language very deeply. However, if you want to implement new data structures or generic algorithms, it gets very deep very quickly.

Why would you say that? I feel this pushes people away. "Hey, you might be able to use Rust trivially if you stick to XYZ, but if you dare touch systems programming you're in for some real hurt. Dragons everywhere." Why say that? It's not even remotely true - it's a gradient of learning. You can use Rust for simple problems as a gateway into systems programming. Rust is honestly a great alternative to Python or Golan…

> Why would you say that? I feel this pushes people away.

It's not my obligation to evangelize for your pet language. I've spent enough time and written enough code in Rust to have a defensible viewpoint. This is public forum - I'll share my opinion if I want to.

Writing servers? Sure, go grab the crate that solves your problem and get on with it. Basically what I said above.

If I thought you would bother to do them, I could give you a list of concrete problems which ought to be super easy but are in fact really hard or ugly to do in Rust.

Phrases like "systems programming" have become so diluted that I'm not even sure what you mean. Once upon a time, that was something like writing a device driver. Now people use the phrase for things like parsing a log file or providing a web server.

I wanted to use Rust for numerical methods and data visualization. I didn't like the existing solutions, so I was willing to write my own Rust libraries from scratch. It was pretty painful, and the learning curve was steep.

> Why say that? It's not even remotely true

I didn't write the thing you quoted. Using a straw man argument like this is a lame tactic.

Re: APT Rust requirement raises questions

#474

Post by xscott »

soiltype wrote: post #449
xscott wrote: post #289

Earlier quoted context omitted.

Do these print statements print the same thing? let i = 1; let j = 1; print!("i: {:?}\n", !i); print!("j: {:?}\n", !j); let v = vec![1, 2, 3]; v[i]; There are definitely times you want to specify a type.

> There are definitely times you want to specify a type. So I'm coming from basically obly TypeScript type system experience but that seems completely ok to me. There are times I make my TS uglier to make it less ambiguous and times I make it more ambiguous to make it more readable. It's unreasonable imo that such a system could universally land on the most readable format even if we could all agree what's most reada…

The Rust example I showed changes behavior when you declare the types. It's not just a readability or bug catching thing.

Re: APT Rust requirement raises questions

#475

Post by fainpul »

adastra22 wrote: post #319
fainpul wrote: post #173

Earlier quoted context omitted.

The commenter I replied to seems to like Kotlin. Swift is extremely close to Kotlin in syntax and features, but is not for the JVM. Swift also has a lot of similarities with Rust, if you ignore the fact that it has a garbage collector.

A Kotlin for Rust would be a drop-in replacement where you could have a crate or even just a module written in this hypothetical language and it just works. No bridging or FFI. That’s not Swift.

You all need to stop with the hair-splitting – it's tiresome.

My intention was to offer something that might be of interest to the person I replied to – not to write the official definition of "Kotlin for Rust" which everybody has to agree to. If you think my answer is nonsense, just skip it and read the next one. No need to reply. Nobody profits from this discourse.

Re: APT Rust requirement raises questions

#477

Post by chillingeffect »

steveklabnik wrote: post #455
chillingeffect wrote: post #451

Earlier quoted context omitted.

True, but you might want to look into the licenses people are actually choosing for Rust versions of coreutils/uutils and who's promoting them.

Sure, those authors chose that license because they did not really particularly care for the politics of licenses and chose the most common one in the Rust ecosystem, which is MIT/Apache 2. If folks want more Rust projects under licenses they prefer, they should start those projects.

> If folks want more Rust projects under licenses they prefer, they should start those projects.

100% true, but also hides a powerful fact: Our choices aren't limited to doing it ourselves. Listening to others and discussing how to do things as a group is the essence of community seeking long-term stability abd fairness. It'a how we got to the special place we are now.

Not everyone can or should start their own open source project. Maybe theyre already doing another one. Maybe they don't know how to code. The viewpoint of others/users/customers is valid and should not only be listened to but asked for.

Re: APT Rust requirement raises questions

#478

Post by MisterTea »

cogman10 wrote: post #393
MisterTea wrote: post #349

Earlier quoted context omitted.

> Where are they coming from? One is in lives in Brazil and I think the other lives in the Middle East. They both have old second hand 32 bit laptops from the 00's. > but you seem to paint it as some kind of affordability frontier... Yes because there are people still using old hardware because they have no choice. Also, whats the problem with supporting old architectures? Plan 9 solved the portability problem and a…

> whats the problem with supporting old architectures? It's not free, it's not easy, and it introduces hard to test and rarely run code paths that may or may not have problems on the target architecture. I think there's a pretty strong argument for running hardware produced in the last 10 years for the next 10 or 20 years. However, I think it should be recognized that there was massive advances in compute power from…

> It's not free, it's not easy, and it introduces hard to test and rarely run code paths that may or may not have problems on the target architecture.

If your platform is designed properly it isn't much of an issue. This was bought up at a recent 9front hackathon and the lead dev stated that there is no reason to drop 386 or arm32. In fact, he said they are great test beds for shaking out cross platform bugs and tests all changes on 32 bit before committing.

Also, performance means nothing if the hardware is already there and capable of the job at hand.

Re: APT Rust requirement raises questions

#479

Post by bryanlarsen »

lagniappe wrote: post #460
bryanlarsen wrote: post #28

Earlier quoted context omitted.

Yes, the immediate and endless backlash we get whenever anybody says the word "Rust" is quite tiresome.

Ah yes, the signature snark from the Rust community. This is the type of thing that repels people.

Most of the repelling is happening on the anti-Rust side. The hate and vitriol has chased away Wedson Almeida Filho, Alex Gaynor, Hector Martin and Christoph Hellwig from the Rust in Linux project.

And it's happening here too. https://news.ycombinator.com/item?id=46048336 makes clear that most of the commentary here is just plain wrong, yet it's not upvoted to top.

Re: APT Rust requirement raises questions

#480

Post by gaanbal »

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…

sounds like something that could be solved with more learning

I wrote python for 15 years

I don't want to write python anymore. mainly rust if I can

Post reply on HN