4 ms·

The elementary Rust syntax looks nicer. But once you start to do more intricate thing in Rust, then the syntax starts to look really ugly. I think this is whe

The elementary Rust syntax looks nicer. But once you start to do more intricate thing in Rust, then the syntax starts to look really ugly. I think this is where Rust falls apart. In things like C, more features requires writing more C code. In Rust, more features requires learning more syntax features.

thomastjeffery 6y ago
How so? My opinion is generally the opposite, that simple decisions like putting type annotations after names, etc. make it so each unavoidable complexity in syntax has its own home, instead of piling together like C++/Java/etc.
prirun 6y ago
This is one of the things I disliked about Nim. I spent a few weeks with it hoping I'd love it as much as Python. But there are quirks in the type system that seem rather baffling to me, and frankly, ugly. Like having to type integer constants with 23'i32 because 23 is an int and int is not compatible with int32 (nor is it compatible with in64!) There are typed integer constants in many stdlib sources too. In the tutorial, the language looks quite nice, comparable to Python. But in production level code, there are {.pragmas.} in a lot of places and they are not just advice for the compiler that can be ignored: they are important keywords that don't pollute the identifier space. Another beef I had is that slice ranges and for loops are closed intervals by default. This is contrary to both Python and C, and while there is a syntax a..<b to be open on the right, it seems like a bad decision to be different from C and Python by default. It reminded me of Julia arrays starting at 1 by default. I guess I can see that if your audience is Fortran programmers, but arrays haven't started at 1 in a new language for a long time afaik. I wish Nim had a goal of being a typed, compiled Python. But I don't think that ever was a main goal and now it's sort of too late because the language has a very wide scope (my opinion) and has compatibility concerns with all of its previous design choices.

thomastjeffery 6y ago

How so? My opinion is generally the opposite, that simple decisions like putting type annotations after names, etc. make it so each unavoidable complexity in syntax has its own home, instead of piling together like C++/Java/etc.

prirun 6y ago

This is one of the things I disliked about Nim. I spent a few weeks with it hoping I'd love it as much as Python. But there are quirks in the type system that seem rather baffling to me, and frankly, ugly. Like having to type integer constants with 23'i32 because 23 is an int and int is not compatible with int32 (nor is it compatible with in64!) There are typed integer constants in many stdlib sources too. In the tutorial, the language looks quite nice, comparable to Python. But in production level code, there are {.pragmas.} in a lot of places and they are not just advice for the compiler that can be ignored: they are important keywords that don't pollute the identifier space. Another beef I had is that slice ranges and for loops are closed intervals by default. This is contrary to both Python and C, and while there is a syntax a..<b to be open on the right, it seems like a bad decision to be different from C and Python by default. It reminded me of Julia arrays starting at 1 by default. I guess I can see that if your audience is Fortran programmers, but arrays haven't started at 1 in a new language for a long time afaik. I wish Nim had a goal of being a typed, compiled Python. But I don't think that ever was a main goal and now it's sort of too late because the language has a very wide scope (my opinion) and has compatibility concerns with all of its previous design choices.