I wish they spoke more about their ideas regarding the memory model. For me, that's usually the first thing I want to know about a new language.
(I initially assumed they had some syntactic sugar for smart pointers.)
Carbon Language: An experimental successor to C++
211–220 of 521 posts
Re: Carbon Language: An experimental successor to C++
#212Earlier quoted context omitted.
Must be avoiding the stigma of the broken promise not to be evil.
The thing is they have an excellent track record with runnig open source programming languages for over a decade. It's often claimed that Go succeeded only because it was sexy because it was Google. Why hide it here?
Being a benefactor doesn't trump being an abuser at the same time.
Re: Carbon Language: An experimental successor to C++
#213Earlier quoted context omitted.
A vector can't change its size or contain things that aren't elements of a field. A std::vector can.
Yes, you can have a vector of, say, naturals. I'm pretty sure you can even create a vector field out of vectors of non-reals.
A "vector field" and a "field" are two completely different notions. (And yes, you can build a field from integers.)
Re: Carbon Language: An experimental successor to C++
#214Earlier quoted context omitted.
Doesn't C++11 precede rust?
I had the same question as you so I checked. C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010.
> C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010.
Given that c++0x was a decade in the making, by that measuring stick the answer is yes, C++11 does precede Rust.
Re: Carbon Language: An experimental successor to C++
#215Earlier quoted context omitted.
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?
2. I'm not sure I understand you here. A vector is defined by those operations. A set without those operations, even if it has the same elements, is not a set of vectors anymore. I don't understand your remark about sets here. The correspondence is necessary, because those operations on vectors are induced from the operations of the relevant field of scalars. The operation of adding vectors of bank numbers would be induced from the operation of adding bank numbers, if there was any such thing. The operation of multiplying vectors by scalars (bank numbers in this case) would need to be induced from the operation of multiplication of bank numbers, if there was any such thing. Anyway, I think you got hung up on the example, when the point is you can have std::vectors of types for which those operations don't make any sense. Now, imagining that perhaps there hypothetically might exist some definitions of those operations, just to convince oneself that std::vector is a vector is really stretching it, and I'm not even sure at this point if you're not trolling.
Anyway, as another commenter pointed out, Stepanov himself, who gave this container its name, said that it has nothing to do with vectors, and he wouldn't name it vector, if he could correct this mistake.
Re: Carbon Language: An experimental successor to C++
#216Earlier quoted context omitted.
Nor does it convey any confidence that Google will support it.
Can we not with this tired joke. Yes we're talking about the company with hundreds of chat apps, but we're also talking about the 100,000+ employee company that developed and support Golang, Dart and Flutter. But ignoring all this, the GitHub page is pretty clear: "Carbon is currently an experimental project." You shouldn't have confidence that it will be supported but they are pretty clear about it, they're trying t…
>> Can we not with this tired joke. . . . You shouldn't have confidence that it will be supported . . .
It is not a joke.
It is a reputation that Google has earned through its actions and inactions.
As shown by https://killedbygoogle.com/ and numerous desperate posts for help [1][2][3] on this and other web sites, Google's "must launch a new shiny thing" promotion culture and abysmal customer service have eroded public trust in the long-term viability of anything that Google creates.
[1] https://news.ycombinator.com/item?id=5523992
Re: Carbon Language: An experimental successor to C++
#217Earlier quoted context omitted.
> is objectively superior Those objective criteria of superiority being?..
It eliminates the Most Vexing Parse. Consider this C++ code: Foo bar(); A programmer could make simple mistake thinking that is declaring a variable of type Foo. Carbon eliminates this by having explicit keywords for variable and function declaration. (This style is much more Rust based than C++) fn bar() -> Foo; var bar : Foo; It makes parsing easier for both the users and maintainers of the language.
> It eliminates the Most Vexing Parse.
C++'s most vexing parse issue ceased to be a concern around a decade ago with the introduction of uniform initialization.
Re: Carbon Language: An experimental successor to C++
#218(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...
Google can have many reasons why they do something. Not all of them will always be listed publicly, or even be written down :)
Re: Carbon Language: An experimental successor to C++
#219Earlier quoted context omitted.
.. is it new development?
I guess, unless you're into retro-gaming.
To be fair, parts of my work codebase are touching on 25 years old, and I work for a startup from 2020. The codebases we're building on have roots in the mid 90s, and the platforms they run on didn't support modern C++ standards for a very long time after that.
Re: Carbon Language: An experimental successor to C++
#220Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give r…
I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic.
The rest I can excuse but [], I cannot. Same reason I won't touch Nim.