because almost none of the symbols in the syntax resemble other languages. For example, parentheses instead of <> for a generic type/template this seems to go against a low learning curve

[insinfo]

because almost none of the symbols in the syntax resemble other languages. For example, parentheses instead of <> for a generic type/model, this seems to go against a low learning curve and also seems to go against familiar C-style languages, C-style languages ​​like C++/Java/C#/ dart/Php among others are quite easy to learn. I confess that I was a little disappointed to see such a different syntax instead of something familiar, one of the things I liked most about Dart was its familiarity with other languages ​​such as javascript, java and C# so simpler without so much java verbosity with much less reserved words and at the same time extremely powerful. Because you can't make a modern object-oriented language like Dart but with a focus on high performance, no garbage collector, compiled ahead of time and with familiar syntax.
I was disappointed in the V, Vale, Zig, Nim, and Rust programming languages ​​for the same reasons, because of their strange syntax and also lack of object orientation.

[insinfo]

I think this also affects attracting C/C++ programmers as it's a very different syntax. I read the video comments https://www.youtube.com/watch?v=omrY53kbVoA&ab_channel=CppNorth
and that most of the complaints are about the weird, unfamiliar for C/C++ style syntax.

[insinfo]

Just some of the comments.

Why does let represent an immutable declaration when in javascript let is the mutable while const is the immutable. it just causes confusion :(.

""fn" and "->" and ":" are not needed to define a function and make the programmer type extra unnecessary characters."

"Also, strange symbols compared to other languages. Who writes "Circle(i32)" instead of "Circle<i32>" ?"

[steplee]

They stated they are going for a design where a type is a kind of value. This probably makes the parsing more consistent. And it leaves room open for reflection. If you don't like it, don't pay attention. It will take time for the project to mature anyways.

[juniperfdel]

Carbon's syntax seems to have been inspired by typed python (and maybe typed GDScript?) which makes it comfortable to use as a c++/python developer. I like the python way of treating generic types like variables and functions as it helps readability a lot and am glad to see it utilized here

[emlai]

Existing successful successor languages, TypeScript, Kotlin, and Swift (even Rust) all use <> for generics. Their design teams have already considered the options carefully, and settled on <>.

Carbon should learn from existing design work of languages with the same goal.

[josh11b]

Carbon has a goal of being easy to parse for tooling, which has meant that we have considered and rejected angle brackets <...>, due to experience with the difficulties parsing them in C++. The generic syntax was discussed and decided in #565 .

[emlai]

But Carbon is not C++ so we are free to make <> much easier to parse than C++. We can look at how TypeScript, Kotlin, Swift, Rust, and others, solved it. If so many other successor languages chose <>, there must be a good reason for them doing so. Most likely they also want to be easy to parse, so there must be a reasonable solution for achieving it. I think it's worth reconsidering since it majorly affects the language's familiarity for its target audience.

[insinfo]

@josh11b

Carbon has a goal of being easy to parse for tooling...

I thought programming languages had to be easy for the programmer. I thought that programming languages should make the programmer's life better. I didn't know that programming languages had to make life difficult for the programmer by using strange syntax to make tools easier.

[insinfo]

I believe that a successor language to C++ should have a familiar syntax, perhaps reducing the verbosity of C++ (just like dart is a C# but simple), eliminating the need for header files (I don't like header files), having fast option secure innovative automatic memory management like Vale, Rust and V lang, but without losing the power to manage memory manually when required, but it doesn't have to be something out of this world.

That

could be like that

package Geometry;

import Math;

class Circle{
    f32 r;

    void scaleAreaAndAppend(i32 log2Scale, Vector<f32> &results){
        var area = Math.Pi * self.r * self.r;
        const scale = 1 << log2Scale;
        area *= scale;
        results.add(area);
    }
}

[josh11b]

@insinfo

Carbon has a goal of being easy to parse for tooling...

I thought programming languages had to be easy for the programmer. I thought that programming languages should make the programmer's life better. I didn't know that programming languages had to make life difficult for the programmer by using strange syntax to make tools easier.

Each of these design decisions is a trade off and different programming languages will make different choices according to their priorities. Carbon specifically has a stated goal that parsing should be simple to implement, see https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write specifically "Support tooling at every layer of the development experience, including IDEs" and "Design features to be simple to implement"

[emlai]

Proper tooling would use the compiler APIs or the Language Server Protocol for parsing -- not implement the parsing from scratch. So I don't think that goal means what you think it means. Implementing Carbon parsers is exceedingly rare and we shouldn't optimize for that use case at the expense of the majority of the user base. I think that goal ("Support tooling at every layer of the development experience, including IDEs") means that Carbon should provide compiler APIs/LSP specifically so that tooling would not need to re-implement parsing. I think that goal should be clarified to be more clear about this.

Sure, sometimes you need to make trade-offs like this and they might be different for each language. But I don't think it applies here, since, again, stuff like <>-for-generics can be made easy to parse as proved by most modern languages. Which would allow us to satisfy other goals such as "Excellent ergonomics", "Adhere to the principle of least surprise", even satisfying "Cost-benefit will drive many choices".

[nigeltao]

Existing successful successor languages, TypeScript, Kotlin, and Swift (even Rust) all use <> for generics. Their design teams have already considered the options carefully, and settled on <>.

Go's design team also considered the options carefully (there was a lot of discussion on Go's generics, at the syntactic and other levels) and settled on not using angle brackets. This was in part because of potential ambiguity with the << and >> bit-shift operators, which aligns with the "Carbon has a goal of being easy to parse for tooling" comment.

[nigeltao]

It's not just double-angle brackets. There's even potential ambiguity with single-angle brackets. Go lets you write a, b = x, y for what's hopefully an obvious multiple-assignment. Now consider this snippet:

a, b = w < x, y > (z)

Is that similarly a multiple-assignment (RHS is (w < x), (y > (z))), or is it a generic function call (RHS is (w<x, y>)(z))? If your parsing tool or library has only seen a, b = w < x, so far, what's the state representation?

Carbon syntax isn't exactly Go syntax, but still, it really simplifies things to avoid angle brackets.

See also the "We've been trying to avoid angle brackets because they create very serious parsing problems" comment at #1691 (comment)

[chandlerc]

I don't really see a specific and actionable proposal here. As @nigeltao mentions, #1691 covers the only specific part of this (using <...> for generic parameters) and seems to have more details and be more concrete. I'm going to close this issue for now as I think @josh11b and others have effectively addressed the generic consideration as well.

That said, if folks have specific and concrete changes to the syntax of Carbon that they would like to propose, I encourage them to do so. IMO, the best way to do this would be to draft a proposal following our evolution process and discuss the tradeoffs, motivations, and implications of it.