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

261–270 of 508 posts

Re: APT Rust requirement raises questions

#261

Post by dontlaugh »

xscott wrote: post #165
movpasd wrote: post #84

Earlier quoted context omitted.

You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think…

I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes: let mut a = Vec:: ::new(); let mut b = >::new(); let mut c = >::new(); let mut d: Vec = Vec::new(); Which one will your coworker choose? What will your other corworkers choose? This is day one stuff for declaring a dynamic array. What you really want is something like: let…

This will be the case in any language with both generics and type inference. It's nothing to do specifically with Rust.

Re: APT Rust requirement raises questions

#262

Post by cogman10 »

maeln wrote: post #10

You know, it is easy to find this kind of nitpicking and seemingly eternal discussion over details exhausting and meaningless, but I do think it is actually a good sign and a consequence of "openness". In politics, authoritarianism tend to show a pretty façade where everyone mostly agrees (the reality be damned), and discussion and dissenting voice are only allowed to a certain extent as a communication tool. This is…

What?

Opensource software doesn't have 1 governance model and most of it starts out as basically a pure authoritarian run.

It's only as the software ages, grows, and becomes more integral that it switches to more democratic forms of maintenance.

Even then, the most important OS code on the planet, the kernel, is basically a monarchy with King Linus holding absolute authority to veto the decision of any of the Lords. Most stuff is maintained by the Lords but if Linus says "no" or "yes" then there's no parliament which can override his decision (beyond forking the kernel).

Re: APT Rust requirement raises questions

#263

Post by stingraycharles »

MisterTea wrote: post #212

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import dutie…

Poor people aren’t running exotic hardware.

Re: APT Rust requirement raises questions

#264

Post by brobdingnagians »

nerdponx wrote: post #195
nofunsir wrote: post #176

Earlier quoted context omitted.

Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than t…

As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.

Perhaps that is the ideal when it was laid out, but the reality of the common implementation is that planning is dispensed with. It gives some management a great excuse to look no further than the next jira ticket, if that.

The ideal implementation of a methodology is only relevant for a small number of management who would do well with almost any methodology because they will take initiative to improve whatever they are doing. The best methodology for wide adoption is the one that works okay for the largest number of management who struggle to take responsibility or initiative.

That is to say, the methodology that requires management to take responsibility in its "lowest energy state" is the best one for most people-- because they will migrate to the lowest energy state. If the "lowest energy state" allows management to do almost nothing, then they will. If the structure allows being clueless, a lot of managers will migrate to pointy haired Dilbert manager cluelessness.

With that said; I do agree with getting products to clients quickly, getting feedback quickly, and being "agile" in adapting to requirements; but having a good plan based on actual knowledge of the requirements is important. Any strict adherence to an extreme methodology is probably going to fail in edge cases, so having the judgement of when to apply which methodology is a characteristic of good management. You've got to know your domain, know your team, and use the right tool for the job.

Re: APT Rust requirement raises questions

#265

Post by tyfon »

cogman10 wrote: post #252
tyfon wrote: post #204

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…

This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch? You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power. You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take…

The system is actually running fine standalone since I have been able to avoid rust software.

As to why it should cater to it, it's more that there is no need to remove something that already works just to remove it.

It is possible to compile rustc on another system so it supports i586 and below. Just a small change in the command line options. And it doesn't degrade the newer systems.

I have plenty of faster machines, I just enjoy not throwing things away or making odd systems work. It's called having fun :)

Re: APT Rust requirement raises questions

#266

Post by ShroudedNight »

ShroudedNight wrote: post #257
tyfon wrote: post #247

Earlier quoted context omitted.

Yes, sorry I remembered incorrectly. The rust compiler claims to be i686 and the CPU is i686 too, but the rust compiler is using Pentium 4 only instructions so it doesn't actually work for i686.

Yeah, that sucks. I assume this is SSE2?

It does look like there are legitimate issues with x87 floating-point: https://github.com/rust-lang/rust/issues/114479

Re: APT Rust requirement raises questions

#267

Post by tyfon »

ShroudedNight wrote: post #257
tyfon wrote: post #247

Earlier quoted context omitted.

Yes, sorry I remembered incorrectly. The rust compiler claims to be i686 and the CPU is i686 too, but the rust compiler is using Pentium 4 only instructions so it doesn't actually work for i686.

Yeah, that sucks. I assume this is SSE2?

That is correct :)

Edit: I see from the sister post that it is actually llvm and not rust, so I'm half barking up the wrong tree. But somehow this is not an issue with gcc and friends.

Re: APT Rust requirement raises questions

#268

Post by tucnak »

leoh wrote: post #87

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making th…

Can you confirm these C++ fascists you speak of are in the room with you right now?

Re: APT Rust requirement raises questions

#269

Post by dontlaugh »

mbel wrote: post #131
stingraycharles wrote: post #52

Earlier quoted context omitted.

Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem. I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.

> It’s less simple than many systems languages because it has a very strong type system. I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.

There is no other ML-like that is as low level. Except perhaps ATS, which has terrible syntax.

Re: APT Rust requirement raises questions

#270

Post by dragonwriter »

steveklabnik wrote: post #260
xscott wrote: post #233

Earlier quoted context omitted.

This is some True Scotsman style counter argument, and it's hard for me to make a polite reply to it. There are people who program with a "fake it till you make it" approach, cutting and pasting from Stack Overflow, and hoping the compiler errors are enough to fix their mess. Historically, these are the ones your pages/books cater to, and the ones who think the borrow checker is the hard part. It doesn't surprise me…

The issue though is that this isn't a solvable "problem". This is how programming languages' syntax work. It's like saying that C's if syntax is bad because these are equivalent: if (x > y) { if ((x > y)) { if (((x) > (y))) { Yes, one of your co-workers may write the third form. But it's just not possible for a programming language to stop this from existing, or at least, maybe you could do it, but it would add a ton…

Well, the solution usually isn't in syntax, but it often is solved by way of code formatters, which can normalize the syntax to a preferred form among several equivalent options.
Post reply on HN