My thoughts on Carbon

[masterneko]

Hi, I'm C++ developer, and I'm interesting this new language. I wanted to share my thoughts and suggestions as I feel I may be using this language in the future and I would like it to nice to use.

Things I like:

• I definitely like the module system, and especially the interoperability between Carbon and C++ headers.
• The modern generic system gives the language a far better advantage compared to C++ which has only just introduced template type restrictions (a.k.a concepts) in C++20. Generics passed as function arguments is also great and makes the code way cleaner.
• I'm glad to see the std::cout operator<< syntax gone, replaced with much more concise the Print function

Things I don't like:

• I'm not sure why the return type is declared after the function declaration in this language. The syntax uses a redundant a fn keyword, and -> symbol. I personally feel like the way functions are defined in C++ is more elegant.
• Like the function syntax, I'm not a fan of the variable declaration syntax. Instead of i32 x = 42, I would have to write var x: i32 = 42, this just means I have to type more to declare a variable. I understand that this syntax probably makes the language easier to parse but for a language that is trying to be a "successor to C++", I don't think it would help migrating C++ developers.

Things would be nice to have:

• Macros - I'm sure you'll know that C/C++'s macro system is terrible. A type safe, hygienic macro system would be perfect, maybe even a macro system that lets modify the AST.
• Documentation and more examples

Anyway, I hope my feedback is useful

ty bye

[edwardlee4948]

I like that they use fn and ->.
a: i32 = ...
This style is more modern.

[cdmaczane]

This comment is very subjective.

[psypdt]

Regarding the function syntax whats the reason behind placing the return type at the end of the function? Personally I find it easier to have the function syntax like it is in C++ because I immediately see what the function returns no matter how long it is, but im wondering is there a technical reason behind this?

This also extends to the variable declaration, if I have something like

veryLongVariableName : i32 = 1;
i : i32 = 3;

vs

i32 veryLongVariableName = 1;
i32 i = 3;

For me personally I feel that the second is easier to read because I don't have to go looking for the type. Again im just wondering if theres a technical reason for this or if comes down to preference.

Thanks 😄

[rahulrawat74385]

Same thoughts they should try to make a language as familiar to currently available as possible. This would make switching to Carbon easier

[jwtowner]

One thing to consider is that placing the variable type or return type to the right of the identifier name allows for the identifier names to align with one another without additional indentation, and it makes reading code a lot easier. In practice, the identifier name of a variable, function or method is far more important than the type details, when it comes to reading, comprehending and maintaining code. I've found this is something many C++ programmers start to realize the more they use the auto keyword or trailing return types.

[freedxmgxd]

Well I think that the motivation for this new sintaxe it's because the formal notation of type theory, https://en.wikipedia.org/wiki/Type_theory .
And if so I agree with the choice, it's very graceful if the Programming languages can match more confident the mathematical notation.

[jonmeow]

Declarations such as fn and var are added in order to reduce syntactic ambiguities, allowing tools (compilers, IDEs, etc) to both behave and perform better. The ambiguities in C++ come at an expense.

https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0618.md goes over the var order choice in detail.

[pache-Ak]

I agree, we need a keyword to specify that the name is a type. A bad feature is displayed in Elaborated type specifier that explains why the display identifies an identifier as a type or a statement as a declaration. Even if we need to enter a few more characters.

For generics, function return types are sometimes related to parameter types, and in my C++ practice, trailing return types simplifies my code a lot.

But I don't like -> and :

I prefer this syntax :

For function fn name(args) return-type

For declarative syntax keyword type name

I don't think -> and : is good for tools and us, both tools and us need read more.

[kuredoro]

Yeah, these : and -> look a bit like a syntactic noise. I like the Go-like syntax for functions at least: func Foo(a, b int, bar string) string. Though on the other hand, if we have those monster template types like in C++, using -> BigBigType on a new line could benefit readability too.

[geoffromer]

For declarative syntax keyword type name

One drawback of this approach is that it doesn't scale as well to situations where you're declaring multiple names, such as functions with more than one parameter:

fn Foo(keyword Type1 name1, keyword Type2 name2, keyword Type3 name3)

The : acts as a much more concise marker that a name is being declared:

fn Foo(name1: Type1, name2: Type2, name3: Type3)

[rscircus]

From https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write:

Excellent ergonomics. Human capabilities and limitations in the domains of perception, memory, reasoning, and decision-making affect interactions between humans and systems.

• Considering keyboard ergonomics special characters are always more challenging than alphabetic characters.
• Considering the visual processing I wasn't able to find too many studies quickly.[0]

[0]: This one shows that single letter processing speed is much much lower than word processing speed. Wonder what happens when special characters are compared. My guess would be that the gap widens even more and favors words instead of symbols/single letters.

[OlaFosheimGrostad]

Such studies are fun to read about, but more difficult to apply. Context matters a lot. For instance, I once argued that it would be better to have "and" instead of "&&" as a bool operator in another language and a Chinese programmer got very upset about this as "&&" was a much better fit for him. Which is natural, when you think about the visuals of Chinese symbols. Another example: I have in the past decades read more English texts than Norwegian, but I still read faster and more accurately in my native language, and it is less tiresome as well… Formative years might have a significant impact on what you measure.

There is sadly very little applicable research on programming language syntax outside languages targeting educational contexts or beginners. Also, much research is done with students as subjects, as the link you provided, which introduce bias by itself…

[YagaoDirac]

cache line?

[Twins-Divyanshu-Sharma]

why use
var name : i32
why not
name : i32
or
var name

its a strongly typed language with ILLUSION of weakly typed

[YagaoDirac]

I agree some of your ideas. But I also would like to say something. Let me only mention what I don't agree.

Things I don't like:

* I'm not sure why the return type is declared after the function declaration in this language. The syntax uses a redundant a `fn` keyword, and `->` symbol. I personally feel like the way functions are defined in C++ is more elegant.

* Like the function syntax, I'm not a fan of the variable declaration syntax. Instead of `i32 x = 42`, I would have to write `var x: i32 = 42`, this just means I have to type more to declare a variable. I understand that this syntax probably makes the language easier to parse but for a language that is trying to be a "successor to C++", I don't think it would help migrating C++ developers.

Sometimes, it's about the readability. But maybe it's better to maintain multiple grammars and separate them somehow.

Things would be nice to have:

* Macros - I'm sure you'll know that C/C++'s macro system is terrible. A type safe, hygienic macro system would be perfect, maybe even a macro system that lets modify the AST.

Macros is probably the biggest obstacle for auto completion. Auto completion is so important that all the features should give the way to it.

Except for what I mentioned, I agree with all the other ideas. Documentations and examples are so important, I would like to recommend add them into language specification.

[0dminnimda]

I think it's much more useful to agree, that the bike shed will be red and move on to the more important topics.