Do you have any articles or any info on why they decided to stop using Rust? I remember seeing things about them using Rust but never saw anything about them not using it and I'm curious.
They made a few offhand comments on Reddit, but that's it.
They decided that having a unified tech stack for the games themselves was worth more than Rust's advantages. Basically, they decided to re-build Witchbrook on top of Wargroove's engine.
That being said, I guess I should have put an asterisk on there; they aren't using Rust in game anymore, but they are still (apparently, last we heard) using Rust for server-side components. Wargroove's servers are implemented in Rust.
It's really sad because this is the first time I heard about this campaign. Had I known earlier I would have pledged sooner and spread the word around.
I'm curious what parts of Rust you think are safer than Python.
Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
Immutability by default, exhaustiveness checks (make sure that you match over all variants of an enum or cover all valid values in an integer), return flow validation (did you forget a return somewhere? Is it the right type?), and, as you mentioned, type checking being mandatory, all libraries define their accepted types. Not only that, being types "cheap", it is customary to wrap base types in explicit types that won't be compiled:
type Point(u32);
fn foo(p: Point) {...}
foo(0u32);
^^^^ expected Point, found u32
When you work with the type system it checks a lot more than you check in Python. In Python you pass around untyped tuples and maps because defining classes won't gain you anything (and is surprisingly cumbersome and unpythonic), whereas in an ML-family language like Rust you use lightweight, fine-grained types to check that every function call is correct and you can refactor fearlessly.
(I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker)
> I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker
OTOH, Rust arguably has a better story for tooling (build system, dependency management, etc.), a more full-featured standard library, and better concurrency support. Depending on your priorities, some or all of these might be worth having to learn the borrow checker.
Well, O'Caml and Haskell predates Rust by decades. I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Obviously you can simulate them, but it's much easier to get wrong or "cheat" (say having a bunch of fields, only some of which are valid depending on a tag).
I do, but I wasn't aware that Rust was considered in the ML family (ML as Meta Language, like SML/NJ). I'm somewhat skeptical of that.
What I see from Rust is a lot of the really great things from functional languages (esp. strong typing) and beyond, but applying them to a language aiming as low as C. That's certainly interesting.
the type-checking catches lots of memory errors (irrelevant in a GC language like Python, but wouldn't be caught by the compiler in C or C++), but it also catches data races when writing concurrent code, which is definitely something that could happen in Python.
> The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
It's this but designs in statically typed languages with more expressive type systems tend to push a lot of the logic into the type system so you can't use APIs incorrectly. This isn't exclusive to Rust but I do have a few examples:
The Glium OpenGL wrapper puts a lot of effort into moving errors to compile time. The overview[1] explains a bunch of them.
More abstractly, one of the more unique features of Rust's type system (linear types) is the ability to be sure a reference is destroyed. This makes Rust particularly good at describing state machines that are compile-time checked. Using standard OOP terms, each state is a class and its methods are the valid transitions. You can't take an invalid transition because the method is missing. You can do this in any language, though it tends to be only done in statically typed languages and it's awkward in Python. What makes Rust unique is that calling the method will consume the instance so you can't accidentally make a transition twice. Trying to call the method again is a compile error. A concrete example of this is state_machine_future[3], which generates an asynchronous state machine using macros.
In a slightly different use of the type system, the Rocket framework has a concept called Request Guards that allow you to map from something in the Request to a parameter in the request handler function. The overview[4] has a simple example on the "Dynamic Params" tab that maps url pieces to a string and an int. This mapping, however, is extensible and you can map to anything. If your handler needs an AdminUser, you can have the request guard pull the user id off the request, connect to the db, retrieve the user, verify the user as an admin, and only enter the handler if all that is successful. This means you can move all the logic and error handling around this into a single place that can be reused just by putting an AdminUser parameter on a handler. I've seen this done with middleware in other frameworks but in Rocket it's on-demand per-handler. As a result, the handlers only have to implement the happy path, which keeps them more compact than I've seen in dynamic language frameworks.
So the general idea is to use the type system to help you use stuff right. As with anything, it's possible to overdo it and get crazy boilerplate heavy code where you have to convert/cast all over the place and unanticipated use cases can't be done but it tends to be helpful, particularly with autocomplete.
Considering how they phrased it and the fact that no phone has the FSF's RYF certification I would tend to think it's because it's currently impossible.
That they took the time to add a note about RYF certification and that they will continue to keep the FSF up to date on this shows that they do care about this. I honestly don't think there's any more you could ask of them.
> it's currently impossible. […] I honestly don't think there's any more you could ask of them.
I don’t dispute that. I have no ill will towards them. I just, you know, won’t actually be buying the phone until one exists which is RYF-certified. I just felt it important that someone pointed this out – while surely their effort towards RYF compliance counts for much, it won’t get me all the way towards actually buying it. I’ll wish them all the luck in actually achieving it, but I (at least) won’t be buying anything until they actually get there.
I suppose I can understand this reasoning a bit, but it seems a little counter intuitive to me. There is literally no alternative. And without efforts like this it's unlikely there would ever be something that is RYF compliant. Accomplishing something like RYF certification requires work, money, and someone willing to try to accomplish it. There is someone that is willing to invest work to at least attempt to accomplish it, but they need money. Why not support them in their quest for this?
Suppose that I’m a vegetarian, but I really like sausage (maybe I acquired the taste before becoming vegetarian), but there are, for some reason, no makers of vegetarian sausages. Should I then accept whatever sausage is available which has the least amount of meat in it? Of course not; I’ll simply go without sausage.
Even if a sausage maker came along and tried to attract the vegetarian buyers with a new kind of sausage which had no meat in it, just a little bit of gelatin in it. They say they can’t currently make vegetarian sausage without any gelatin in it, but they’re working on it. Should I “support” them and buy the sausage with gelatin in it anyway? Of course not; I’m a vegetarian; gelatin means it’s off the table.
(I’m not necessarily really a vegetarian, of course; it’s just an analogy.)
I don't think that analogy is a fair comparison to make because it doesn't fairly portray that Purism doesn't have a choice in this. It is the upstream manufacturers who control this area, and they will have no reason at all to make something which is RYF approved unless someone big enough is pushing for it.
So to make this comparison more apt, it's more like a sausage maker who is focused on making vegetarian sausage. Now, it just so happens that they'd also love to make these sausages vegan sausages, but the suppliers of the contents of the sausage just don't make a "meat" which is vegan because literally no one with any power has asked for it before. If no one buys their sausages there is literally no chance of a vegan sausage being produced because there is just no reason for it.
Even that isn't really an apt comparison because it doesn't correctly portray the ubiquity of cell phones. I guess instead of a sausage maker it would be something more like "a producer of food", where there is literally no vegan food anywhere. So what I don't understand in all this is why someone who wants an RYF certified cell phone would choose not to support the one group even attempting such a thing. You don't even need to eat the sausage or use the phone in this case either, they just need the support.
This analogy is not good, because for a vegetarian there are other easy-obtainable things to eat. On the other side, in the case of handheld portals into the digital world, we do not have easy-obtainable alternatives.
Besides this weakness, the analogy relies on fanatism. One can easily become nearly vegan and have virtually all of the benefits while not needing to be totalitarian nor fanatic.
(I’ll answer about my thoughts and opinions are instead of what I am actually using.) I would not be adverse to using a “feature phone” – i.e. a non-updateable non-smartphone. It’s hard coded; no one can affect the software in it, so it would be OK if I can’t either. Of course a free (RYF-certified) phone would have much better features (including inspectable privacy guarantees), which is why I’m considering such a thing.
I can’t know that, which is why I wrote “Of course a free (RYF-certified) phone would have much better features (including inspectable privacy guarantees), which is why I’m considering such a thing.”
> Write a code of conduct, make sure everyone is respected, and make that the end of it.
But that's exactly what all of your examples are. In each situation the decision and action was to make things as neutral and inclusive as possible. That there are people in any given community which want things to be taken in a different direction (any direction, social or otherwise) seems like a pretty natural thing.
Good luck finding these types of patches in the Linux kernel dev community. There is a very specific type of culture that spawns this kind of timewasting.
You either waste a small amount of time up-front defining what's acceptable and how people should deal with each other, or you waste what's likely much more time the first time people have a major problem that could have been avoided with some sane defaults. And then you're faced with the choice to spend more time setting some sane default expectations, or you put it off until the next problem.
The real difference in why the kernel can work with that and other projects can't is the D in BDFL. What Linus says goes, so there's an ultimate arbiter (for better or worse) that can settle these problems, and set the tone. The LKML doesn't need a code of conduct because Linus is the example of conduct, which in this case is "words don't matter put up or shut up". That'f fine, as long as you're aware and okay with marginalizing the people that don't deal well with that, which can, and has happened on the LKML. But that's a choice for Linus. Rust doesn't have a BDFL, so there's no ultimate authority to define what's right or wrong for Rust and the community around it (as much as a BDFL can for something at large as a language). In that situation, a code of conduct that exists to set some sane defaults can be useful.
I don't exactly see the Linux kernel dev community as being inclusive, so that's not really an apt comparison. Nor is it a language-based community. It's a very specific set of people who are expected to follow the rules and do things in a particular manner; and for them that's okay.
For a programming language community though I don't think that's the kind of approach to take. Sure, it could work and you may get some very talented people to help, but it's also arbitrarily limiting the kinds of people who can contribute and feel welcome based on the thickness of their skin, not on their technical ability. You may consider this timewasting, but I think it's more like a clever and nuanced form or marketing. Not only do you get the benefits of including more potentially skilled people into your community, you encourage them to actually get involved with the language. It seems like a worthwhile investment to me.
Dude what you listed are trivialities and if you consider the throughput of Rust project the time taken must surely be negligible. I wonder what Theo or Brad think about timewasting on that other paragon of a project you mentioned.
But it's true that there's nothing inherently "bad" about the code. It's just not conforming to the standard style. It seems pretty reasonable to want that to sound less menacing than "bad code", which would hint very strongly that one has something semantically incorrect.
