211–220 of 289 posts
Earlier quoted context omitted.
Ah I was writing a reply to someone else as you commented this :) We've got experimental projects with some ports of our firmware to it already, but there are lots of showstoppers that we've run into (some of which are ESP-IDF's fault more-so than esp-rs directly). In the medium-to-long-term, I'm really hopeful we can move to it. Not quite there yet for our production use cases though unfortunately.
If the lack of some services allows it (maybe not given the chip, but it was enough for me) I recommend using esp-hal+esp-wifi rather than esp-idf-hal, it is a pure rust 'rewrite' and it's been a great experience compared to esp-idf(c++). Default is bare-metal but embassy resolves most of the need of an rtos.
Earlier quoted context omitted.
It didn’t have at 1.1, but it does now: https://news.ycombinator.com/item?id=35133670
You can do that with go too, there are libraries out there. But it's all a joke compared to real support in the language.
Earlier quoted context omitted.
Actually all three of Rust's user defined types (the sum type enum, the product type struct, and union†) are fully fledged types which can implement traits and have functions of their own (including functions taking a self parameter, thus methods) C++ unions can actually have methods, although this isn't used very much. However C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods…
> C++ enums can't have methods, even C++ 11 scoped enums ("enum classes") can't have methods, I have no idea why that restriction seemed like a good idea It is possible that Oracle holding the patent[1] to methods on enums is the blocker, rather than any technical restriction. [1]: https://patents.google.com/patent/US7263687
Earlier quoted context omitted.
C++ has std::variant though?
So, so many ways in which this is defective compared to actual sum types, some of them were already listed, but to me the most crucial, even if mostly about theory rather than practice, is valueless_by_exception. The choice to provide exceptions everywhere as a error handling means C++ is obliged to admit that your std::variant may not have a value at all. Which blows up all of your type safety. In Rust I can say tha…
You also don't have to handle the exception, in which case you won't access the variant again anyway. Or it gets handled where the variant is teared down. It's very unlikely that it gets handled where the variant is constructed or assigned to, making it a non-issue.
Earlier quoted context omitted.
I am absolutely not a lawyer, but wouldn’t it fall into the “trivial” category, so even if patented, it couldn’t be enforced?
Problem is, unless it has been tried in court, you can't be certain. And if you're building something, you might not want to spend time in court having to fight it in the first place. So even if it's 50/50 enforceable/not enforceable, do you really want to spend the time testing if it is? Patents really have a chilling effect, even if a particular one might not be enforceable.
Having said that this is the first time I ever heard of methods on enums being patented, what a ridiculous patent. It's a good thing then that C++ doesn't have methods, it has "member functions" :).
Also C++ allows user defined operators on enums, which feels somewhat adjacent.
Rust will only be a real competitor once it’s generics can hold a candle to C++ templates.
Thanks but no, replacing a bunch of code as strings and then relying on some code _not_ compiling should be left in 20th century for good.
Earlier quoted context omitted.
That sounds bizarre. So this means that parents are potentially holding back programming language innovation? I hope I don’t have to consult with a lawyer every time I invent a new variation on the for loop. (I anticipate that someone will then tell me that there already is a patent for that…)
Why would it be bizarre? It's not exactly a fringe belief that patents in all software are holding back innovation. I don't think programmers often consult 20 year old "inventions", so it seems pretty obvious on its face that the supposed benefit of patents, that something is _only_ locked up for 20 years, is quite pointless in software. Anyway, for loops are safe, unless the for loop is over the elements of a linked…
Earlier quoted context omitted.
A union in C++ is the same thing as a struct, except all of its fields live at the same offset. So you can define any method you want on it, including special stuff like constructors and destructors. No base classes are allowed, though.
A method on a union is much less useful when you can't match on the tag though. I suppose you could store tag inside the union. Is that common? I've always imagined C/C++ tagged unions would store tag outside the union.
So yeah, it's possible to store the tag in the common initial sequence of all the union members.
This is quite niche and rarely used. Most of the time it makes more sense to have the tag outside. Sometimes the tag in the common initial sequence allows the whole data structure to pack better than with a tag outside of the union.
The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…
Can someone elaborate on what sum types are and an example in Rust?
A "Rust enum" is a sum type.
Also, I talked about ASTs being a good example use case for a sum type. Here's a "real" version of an AST for a regular expression in all its complex glory: https://github.com/rust-lang/regex/blob/a9b2e02352db92ce1f6e...
You can see that it starts out as a sum type at the top level. And inside each variant is all sorts of product types and other sum types.
But do note in practice that sum types aren't limited to specialized things like ASTs. In practice, they come up everywhere. For example, here's a small little state machine used to implement a simple "unescape" routine. e.g., converting the string 'a\xFF\t' to the byte sequence 0x61 0xFF 0x09: https://github.com/BurntSushi/ripgrep/blob/44fb9fce2c1ee1a86...