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

441–450 of 508 posts

Re: APT Rust requirement raises questions

#441

Post by adastra22 »

maximilianburke wrote: post #377
adastra22 wrote: post #325

Earlier quoted context omitted.

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?

That's not what "readability" generally means. Yes, Rust's semantics are more tightly locked down, and that's a big part of why I use it. But given two well-written source files, one in modern C++ and one in contemporary Rust, can you quickly skim and understand what each one is supposed to be doing, irregardless of bugs that might be lurking? If you made me guess right now which one I'd have an easier time understanding, I'd guess the C++ file.

Re: APT Rust requirement raises questions

#442

Post by morshu9001 »

Aurornis wrote: post #312
mixmastamyk wrote: post #299

Earlier quoted context omitted.

> Being explicit adds syntax. Not what they are talking about. Rather better to use words instead of symbols, like python over perl. Instead of “turbofish” and , there could be more key words like mut or dyn. Semicolons and ‘c’har are straight out of the seventies as well. :: not useful and ugly, etc. Dunders avoid namespace collisions and are not a big problem in practice, all one char, and easy to read. I might rem…

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.

I've been relying on Python for a decade+ and still think twice about the indentation. Straight up bad design, and you can't even attribute it to the original use case of dirty scripting cause it's particularly bad in a REPL.

Re: APT Rust requirement raises questions

#443

Post by nofunsir »

zanellato19 wrote: post #384
nofunsir wrote: post #244

Earlier quoted context omitted.

Not nonsense. Don't be reductive.

I think you are being reductive on your original comment. The idea of cycling planning and implementation is nothing new, and quite used on the other disciplines. Saying that agile is the problem is misguided and pointing to other engineering disciplines for "they do it better" is usually a sign that you don't talk to those engineers. Of course we can plan things better, but implementation does inform planning and vi…

I don't think this is productive, since you're so adamant [1] that "big C memory safe programs don't exist." I know for a fact they do. Most of the software you won't ever see. What do you think powers the most critical sytems in, say a fifth gen fighter, or the software that NSA relies on in their routers?

I'll give you a hint. It's neither rust- nor scrum-based. I'd rather change careers or retire than work another day doing scrum standups.

[1] https://news.ycombinator.com/item?id=45353150

Re: APT Rust requirement raises questions

#444

Post by teunispeters »

maximilianburke wrote: post #103
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…

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

Honestly, rust is slightly more readable than obfuscated perl. I think I prefer K&R C, and I don't like K&R C. In terms of readability, maybe equivalent to early Win32 API? [3000 lines to set up API, then call to activate].

With C++ you have a range of readable from - easy and very approachable - to 2000s era Microsoft STL. (where not only is it close to unreadable, many many hidden bugs are ... somewhere. And behaviour is not consistent).

I will admit I don't find Rust quite as unreadable as the 2000s era Microsoft STL, but the latter's one of the things that pushed me far more into Linux dev.

Rust is the kind of language that would push me to write a new language that isn't rust. And maybe work on supporting all the zillion platforms rust doesn't support. Or maybe just stick to C. I'm not a fan, but there are worse, and yeah - there are some C++ libraries out there that are worse. Lots that are better, too, eg llvm source.

Re: APT Rust requirement raises questions

#445

Post by NekkoDroid »

superxpro12 wrote: post #123
enriquto wrote: post #96

Earlier quoted context omitted.

> I am thrown back by how... "janky" the syntax is. Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful languag…

As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions. IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.

Do note that a (I think standardized) common package specification is being worked on called CPS (Common Package Specification). It doesn't specify how you get your dependencies, but it does specify how they should look like, so that your actual package manager does not need to care about the build system specific formats as it currently does.

Re: APT Rust requirement raises questions

#446

Post by anarki8 »

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 insert my favorite language.

In this specific case we are talking about the maintainer adding a new language into the existing codebase.

I think refactoring parts of the software in the new language is what you call "rewrite" here, correct?

So what improvements does it bring? You actually answered it yourself:

> it's not just a matter of pretty types and memory safety

So indeed, stricter/stronger type system and additional automatic compile time and runtime checks are a major improvement.

> platform

As already mentioned in this thread: neither of the platforms lacking Rust were supported officially anyways.

> language stability

Rust is extremely stable and backwards compatible - 1.0 code still compiles without any issues on 1.90 and will continue to do so for the forseeable future.

> skill and expertise of the authors

The same developers continuing to contribute and newcoming developers have more checks in place to prevent bugs.

> development speed

I guess you imply here that developing in C++ is faster. It's in fact not if your aim is to produce correct software. There are so many more things to keep in mind and take care of with C++, you have fewer automatic checks being done by the compiler and the type system.

About Zig: it's a nice language and much more comfortable to use than C/C++ IMO, but compared to Rust it lacks in strictness and safety, so added benefits are smaller and fewer if you put away subjective preferences.

Re: APT Rust requirement raises questions

#447

Post by pornel »

Surac wrote: post #387

my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.

That's just your lack of familiarity with the foreign-to-you language (you may be unable to read Korean too, despite Korean being pretty readable).

Syntactically, Rust is pretty unambiguous, especially compared to C-style function and variable definitions. You get fn and let keywords, and definitions that are generally read left-to-right, instead of starting with an arbitrary identifier that may be a typedef, a preprocessor macro, or part of a type that is read in so-called "spiral" order (which isn't even a spiral, but more complex than than).

Re: APT Rust requirement raises questions

#448

Post by maximilianburke »

teunispeters wrote: post #444
maximilianburke wrote: post #103

Earlier quoted context omitted.

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

Honestly, rust is slightly more readable than obfuscated perl. I think I prefer K&R C, and I don't like K&R C. In terms of readability, maybe equivalent to early Win32 API? [3000 lines to set up API, then call to activate]. With C++ you have a range of readable from - easy and very approachable - to 2000s era Microsoft STL. (where not only is it close to unreadable, many many hidden bugs are ... somewhere. And behavi…

How much Rust have you written?

Re: APT Rust requirement raises questions

#449

Post by soiltype »

xscott wrote: post #289
J_Shelby_J wrote: post #249

Earlier quoted context omitted.

exactly. you specify types for function parameters and structs and let the language do it's thing. it's a bit of a niche to specify a type within a function... There is a reason the multiple methods detailed above exist. Mostly for random iterator syntax. Such as summing an array or calling collect on an iterator. Most Rust devs probably don't use all of these syntax in a single year or maybe even their careers.

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 readable. Instead, some cases are going to be tradeoffs so that the more common cases can flow unimpeded.

Re: APT Rust requirement raises questions

#450

Post by 1313ed01 »

yjftsjthsd-h wrote: post #400
powerclue wrote: post #107

Earlier quoted context omitted.

Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?

Some of us abandoned commercial OSs for Debian precisely to escape that mentality.

I used Debian since around version 1.2 (even if not always as my main desktop OS) but increasingly using FreeBSD and NetBSD on my old computers.
Post reply on HN