Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Makes it look easier to design FPGAs than to attempt to write programs in Rust. Or just write the program in assembler AND write your own macro assembler.

Reminds me of the C++ book that used the acronym RAII (corrected) several times per page as if it was a magic spell that warded all evil and finally defined what RAII was around page 250.

View on HN

This post is definitely inside baseball, so it’s incredibly esoteric to those that understand it, but it’s worth mentioning: Rust is accomplishing things at compile-time that most languages with similar features have to do at runtime with runtimes (in this case, all of the higher-kindedness that GAT represents without extensive heap allocation and runtime-level bookkeeping under the hood).

The LendingIterator is conceptually providing mutable access to a sub-slice of a larger struct, and doing it without heap allocation (NB besides the initial box storage shown in the example). Even in the case of dyn, which is a feat. Also it is safely returning pointers for the above-referenced mutable access across function calls; it’s impressive the way good perl golf is impressive, because you appreciate what is happening underneath.

Putting all of that aside, what you said about FPGAs is probably valid.

Also, you can totally write (with a bit of unsafe) a LendingIterator with runtime checks instead of this compile time check, with the cost of 1 byte per item (and of course the possibility of a runtime panic). So this is really only relevant for library authors and those who want to wring the last bit of performance out of their program.

I still find Rust a disappointment. I thought Cyclone was a good idea but it hurts so much to watch people to struggle doing what should be very simple things in Rust. People are re-writing the Software Tools by Kernighan and Plauger. C took over the world because books like that made it look easy.

I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting.

That is, we have systems of memory allocation and resource management that almost work in C++, Java and other languages. Rustifarians would claim they've removed the almost (if the program compiles) but there are programs that will never get written, features that will be added, bugs that will never get fixed because of the extra complexity. So the "almost" doesn't really go away.

I like the idea of a flexible compiler that supports a lot of metaprogramming, has a theorem prover to prove that application-specific constraints hold, and writes code that meshes with a bespoke runtime. (e.g. imagine a C++ designed to support what people really do with C++) Unfortunately it kills the whole idea of importing libraries, so it is still an "almost".

The C implementation for Arduino drives me absolutely up the wall. AVR8 has as many registers as the old IBM 360 (a lot!), the programs I write can run entirely with statically allocated memory, I almost want to cry writing AVR8 or ARM assembler and still having to hook into C libraries with calling conventions and futzing around with the stack that are providing features the application doesn't really need... And there is that Rube Goldberg CMAKE build system that could have only been inspired by autotools.

That's how "almost" is the enemy of the good.

> I like the idea of being able to guarantee properties of the compiled code but the properties that Rust is guaranteeing aren't really that exciting.

These properties are the baseline you're going to need if you want to guarantee harder ones. The whole field of high-assurance software is pretty much in agreement about this, memory safety is a key enabler of proper semantics more generally.

Except that a particular program could have its own answers to the memory problem. Some problems that are intractable in general are straightfoward in specific cases.

That's kinda what the selling point of C++ is supposed to be.

What I dislike is how some in the community hijacked the idea that unsafe code blocks are for possible memory corruption code, as introduced in Algol languages since the late 1950's, and now everything that consider might be error prone is an "unsafe" API.

Having used both VHDL and Rust. Rust is waaaaaaaaaaaaaaaay easier. Like pre-elision lifetimes Rust is still easier than VHDL.

This is a problem for lib authors and it's good to be aware as soon as possible.

That said GAT weren't designed to tackle this problem, but async fn in traits.

Also according to https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-tra...

The faults could be removed in stages, so it's not like GAT can't be improved.

GAT are also supposed to enable an encoding of HKT. Which means that support for advanced type system features as seen in Haskell, Scala etc. will become feasible once GAT stabilize.

> RAAI

RAII?

https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

Reply on news.ycombinator.com