Hacker News Reader

Comment by FpUser | Hacker News Reader

>"This looks fine, but what happens if you do not get the pin mode right, for any of many possible reasons?"

This is such a contrived and pathetic example. None of it has anything to do with C++ or Rust. It was a decision of whomever wrote pin access libraries. In either of the languages mentioned there is absolutely no problem creating an interface that would return particular pin in "right" state ready to be operated on. Neither of the languages also prohibit fuck up by defining poor access interface.

I think author would do much better off not writing articles like this one.

View on HN

Ok, that was harsh, but I was excited and wanted to get to the meat of the article but then it just ended.

I was thinking, "that's not how I would design a C++ interface". I still don't understand what these Rust types are good for, but I want to know.

I miss how in Ada you can define which values an int can have. Can you do that in Rust?

> I miss how in Ada you can define which values an int can have. Can you do that in Rust?

yes, kind of: https://crates.io/crates/deranged

It'll take another while until const generics on stable are advanced enough to make this properly usable, such that e.g. `RangedU32<3, 10> + RangedU32<5, 6> = RangedU32<8, 16>`.

You're looking for dependent types and while Rust has a limited form, it doesn't have them fully. Idris does, on the other hand.

Yeah there’s a serious lack of discussion of Idris in this thread. Probably the most fun, least used programming language ever.

You can do with a sum type (enum) that is represented by a u32 (repr(u32)), or converts into one. Though I don’t know Ada so can’t speak to how accurately I’m creating the analogy.

In Ada/Pascal/Modula-2/Modula-3/.... it would be something like,

    type
      Subrange = 56..100;
      Colors = (Red, Green, Blue);
      Pixel = array [Colors] of byte;

With the plus that it is a compiler error if an invalid value is assigned, and can be validated at compile time (or it will be a range runtime error otherwise).

But a strongly typed language allows you to check for that error in compile time. As someone who programs embedded I can assure you that you constantly run into that type of error and I could really live without it.

So if people could also do that in C/C++ they are apparently not doing it.

>"So if people could also do that in C/C++ they are apparently not doing it."

Maybe because they do not feel that it is worth doing. It maybe poor decision on their side but it has nothing to do with the implementation language. From a practical standpoint - I programmed enough microcontrollers and frankly initializing pin for particular mode before using it is hardwired into my brain. I do not remember ever having this type of error in my code. In the end if you do not like it you can always roll out your very own "safe" version. Just make sure your "safe" version does not have bugs either.

Exactly, this is a lot for something rarely going wrong,.and if going wrong pretty apparent what's wrong..

Also, that approach would need quite some extension for modern capabilities of pins and conflicting options across multiple registers (pin dir, pin mux and what else driver options).. Also what about those pins you really need to be use in both directions (e.g. one wire protocol, or pins where you have your own mux behind), how to do that? The current approach does not look like supporting switching at runtime.. another complexity level added..

Switching the pin mode should be exactly what Rust is offering over potentially more advanced C++ solutions, because you can take a "raw" pin as an input pin and ensure you don't use it as an output pin for exactly the duration you have it as an input pin.

Same thing in C++, when one actually uses the C++ type system.

Rust can be made as unsafe as the C example, by calling digitalWrite() directly, instead of using the language type system.

C++ has reinterpet_cast<T> or whatever. But in reality the huge majority of C++ code works on safely typechecked code with no escape hatches.

It’s not a contrived example. It’s the canonical embedded hello world, written against two different libraries.

At any rate, the C++/Rust part can be a distraction, because the interesting point here is the technique of encoding program state in the type system.

>"At any rate, the C++/Rust part can be a distraction"

that was exactly my point.

>"interesting point here is the technique of encoding program state in the type system."

It is "interesting" but there is nothing new about it.

Where was it claimed to be "new"? That's a different complaint than you had before... not sure how it's relevant to languages in the example.

I think the author has left out a big piece why Rust enables better interface here: ownership. In C++ could the compile time checks prevent me from creating both an input and output type working on the same pin?

Yes! Hell we did such things in C and a little custom build tool support.

Yes, you would have different set of classes with invariants.

With template metaprogramming those invariants can be done at compile time.

It is a matter of type system design, the whole point of type-level programming.

In C++ (or another language of your choice without strict linear types) how would you design a pin library to prevent someone from using a pin as both input and output enforced at compile time?

As long as it is static, that is, it doesn't change during execution; you would do it by declaring the pin as either or using the type system.

> None of it has anything to do with C++ or Rust. It was a decision of whomever wrote pin access libraries.

Which is why the article title is ‶What is Type-level programming?″ and not ‶C++ suckz Rust r0x lol″

... but then still somehow gets into this by showing a C++ example which is bad and then continuing that in Rust you could do this-and-that. Which completely obfuscates what's actually going on.

> by showing a C++ example which is bad

What the author shows is how the Arduino stdlib does it in an unsafe way; that it is C++ is a coincidence (and one could easily argue that the C++ Arduino stdlib is barely C-with-classes and far away from what could be done in C++).

Exactly. In other words, the post could have just continued with C++ and shown a better way to do it in the same language.

And maybe, just maybe, the guys knows Rust better than C++ and just want to take an example from their daily work rather than take every single precaution not to hurt the fragile sensibilities of HN reader unable to see the point if their life depended on it?

Then they should have presented the case that way, instead of showing C like code and assuming there is no way to do that in C++.

> Then they should have presented the case that way

That's exactly what they did.

> assuming there is no way to do that in C++

You are extrapolating things that are nowhere to be found in the article.

C like code was presented as C++, while Rust code using an existing library was presented as something not available in C++ (type level programming).

> C like code was presented as C++

Blame Arduino for their stdlib.

> was presented as something not available in C++

You are putting things in the author's mouth, they never said that; only that it was not available in Arduino's stdlib.

What about blame the author for their lack of C++ skills while selling Rust, and pretending otherwise?

Once again, you're reading a language war where there is none.

Read the bloody article, it's all about the type system, not the language.

Do you really expect the author to rewrite the Arduino stdlib for the sake of pjmlp's sensibility?

I expect the author to actually learn C++ to start with.

I survived the Usenet flamewars, there is no sensibility to hurt.

Looking at the fellow comments the crowd shares a similar opinion on the article.

Some food for thought.

> > Then they should have presented the case that way

> That's exactly what they did.

You have read the article, right? It starts with showing how it looks like in C++ and then goes on with the revelation "In Rust on the other hand ...". Literally. This strongly suggests that what they are getting at is a language feature that sets Rust apart from C++.

Reply on news.ycombinator.com