On top of that Rust might be the ugliest modern language.
* Why does C# require a break; under switch?
* What about the "Most Vexing Parse"?
* Why does Zig change capitalization of @import and @TypeOf?
Rust is an extremely "guessable" language. It's highly likely that experimenting with syntax will succeed in Rust, which is a syntax feature that I have seen nowhere else.
TypeOf returns a type. Corresponding to how type names are uppercase.
These feature enablement blocks drive me crazy. You could go from codebase to codebase and it's almost like you are working in a different language depending on how many of these are enabled or not. I've been trying rust on and off since it's release, and I still have yet to feel like I have a grasp on some "core" subset of the language I can fall back on to solve most of my problems. I always have to scour documentation for the hot new thing to turn on or do, and this isn't to scorn innovation and change, but it does get exhausting at some point.
(Please release a spec)
(Though I do agree that Rust definitely moves fast, which is sort of understandable as a relatively newish language)
I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain.
I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.
C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code.
OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases:
var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...}
let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ];
Since it's a macro there's no impact on runtime performance, but on the other hand it's more work to debug it. Learning declarative macros in Rust is much nicer and safer than learning C macros, but nowhere near as powerful as Rust's horribly unsafe proc macros.
const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...];
for (str1, num, str2) in &foos {
// ...
}
Having to name the fields is only part of the pain. You also have to redundantly repeat the struct name. I don't see any fundamental reason why something like this shouldn't be valid:
let foo: [MyStruct; _] = [{a: "foo", b: 1, c: "amp"}, {a: "bar", b: 1, c: "fff"}, {a: "amp", b: 1, c: "aaa"} ];
fn make_struct(x: (&str, u8, &str)) -> MyStruct {
MyStruct { a: x.0, b: x.1, c: x.2 }
}
let foo = [("foo", 1, "amp"), ("bar", 1, "fff"), ("amp", 1, "aaa")]
.map(make_struct);
Rust is more on the verbose/explicit side and I agree that can sometimes be annoying, but as autocompletion exists I can live with it.
There's no reason you couldn't match on struct fields positionally as well. It would actually be quite convenient for cases like struct Point { x: f64, y: f64 }.
Side note: matching f64 by value isn't a good idea either way, is deprecated and will become an error in the future.
I wasn't thinking about matching floats by value, just destructuring a Point to obtain the coordinates as separate variables. Come to think of it though, as Rust already allows
let Point{x, y} = pl
My overall point here isn't that Rust has made bad design decisions. It's just that the end result of a bunch of sensible design decisions is that initialising arrays of structs is clunky. It might well be that this problem isn't fixable without creating other, worse, problems. However, I think it's a problem that's emblematic of what the OP was talking about. We have here a language that's so concerned with solving difficult problems in clever ways that it's ended up backed into a corner when it comes to something as ridiculously simple as initialising an array of structs.
Yes, though at least the language gives you tools to make it more convenient. In the previous examples that would be constructors, and macros can help too (`println`, `vec` etc. exist for that reason).
I myself like to create tiny macros to shorten things like `UnicodeSegmentation::graphemes(s, true).count()` when I have to properly handle unicode. Sure I would prefer to have it be shorter from the start, though that wouldn't make it as obvious how expensive the operation is compared to just getting the size in bytes.
I'm really new at Rust, but that was my takeaway, e.g. `String` has `String::new()`
String::new() just makes you an empty String, which, since an empty String doesn't own any storage and doesn't contain anything, is very cheap (and indeed constant evaluable), likewise Vec::new() makes an empty Vec.
What your parent commenter wants is for Rust to make the appropriate MyStruct, but without them needing to say MyStruct each time, which would have worked in e.g. C or Go.
By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.
If you end up with a long::run::of::module::names, I find it all just blurs into one.
If I was to think about it: comparing rust to zig, zig benefits a lot from error and optional types having their own syntax rather than being treated like any other type. For example a return type of:
Result<Option<usize>, Error>>
!?usize
Disclaimer: I'm a zig fan and contribute monetarily so please weight anything I say on zig vs rust with that in mind. (I do write rust at work though)
fn someFunction(a: usize) !usize {
if (a < 10) return error.LessThanTen;
const b = try anotherFunction(a);
return 2 * b;
}
fn anotherFunction(x: usize) !usize {
if (x < 20) return error.LessThanTwenty;
return x * 3;
}
error {
LessThanTen,
LessThanTwenty
}
Note the "(mostly) equivalently" was a reference to the fact that Zig errors can't (currently) contain any other information, whereas an error in rust can carry other information.
Also note that the compiler can't infer the error type in all case, for example in the case of a recursive function. In that case you do need to explicitly write out the error set.
1. Doesn't that risk introducing accidental breaking changes by adding a new error to the set in the implementation, since the set of errors is inferred from the implementation? Having a compile error in this case in Rust is often the last barrier standing between me and an accidental major semver bump (since callers have to exhaustively match on the error conditions) 2. Can you have data in the variants of the error enumeration?
Do you have an illustrative example? (I'm not implying it's not possible, just trying to think of a good example so I can give a good answer)
> since callers have to exhaustively match on the error conditions
If it's exhaustiveness that you're referring to, zig will make you handle all the possible errors (you can still do a catch all type thing when handling errors, which has the potential to "hide" an error that you otherwise wanted to handle explicitly).
> Can you have data in the variants of the error enumeration
No, they compile to just integers. Essentially it compiles to the same as C function that returns an `int` representing the error (with your actual return type passed in as a pointer, say).
Another limitation of zig error values is I think they're globally scoped, so you potentially could have two libraries have clashing error names that you then can't differentiate (I don't know if there are any plans to try and resolve that).
I will say that this automatic error set inference gives writing zig code this lovely "flow", where I do some error checks at the top of the function and early return some errors (which I just invent the names of there and then) and then move onto the happy path of the function, happy in the knowledge that the error handling is already "correct" (in that if the error isn't handled it'll (typically) bubble all the way up to main and exit the program). Any refinement on how a specific error is handled, I can go back to an appropriate place in the call stack and handle it. I always feel like it's helping me write correct code.
Illustrative, I don't know, but I'll try to give more context.
When writing a library, it is important that public items (like functions and enum) don't change between minor versions so that client code doesn't need to update their calls to the library.
Sometimes when refactoring code you end up modifying how a library function is implemented. Maybe it will now depend on some file being present on the system, while previously it wouldn't, meaning that the absence of that file adds a new error variant to this function.
In today's Rust, since the Error type of a Result is an explicit part of a function's signature, such a change is very noisy to the library's maintainer: it entails either modifying the signature of the public function to return a different error type, or modifying the Error type itself, which is also public.
When this happens, the change needs to be reconsidered: either you can defer it to later, provide an additional function with that new implementation and error variant, try to make it work with the error types you already have, or decide in that it actually warrants a major version bump, in conscience.
By contrast, if the set of errors of a function is inferred rather than part of its explicit signature, it means that modifying the implementation you can add a new variant without even realising it (for instance, by mixing the variant name with a variant returned by a sibling function that you thought was already used by this function) and break semver in a much more silent way.
I guess it also makes life harder for tooling, since it has to parse the implementation of a function (and all its subfunctions) to rebuild the set of errors, as opposed to simply parse the signature of the top-level function.
> Essentially it compiles to the same as C function that returns an `int` representing the error
That feels very limiting, I often use error types to e.g., attach data about the error. Is there a more general mechanism for sum types for when this shorthand doesn't apply?
fn someFunction(a: usize) MyError!usize {
if (a < 10) return error.LessThanTen;
const b = try anotherFunction(a);
return 2 * b;
}
fn anotherFunction(x: usize) MyError!usize {
if (x < 20) return error.LessThanTwenty;
return x * 3;
}
const MyError = error {
LessThanTen,
LessThanTwenty
}
I agree it's limiting. It obviously is going to depend on your application, but I have largely done without annotating errors with extra information (that maybe speaks more to the seriousness of my zig projects than to that approach to error handling as being sufficient!).
One pattern I have used (in e.g. a parser) is additionally passing in a pointer to a sum type:
fn parse(allocator: *mem.Allocator, tokens: Tokens, parse_error: *ParseError) !AST
For what it's worth, if you expect this might happen, you should give the enum the [[non_exhaustive]] attribute. This attribute says I, the implementer, know how many of these there are, and in my code I can exhaustively enumerate them e.g. in a pattern match, however, you the 3rd party programmer using this crate, must assume you can't know how many there are, and therefore must write a default match to handle others, even if there seem to be no others when you write it.
Once you do this, you don't cause a compatibility break by adding a new item.
Also this is an no-win situation. C++, Ruby, Perl, and others have used `::` as module-scoping syntax for decades. If Rust does something novel, it's penalized for being unfamiliar. If Rust uses syntax for which there's ample prior art, it's apparently line noise. If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain.
There's literally no way to win.
This is especially true when there's similarly named items from different paths. Best example is `Result`/`Error` types. eg: std::io::Result vs normal default Result vs other crate's Result type. Another example would be math types like Vec2 between game engine and egui. String in mlua vs std rust etc..
Usually you can get around this by importing it with a different name like `use mlua::String as LuaString`. but it is still something that you need to actively do.
> If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain
Interestingly, from the zig documentation:
Zig source files are implicitly structs, with a name equal to the file's basename with the extension truncated. @import returns the struct type corresponding to the file.
Yes there is? Follow what C#, F#, Java, TypeScript, etc. do
* Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result.
* Lifetimes have the form 'a, and that single quote is likely to bother a lot of people (I know it bothers me).
* Unqualified name lookup in Rust is a bit weaker than other languages, which makes the scope operator (::) more common.
* Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.
* Similarly, macros require an explicit ! in the name to invoke. Given that println! (and formatting in general) is a macro and not a function, this means you get a lot of extra uses of ! that's unexpected for C family code.
* Again, the try operator (also decently common) is another random special character.
* Attributes also use #[] syntax, or sometimes #![]. While C++11 did use [[]] to designate its attributes, it's also something that always felt a bit ugly to me personally (I find the @Decorator() pattern from Java or Python to be a visually cleaner way to do attributes).
In short, Rust generally has a higher density of special characters than other C family languages, and I think that contributes to a sense of ugliness.
There is a very good reason for this. Behold, the Bastion of the Turbofish.
https://github.com/rust-lang/rust/blob/master/tests/ui/parse...
int foo(int a, float b);
fn foo(a: i32, b: f32) -> i32;
Or look at an array declaration:
int arr[5];
This kind of argument of course goes all the way back to AT&T vs Intel assembly syntax and I am firmly on Intel's side.
Pascal, Modula, and Ada are all type on the right languages and were also very influential in the historical development of programming languages. I happen to prefer types on the right for complex declarations. Note that Pascal and Modula were designed by Niklaus Wirth after he created Algol W; it seems he preferred types on the right.
The absence of default args is a deliberate choice, notice that Rust does have default type arguments in polymorphism, the absence of defaults for function parameters -- which would be technically easy to implement -- reflects a belief which I've come to agree with that overloading is a bad idea, and defaults most often in practice mean you're overloading.
For example, C++ std::ranges::binary_search uses defaults to present what are in effect at least two distinct features, as a single function, suiting C++ sensibilities, whereas Rust reflect almost the same capabilities as three functions []::binary_search []::binary_search_by and []::binary_search_by_key
For a very simple binary search, things seem pretty similar. In Rust we have a single parameter, for our searched-for element, and in C++ we can stop after that parameter, leaving the comparison function and projection as default for similar effect.
However for binary_search_by the C++ is contorted by this API shape. Instead of a callable to decide whether our search found what it was looking for, and if not where it is relative to the searched-for element, the C++ is obliged to carry that element (because it was an earlier parameter) even if it's unused - and then a comparison function which takes the element, and only then optionally a projection which you may or may not use.
And for binary_search_by_key the C++ is even more awkward, we have a good reason to use a value here, but we're obliged to specify the comparison function even though we only want to write a callable to make suitable keys (ie a projection), because of the order of the parameters.
These would be better served, as in Rust, by three distinct functions, with only the appropriate parameters for each function - even if you choose to actually implement the simplest in terms of the others, because of the documentation and the API shape afforded if you think about it as three things not one with defaults carefully tailored to allow all three uses.
Variadics is a genuinely useful feature, but to do it properly is very difficult, C++ 98 doesn't have anything better than Rust [C compatibility, with no real type checking], C++ 11 does have the outline of what you'd actually want, and C++ 17 has much closer to what I'd want to see in Rust some day.
Much of what you're thinking of in "weak generics" is probably deliberate constraints to only allow coherent things, in C++ they don't care if you want to make a Foo<NaN> even though that's nonsense, IFNDR gives them the ultimate out, your program has no defined meaning, so too bad.
There are some obvious things Rust wants to have but doesn't yet in this space, including broader const Generics (e.g. my OnewayEqual ought to be Oneway<Ordering::Equal>) but it's not going to pursue the irrational C++ exuberance because it's so quickly unsound. C++ doesn't care about that while Rust does.
I don’t really care for your examples of defaults being abused in C++, because all of rust’s workarounds like builder pattern and the default trait have the same potential to be misused while also impeding performance. They also suck for ergonomics, see bevy and polars. Rust already has a huge function colouring problem with async and mut and the lack of defaults only makes it worse.
Similarly for generics. Templates are simply better. Don’t use the power if you’re scared if it, that’s the great thing about freedom, you won’t be forced to. C++ can always do something the Rust way, nullifying everything you’ve said, but the other way around is not true. Rust sacrifices the complex case to make the simple case a little simpler and just leans on macros to do everything else. “Rust just allows coherent things” is a typical example of the bullshit rust programmers spew when they don’t have an actual response but want to say something anyways because it’s completely wrong. Plenty of useful template functionality is impossible to replicate in rust. For example:
Rust also has const generics (but they are still a bit shabby in places last time I used them).
I for one never liked the constexpr semantic and syntax. Always felt like a... Little pebble in my shoe. Didn't quite annoy me enough not to use it since it was useful, but it was never a comfortable experience.
It is one of my favourite languages, but I also acknowledge that C compatibility is a big pain point for security.
No access to performant generic data structures is a major reason why truly performance oriented programs rather choose C++ over C.