6 ms·

I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve on c++ and not improve the syntax or containers? It's like python never existed.

gbersac 11y ago
If syntax is still verbose (it's ok for me) at least it is clear. There is no ambiguity unlike c++.
kiiski 11y ago
If by that reference to Python you mean you want significant whitespace, I think that would make it unnecessarily difficult to work with different scopes. fn something() { foobar(); { bar(); foo(); } quux(); } That is much easier to understand, and easier for tools to work with (they can actually automatically indent your code without breaking it), than: def something(): foobar() bar() foo() quux() edit: And how would you even add a scope right after another block (like if)? That would require you to have a keyword anyway.
Symmetry 11y ago
There's always Nim if you want nice syntax but then you're working with a garbage collected language without a borrow checker.
shmerl 11y ago
> It's like python never existed. Whitespace / indentation used for scope delimiting in Python is a bad idea. No, thanks. I'm glad Rust isn't using anything like that.
- beerbajay 11y ago
  I agree that whitespace scope delimiting is a bad idea, but I was thinking more about general syntactical clarity. Just because C++ uses every possible typographical symbol doesn't mean rust should. Simple example which had me WTFing: use std::collections::{HashMap, HashSet}; Are all those ::s and {}s adding to clarity? Why are there no easy to use initializers for maps? It's 2015! I have to do: let mut map = ::std::collections::HashMap::new(); map.insert("a".to_string(), "b".to_string()); ... or some such nonsense. Oh, right, I have to write a macro and basically learn another language. Also, using the macro system for basic things like println just seems bonkers to me; use macros when you really, really need to do something special, not everywhere.
  - dbaupp 11y ago
    You personally don't have to write the macro: cargo makes it super easy to use ones others have written, e.g. https://crates.io/crates/maplit/ https://crates.io/crates/maplit/.
  - shmerl 11y ago
    Yeah, I also miss initializer lists[1] in Rust. Not sure why they weren't implemented, but it's a very good feature which is pleasant to use in C++11 and higher. It's way neater syntax than writing different macros like for vector and other containers. Is it something that developers just never got to implement, or they didn't want to do it for some reason? [1]: https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists
  - steveklabnik 11y ago
    Println is a macro because it needs to be: it does compile-time checking of the format string.
    - shmerl 11y ago
      Do you think it's feasible to implement initializer lists in Rust, or there is some language limitation which makes it hard? I.e. I'd prefer to write: let v: Vec<i32> = {1, 2, 3, 4, 5}; Instead of let v = vec![1, 2, 3, 4, 5];
      - steveklabnik 11y ago
        I'm not sure, other than that because {} evaluates to a value, this already looks very close to valid Rust; I thought it was for a minute, but realized that it's not quite. I'm not sure I personally feel that the first is particularly better than the latter, but it should have to be by a large margin to justify adding new syntax to the language.
        shmerl 11y ago
        I can explain why I think initializer lists style is better. You can have a standard / uniform syntax for initialization. And it's using already defined syntax for types to actually indicate what you are creating. Compare it to the current one. It's necessary to create a new syntax for each type (that you want to enable for such initialization). I.e. a macro. This macro also is different from already existing syntax which indicates the type (i.e. you have Vec and you have vec!). That's why I think current approach is more cumbersome and initializer lists style is more streamlined and elegant. > it should have to be by a large margin to justify adding new syntax to the language. C++11 put some effort into simplifying some cumbersome syntax constructs. It makes things easier to read and write which pays off.

gbersac 11y ago

If syntax is still verbose (it's ok for me) at least it is clear. There is no ambiguity unlike c++.

kiiski 11y ago

If by that reference to Python you mean you want significant whitespace, I think that would make it unnecessarily difficult to work with different scopes. fn something() { foobar(); { bar(); foo(); } quux(); } That is much easier to understand, and easier for tools to work with (they can actually automatically indent your code without breaking it), than: def something(): foobar() bar() foo() quux() edit: And how would you even add a scope right after another block (like if)? That would require you to have a keyword anyway.

Symmetry 11y ago

There's always Nim if you want nice syntax but then you're working with a garbage collected language without a borrow checker.

shmerl 11y ago

> It's like python never existed. Whitespace / indentation used for scope delimiting in Python is a bad idea. No, thanks. I'm glad Rust isn't using anything like that.

beerbajay 11y ago
I agree that whitespace scope delimiting is a bad idea, but I was thinking more about general syntactical clarity. Just because C++ uses every possible typographical symbol doesn't mean rust should. Simple example which had me WTFing: use std::collections::{HashMap, HashSet}; Are all those ::s and {}s adding to clarity? Why are there no easy to use initializers for maps? It's 2015! I have to do: let mut map = ::std::collections::HashMap::new(); map.insert("a".to_string(), "b".to_string()); ... or some such nonsense. Oh, right, I have to write a macro and basically learn another language. Also, using the macro system for basic things like println just seems bonkers to me; use macros when you really, really need to do something special, not everywhere.
- dbaupp 11y ago
  You personally don't have to write the macro: cargo makes it super easy to use ones others have written, e.g. https://crates.io/crates/maplit/ https://crates.io/crates/maplit/.
- shmerl 11y ago
  Yeah, I also miss initializer lists[1] in Rust. Not sure why they weren't implemented, but it's a very good feature which is pleasant to use in C++11 and higher. It's way neater syntax than writing different macros like for vector and other containers. Is it something that developers just never got to implement, or they didn't want to do it for some reason? [1]: https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists
- steveklabnik 11y ago
  Println is a macro because it needs to be: it does compile-time checking of the format string.
  - shmerl 11y ago
    Do you think it's feasible to implement initializer lists in Rust, or there is some language limitation which makes it hard? I.e. I'd prefer to write: let v: Vec<i32> = {1, 2, 3, 4, 5}; Instead of let v = vec![1, 2, 3, 4, 5];
    - steveklabnik 11y ago
      I'm not sure, other than that because {} evaluates to a value, this already looks very close to valid Rust; I thought it was for a minute, but realized that it's not quite. I'm not sure I personally feel that the first is particularly better than the latter, but it should have to be by a large margin to justify adding new syntax to the language.
      - shmerl 11y ago
        I can explain why I think initializer lists style is better. You can have a standard / uniform syntax for initialization. And it's using already defined syntax for types to actually indicate what you are creating. Compare it to the current one. It's necessary to create a new syntax for each type (that you want to enable for such initialization). I.e. a macro. This macro also is different from already existing syntax which indicates the type (i.e. you have Vec and you have vec!). That's why I think current approach is more cumbersome and initializer lists style is more streamlined and elegant. > it should have to be by a large margin to justify adding new syntax to the language. C++11 put some effort into simplifying some cumbersome syntax constructs. It makes things easier to read and write which pays off.