Live data from Hacker News

APT Rust requirement raises questions

lwn.net

341–350 of 508 posts

Re: APT Rust requirement raises questions

#341
post #283

Earlier quoted context omitted.

Only `b` has the equivalent of "superfluous parens". It's practically your job to defend Rust, so I don't expect you to budge even one inch. However, I hate the idea of letting you mislead the casual reader that this is somehow equivalent and "just how languages work". The grammar could've used `Generic[Specific]` with square brackets and avoided the need for the turbo fish.

> The grammar could've used `Generic[Specific]` with square brackets and avoided the need for the turbo fish. But then people would grouse about it using left-bracket and right-bracket as brackets in a type "context".

Lol, yes they would. However, I wouldn't. :-)

Re: APT Rust requirement raises questions

#342

Earlier quoted context omitted.

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

Related from a couple of days ago: A time-traveling door bug in Half Life 2

https://mastodon.gamedev.place/@TomF/115589875974658415

https://news.ycombinator.com/item?id=46009962

Re: APT Rust requirement raises questions

#343
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…

[dead]

Re: APT Rust requirement raises questions

#344
post #326

Earlier quoted context omitted.

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…

You can’t change things faster than persuading the people that maintain the things. Over-the-top evangelism doesn’t work well for persuasion.

On the other hand, the presence of an alternative is the persuasion.

It's very easy to justify for yourself why you aren't addressing the hard problems in your codebase. Combine that with a captive audience, and you end up with everyone running the same steaming heap of technical debt and being unhappy about it.

But the second an alternative starts to get off the ground there's suddenly a reason to address those big issues: people are leaving, and it is clear that complacency is no longer an option. Either evolve, or accept that you'll perish.

Re: APT Rust requirement raises questions

#345
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…

You might enjoy https://nim-lang.org/ which has a Python-like syntax with even more flexibility really (UFCS, command-like calls, `fooTemplate: stuff` like user-defined "statements", user-defined operators, term-rewriting macros and more. With ARC it's really just about as safe as Rust and most of the stdlib is fast by default. "High quality" is kind of subjective, but they are often very welcoming of PRs.

Anyway, to your point, I think a newbie could pick up the basics quickly and later learn more advanced things. In terms of speed, like 3 different times I've compared some Nim impl to a Rust impl and the Nim was faster (though "at the extreme" speed is always more a measure of how much optimization effort has been applied, esp. if the language supports inline assembly).

https://cython.org/ , which is a gradually typed variant of Python that compiles to C, is another decent possibility.

Re: APT Rust requirement raises questions

#346
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…

Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.

The lifetime syntax was taken from OCaml but it has somewhat different semarics than OCaml. I honestly get a bit tripped up when I look at OCaml code (a language I'm a beginner at), and see ordinary parameterized types using syntax that suggests to me, from a Rust background, "woah, complex lifetime situation ahead!"

I know that Graydon Hoare is a fan of OCaml and that it was a core inspiration for Rust, and I sometimes wonder if he gets tripped up too by having to switch between Rust-inspired and OCaml-inspired interpretations of the same characters.

Re: APT Rust requirement raises questions

#347
post #335
post #318

Earlier quoted context omitted.

> This is like complaining that in C [...] It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anything. And I'm not defending C or C++ anyways. When I was trying to learn Rust (the second time), I wanted to know how to make my own types. As such, the macro `vec!` mentioned elsewhere isn't really relevant. I was using `Vec` to figure things out so I could make…

> let v = Vec::new(); // Crap, I want to specify the type of Vec This kinda implies you've gone wrong somewhere. That doesn't mean there aren't cases where you need type annotations (they certainly exist!) but that if `Vec::new()` doesn't compile because the compiler couldn't deduce the type, it implies something is off with your code. It's impossible to tell you exactly what the problem was, just that ` >::new()` is…

Nah, there's lots of times you need to specify the types of Vec, either because

1. You don't want the default `i32` integer type and this is just a temporary vector of integers.

2. Rust's type inference is not perfect and sometimes the compiler will object even though there's only one type that could possibly work.

Edit: The >::new() syntax is definitely never used though.

Re: APT Rust requirement raises questions

#348

Earlier quoted context omitted.

This is just personal preferences and familiarity Python using indenting to convey specific programming meaning feels janky and outdated to people not familiar with Python, but Python familiar programmers don't think twice about it.

No, it’s not only familiarity. I learned C/C++ in the early 90s, before Python. It’s well studied that words are easier to read than nested symbols.

Maybe it's my math background but I honestly prefer symbols to keywords. It's more up front cost in learning, but it's much more efficient in the long run.

Re: APT Rust requirement raises questions

#349
post #237

""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…

You seem to be involved with 9front. Are you trying to suggest there is a nontrivial community of people who cannot afford modern 64-bit Linux platforms, and opt for 9front on some ancient 32-bit hardware instead? Where are they coming from? Don't get me wrong, I love the 9 as much as the next guy, but you seem to paint it as some kind of affordability frontier...

> 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 prominent user recently ported it to cheap MIPS routers so we can run Plan 9 on cheap second hand network hardware. We have the tool chain support so we use it.

And believe me, I understand a raspberry pi or whatever is much faster and uses less power but I would rather we reduce e-waste where possible. I still run old 32 bit systems because they work and I have them.

Re: APT Rust requirement raises questions

#350

Earlier quoted context omitted.

Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.

There’s syntax that is objectively easier to both read and write, and there’s syntax that is both harder to read and write. For a majority. In general, using english words consisting of a-z is easier to read. Using regex-like mojibake is harder. For an concrete example in rust, using pipes in lambdas, instead of an arrow, is aweful.

I don't think it's an awful choice, but I'll admit that pipes in lambdas are not my favorite bit of syntax. I'm not a fan of them in Ruby either. I personally prefer JavaScript-ish => for lambdas. But I'm not gonna try to bikeshed one syntax decision made over a decade ago that has relatively minor consequences for other parts of the language. The early Rust core team had different taste than I do essentially, and that's fine.
Post reply on HN