Live data from Hacker News

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

21–30 of 200 posts

Re: Carbon Language: An experimental successor to C++

#21
post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

F# uses “fun” and I like it. The vowel does help a bit and I never confuse it with the English word. The worst one IMHO is Haskell’s “\”.

Re: Carbon Language: An experimental successor to C++

#22
I remember back when Rust was still in so much flux that there were regular discussions about syntax, and there was a proposal very similar to the syntax of carbon: square brackets for generics and type annotations, parens for indexing, etc. It was basically turned down because they wanted to win over C++ devs. I still wish it was the favored outcome...it looks so much cleaner and less jarring.

Re: Carbon Language: An experimental successor to C++

#23
post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

Pony's keywords are the best. "fun" and "be" are just, well, fun lol.

I agree, I hate fn. Also not a fan of func though.

Re: Carbon Language: An experimental successor to C++

#24
post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

How about "proc"? Too different? I don't like fn either but function is too much. Fun and func aren't great either. I'd go with proc or fn.

Re: Carbon Language: An experimental successor to C++

#25
post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

Tbh, I wonder why modern languages still have a function keyword at all, e.g.: const add = (a: i32, b: i32): i32 => a + b; ...or any variation of the arrow-function idea...

That looks like a variable that points to an anonymous function. For simple small functions here and there it may not matter, but if the entire call stack in a debugger is full of anonymous functions then it could be a problem.

Re: Carbon Language: An experimental successor to C++

#26
post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

Re: Carbon Language: An experimental successor to C++

#27

Earlier quoted context omitted.

It's an ongoing project, specifying a date here wouldn't make much sense.

is there any news? the website has no information and doesn't really highlight anything other than their launch at a conference in 2022.

Yes. pjmlp answered here, but before he posted his reply, nxobject commented with the roadmap which covers 2025 and beyond:

https://docs.carbon-lang.dev/docs/project/roadmap.html

Even on the submitted page, the oldest you could claim it represents is 2024. But I stand by my earlier remark. When linking to an active project's documentation or home page, unless it's to a specifically dated version of it, a date doesn't make sense. For instance, linking to something specific in Python 2.6 documentation, maybe add a date. But if it's just to python.org, it would be absurd to tag it with [1991].

Re: Carbon Language: An experimental successor to C++

#28
post #5

If you've seen this before, it's worth looking at the 2025 roadmap – it's long-term work, a full safety story hasn't been quite figured out (TBD end 2025), and 0.1 is TBD end 2026. About the pace of Rust, although without the active forum that Rust had in its early days. https://docs.carbon-lang.dev/docs/project/roadmap.html What _is_ interesting is that I get the impression that Carbon is being workshopped with the…

> being workshopped with the C++ community

Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.

Re: Carbon Language: An experimental successor to C++

#30

I remember back when Rust was still in so much flux that there were regular discussions about syntax, and there was a proposal very similar to the syntax of carbon: square brackets for generics and type annotations, parens for indexing, etc. It was basically turned down because they wanted to win over C++ devs. I still wish it was the favored outcome...it looks so much cleaner and less jarring.

Nah, IMO they're both pretty suboptimal, and if Rust is going to choose between two bad options, it might as well choose the overwhelmingly familiar option. (Sadly, my strong opinions on what type parameter and indexing syntax should look like are too large for this margin to contain.)
Post reply on HN