Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon Language: An experimental successor to C++

github.com

Post reply on HN
Print view View original

191–200 of 521 posts

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

#191

Post by masklinn »

nikolay wrote: post #174

Well, `returned var` is totally unnecessary - why didn't they borrow the syntax from Go?!

https://github.com/carbon-language/carbon-lang/blob/trunk/pr...

> Disadvantages:

> - The syntax space of the return type is very crowded already, and this would add more complexity there rather than fitting in cleanly with existing declaration spaces within the body of the function.

> - Likely to be an implementation detail and valid to use on a function with a normal return type in its forward declaration. This isn't obvious when placed in the declaration position, and it might well be unnecessarily added to forward declarations just because of its position.

> - Removes the ability to both specify a specific return type and a pattern for binding parts of that object to names. Instead, the type must be inferred from the pattern. This ended up feeling like a deep and fundamental problem where we would lose important expressivity to disambiguate the return type from patterns. For example, when the return type is some form of sum type or variant, the pattern space is both especially attractive to use and fundamentally fails to express enough information to capture the type.

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

#192

Post by nerdponx »

cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

I would also wonder about D and Odin, neither of which are particularly successful but both of which are also supposed to be kind of like C++ replacements.

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

#193

Post by Koshkin »

compiler-guy wrote: post #147
danjoredd wrote: post #140

Don't create a programming language to kill another language. That never works. Create a language that fulfills a specific purpose.

Carbon is intended to kill C++ in just the same way as C++ is designed to kill C, Kotlin is designed to kill Java, and Dart is designed to kill Javascript. Which is to say, "Not at all".

Well, to be fair, "successor" can indeed be understood as "replacement."

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

#194

Post by Jabbles »

saagarjha wrote: post #109

(Speaking only for myself, I just watch from the sidelines and have no involvement) This seems like Google’s response to 1. Rust not being sufficiently “Go-like” (in the sense of the “The key point here is our programmers are Googlers, they're not researchers” quote) where C++ lets a bunch of people who are not really experts in the language write footguns that Google has to deal with when they cause problems at scal…

(1) does not seem true, they have documented some seemingly detailed reasons why Rust is not always the right choice, and acknowledge that in many cases it is: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

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

#195

Post by Koshkin »

danjoredd wrote: post #140

Don't create a programming language to kill another language. That never works. Create a language that fulfills a specific purpose.

This is rather deep, if you think about it. My gut feeling, coming from experience, is that the future lies with DSLs. A good programmer would mold the the general-purpose language he works with into a DSL fitting the problem at hand anyway (using whatever means available, e.g. macros or generics or both). Incidentally, the modern Lisps and C++ look the best in this regard.

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

#197

Post by KerrAvon »

kllrnohj wrote: post #62
zozbot234 wrote: post #31

Earlier quoted context omitted.

Isn't this one of the most prominent features in D? Sounds like they're trying for something very much like D, while starting closer to current C++.

D still requires you to write bindings, see https://dlang.org/spec/cpp_interface.html Also D objects have a different lifetimes & requirements, which complicates things ( see https://dlang.org/spec/cpp_interface.html#lifetime-managemen... ) Carbon appears to be auto-generating bi-directional bindings, and since it has the same memory model has no such awkward interactions between non-GC'd and GC'd worlds like D does.

This is true, although there is this:

https://dlang.org/blog/2019/04/08/project-highlight-dpp/

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

#198

Post by WalterBright »

cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

Which is what D can do. D can (and does) interact successfully with C++ classes and member functions. Even templates!

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

#199

Post by fluoridation »

yakubin wrote: post #119
fluoridation wrote: post #91

Earlier quoted context omitted.

An std::vector is a vector in the mathematical sense, though. It's a homogeneous tuple. It's just that using an std::vector of std::vectors to store a list of points would be inefficient.

It's not. Vectors can be added together and multiplied by scalars. That they are often represented as tuples of coefficients is just notation, doesn't matter for the notion of vectors, and vice versa: a tuple is not necessarily a vector. 1. std::vector doesn't have a fixed dimensionality, as would a mathematical vector. A fixed-length array actually makes more sense as a vector. 2. It doesn't provide the operations o…

1. That doesn't make it not-a-vector. It just means there isn't a one-to-one correspondence between std::vector and T^n. However, a particular instance x of std::vector is still a T^x.size().

2. Operations are not intrinsic to a set, but to an algebra. Why would there need to be any correspondence between the operations of linear algebra and those of banking algebra in order to call an std::vector a vector?

Post reply on HN