On Wed, 21 Apr 2021 02:38:48 +1200
Miles Rout <miles_AT_rout.nz> wrote:
Dear Miles,
> On Tue, Apr 20, 2021 at 06:45:40AM -0700, Jeremy wrote:
> > Regarding readability: in terms of the just the standard libraries,
> > I agree that Rust is more readable than C, especially it comes to
> > iterating and generics.
>
> impl I<Don't> {
> fn know<'a, How::Someone>(could: &'a Say) -> This<'a>
> with A: Straight<Face> + Send + Sync + 'a
> { ... }
>
> static
> struct this *
> is_readable(struct to *me)
> { ... }
>
> Syntactically, Rust's generics are a total mess.
haha, you made my day! Rust code looks like a trainwreck, especially
when Rust is used to demonstrate that it can be as fast as C.
> Rust's iteration is even worse. Something that should be a simple
> matter of for (i=0;i<N;i++) is turned into a frightful palaver with
> the compiler with layer upon layer upon layer of complexity, and in
> the end it all ends up getting compiled (over the course of several
> minutes) into exactly the same for loop!
Good point. Ada provides safety without the bells and whistles, mostly
because it's access types are linear. This is a bit more limited than
Rust and you have to be more explicit at times, but I prefer it that
way.
> I really like this. Thanks for linking to it. This is the sort of
> thing that we (the programming community in general) need more of:
> stepping back from complexity and doing the minimum needed to actually
> work *effectively*. Does this have all the features of C++ templates?
> Of course not. It has the features one actually needs if one wants
> generic data structures (which one probably doesn't need anyway).
Yes, this point nicely merges into what I said before.
> > Regarding ISO-standardization: could you explain a bit more about
> > the value of this?
>
> Standardisation means there's a document you can read to understand
> whether something is a bug in your code, a bug in someone else's
> code, a bug in the implementation or (heavens forbid!) a bug in the
> specification. ISO-standardisation is the gold standard of
> standardisation because the rigorous process behind it ensures that
> every necessary detail is fixed down in precise technical writing.
>
> One of the side-benefits of this kind of writing is that it gives
> people a language in which to talk about the language. I'm not sure
> whether before C standardisation terms like declaration-specifier and
> declarator were precisely demarked in the way they are now. But now
> that they are, two people using different implementations in
> different countries with different backgrounds can establish a
> consensus on the correct syntactic interpretation of any piece of
> code.
>
> Of course in the case of C++, that interpretation might be 'it's
> syntactically correct... if the Riemann hypothesis is true'. But it's
> better than you can do for Rust, where what is correct behaviour is...
> whatever rustc does. Rust evangelists love to talk about how much
> undefined behaviour C has, but it only has undefined behaviour because
> it has defined behaviour! Undefined behaviour is behaviour that isn't
> defined... by the standard. Everything in Rust is undefined
> behaviour!
Very well put, thank you! Many also criticize Ada because it's
specification is so long (hundreds of pages), but as you said it's laid
out so explicitly so one can build on top of it and know when something
goes wrong.
> When OOP became trendy in the 80s-90s-00s, almost every
> language out there either added an OOP system or an 'Object ____'
> variant was created of it with one. We now near-universally regard
> this as a pretty bad idea.
>
> It is my opinion that the profusion of async/await across the
> programming world will be viewed in 15 years like the profusion of OOP
> across the programming world is viewed now: a bad solution to a
> problem ("programming in the large" for OOP, "web scale" for
> async/await) that doesn't actually really exist!
Parallelism/Concurrency is extremely hard to get right, and I've
suffered a lot through it in the HPC-context (OpenMPI, BLAS, etc.).
What really bothers me about Rust is that async is delegated to
external crates.
Rust seems to be the language mostly either used for toy- and
tinker-projects with a short lifetime or high-maintenance projects
where time is plentiful enough that it's warranted to rewrite it more
or less from scratch every 2-3 years.
> Rust is marketed to a... certain kind of person. I don't think I need
> to go into detail. As for their enthusiasm, my view is that they're
> incredibly enthusiastic and evangelistic about it for one main reason:
> it makes them feel smart, and little else does.
Please feel free to elaborate on the kind of person you're talking
about! :)
> We'd all be better off if we focused our efforts on tools to make C
> programming better. I was thinking today about how useful it would be
> to have a way to indicate that a particular variable shouldn't be able
> to impact the running time of a function for cryptography purposes.
> (Generally, the control flow, resource use or running time of
> cryptography-related functions shouldn't depend on secret values, as
> those all have the potential to become side channels). If a compiler
> or compiler plugin recognised such a directive, it could ensure it
> didn't destroy that property. A static analysis tool could check the
> resulting object code and warn you. Other tools could verify it with
> randomised automated testing, etc.
>
> Generally speaking, these things would be better off as unobtrusive
> extensions to C, able to be ignored by a compiler or other tool
> without affecting the meaning of the code to retain compatibility.
> Rust has many good ideas but it's just not trendy to implement those
> ideas in C sadly.
The more such things you implement, the more complex the language
becomes to implement, unless these things are optional. Such
annotations could be useful for linting purposes, and Ada does it well
with their concept of "aspects" that allow you to specify invariants
and other things.
With best regards
Laslo
Received on Sun May 02 2021 - 15:33:13 CEST
This archive was generated by hypermail 2.3.0
: Sun May 02 2021 - 15:36:08 CEST