Readability (in the sense of "How fast can the average developer parse code in the given language?") and proneness to errors are a thing, though.
Consider, e.g., how in TypeScript object literals ({ a: b, c: d, e }), object types ({ a: b; c: d; }) and object destructuring ({ a, c, e } = … ) can all look very similar. Same thing for lambdas ((a: b) => b) and function types ((a: b) => b). Also, additional parentheses are needed to prevent the compiler from mistaking an object literal ({ … }) for a function body ({ … }) when it is returned in a lambda expression. In short: Some of TypeScript's syntactic constructs are heavily overloaded and their meaning depends on the context.
For an example of proneness to errors, consider that in Nix function calls (<function name> <param1> <param2> …) and lists ([<item1> <item 2> …]) look almost the same and it's very easy to confuse the two and mess up, e.g.
Sure but I don’t think those examples really matter once you establish basic familiarity with a language. The semantics and constructs a language provides are much more important and debating syntax is missing the forest for the trees
Readability (in the sense of "How fast can the average developer parse code in the given language?") and proneness to errors are a thing, though.
Consider, e.g., how in TypeScript object literals ({ a: b, c: d, e }), object types ({ a: b; c: d; }) and object destructuring ({ a, c, e } = … ) can all look very similar. Same thing for lambdas ((a: b) => b) and function types ((a: b) => b). Also, additional parentheses are needed to prevent the compiler from mistaking an object literal ({ … }) for a function body ({ … }) when it is returned in a lambda expression. In short: Some of TypeScript's syntactic constructs are heavily overloaded and their meaning depends on the context.
For an example of proneness to errors, consider that in Nix function calls (<function name> <param1> <param2> …) and lists ([<item1> <item 2> …]) look almost the same and it's very easy to confuse the two and mess up, e.g.
``` let foo = [ item1 myFunction "arg1" "arg2" item3 ] ```
defines a list with 5 items, not 3, due to missing parentheses around the function call.
Sure but I don’t think those examples really matter once you establish basic familiarity with a language. The semantics and constructs a language provides are much more important and debating syntax is missing the forest for the trees
The array syntax is very offensive: `const a = [3]i32{ 1, 2, 3 };` A set is denoted by braces, not an array.
1. using [] drops context-freeness. what is: foo[1]? is that foo type array with one element? or accessing the foo array at index 1?
2. how do you feel about array initialization in C?
3. you can think of {...} as defining memory regions, curlies around code are defining "a memory block of instructions"
According to your familiarity yes, but how is this such a problem? It’s easy to get past
Yes it is according my familiarity, but set notation has been the same since the 1870s, why should this language fuck it up? Rust does it correctly.
This is exactly why I find the language unintuitive. I don't understand why they made the choices they made. For example, why curly brackets?
I find the rust equivalent much more intuitive `let a: [i32; 3] = [1, 2, 3];`
It’s targeting C/C++ programmers accustomed to initializer lists in C/C++.
you couldn't do that in zig because a type is potentially a valid value:
.{i32, 3} is a valid term in zig.