31–40 of 96 posts
Correct me if I'm wrong, but I see nothing in the Rust example that couldn't just as well be implemented in C++. A comparison to C would have made more sense.
It dumps on the Arduino stdlib, not C++ itself. The example is probably in Rust simply because that's what the author is using.
https://www.youtube.com/watch?v=2Bi8SiVwyQA
Basically how to use the C++ type system to create state machines for embedded systems.
Including examples for Arduino.
>"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 operat…
Which is why the article title is ‶What is Type-level programming?″ and not ‶C++ suckz Rust r0x lol″
Correct me if I'm wrong, but I see nothing in the Rust example that couldn't just as well be implemented in C++. A comparison to C would have made more sense.
I program MCUs in C++ as a hobby, and I'm not sure how I would do this in C++. Idiomatically I believe you could use move semantics to invalidate a "handle" to a pin when switching its type, but that wouldn't fail at compile-time. With ownership you really have something in your execution that "is" the pin by virtue of only one value of that pin existing at a time. See also https://docs.google.com/document/d/e/2PACX-…
Ownership is a different beast, and definitely more manual/error prone in other languages; but you definitely pay a price for that.
>"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 operat…
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?
>"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 operat…
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 ?
Earlier quoted context omitted.
I program MCUs in C++ as a hobby, and I'm not sure how I would do this in C++. Idiomatically I believe you could use move semantics to invalidate a "handle" to a pin when switching its type, but that wouldn't fail at compile-time. With ownership you really have something in your execution that "is" the pin by virtue of only one value of that pin existing at a time. See also https://docs.google.com/document/d/e/2PACX-…
As long as your final handle has the correct type, I see nothing mentioned in the article than couldn't be done just as easy in C++. Ownership is a different beast, and definitely more manual/error prone in other languages; but you definitely pay a price for that.
Come on. Ensuring that is the whole game!
"In C++, if I do: import numpy as np np.linspace(2.0, 3.0, num=5) nothing happens. In fact, it's a compile error. But if I do the same in Python, it works and works very well! Python > C++" Sorry for the troll post, but this really is ridiculous.
The `pins.d13.into_input();` part just returns an object/reference/... of a type that only has input-specific methods, while using `.into_output()` would do the same with only output-specific methods, correct? That's nice, but why couldn't you do the same thing in C++?
With a dependent type you could do `pins.d13.into(INPUT)` and get the input-specific type, but that seems to not be something Rust could do?