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

251–260 of 521 posts

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

#251

Post by boardwaalk »

StillBored wrote: post #223
fouronnes3 wrote: post #134

Earlier quoted context omitted.

C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.

"C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinc…

You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all.

Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)

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

#252

Post by xigoi »

dleslie wrote: post #13
mda wrote: post #5

Earlier quoted context omitted.

Why is it an obvious footgun?

A developer familiar with C++ may believe it to be a fixed length container (perhaps with automatic bounds checking[0]) and treat it as such in memory/security/performance critical sections. 0: https://en.cppreference.com/w/cpp/container/array/at

And if they named it “vector”, a developer familiar with mathematics might believe it to be a vector.

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

#254

Post by xigoi »

jimbob45 wrote: post #220
beeforpork wrote: post #50

Why 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.

I can't handle syntax for generics. It's impossible to auto-pair and looks ugly.

The real solution is [] for generics and something else for indexing.

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

#255

Post by Jensson »

maccard wrote: post #219
pjmlp wrote: post #171

Earlier quoted context omitted.

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.

So anything including "windows.h" isn't really new development then? Sounds like a strange definition.

I'd say that there is a lot of new projects being started with C++, still way more than there are new projects in Rust, at least if you only count serious ones.

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

#256

Post by xigoi »

mihaic wrote: post #133

Am I the only one that doesn't like this direction for the syntax? This was the main reason why I never got into Rust, it was just too different without any obvious reason. It's strange that I actually enjoy working with type annotated modern Python though. I'll now go away for a few years until the dust settles.

The obvious reason is that C++ syntax is difficult to parse, for both machines and humans.

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

#258

Post by fluoridation »

xigoi wrote: post #233
fluoridation wrote: post #204

Earlier quoted context omitted.

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.

Really? What is the additive inverse of (1, 2, 3) ∈ ℕ³ ?

It depends on how you define addition.

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

#259

Post by fluoridation »

yakubin wrote: post #240
fluoridation wrote: post #227

Earlier quoted context omitted.

A vector is defined as I did above. It's a homogeneous tuple, i.e. the Cartesian product of n sets, where all sets are the same. Vector addition plus scalar multiplication are not part of the set. Usually they're part of the definition of a vector space. E.g. (R^2, +, ⋅). But you can construct a vector space out of a set of non-vectors (such as matrices), or out of operations other than vector addition and scalar mul…

Then you're using a definition of vector, not used in any mathematics course. > you can construct a vector space out of a set of non-vectors (such as matrices) A vector is by definition no more and no less than an element of a vector space. Vectors are defined by vector spaces, not the other way around. If you have a vector space whose elements are matrices, then those matrices are vectors. And they will be written i…

>Then you're using a definition of vector, not used in any mathematics course. [...] A vector is by definition no more and no less than an element of a vector space.

It's the definition I was given. If you accept that the word "vector" may be given a definition different from the one you give it, you'll need to concede that an std::vector may be a vector.

>you don't choose them. You choose the field and dimension, and those operations (vector addition and scalar multiplication) are a consequence.

You're using the phrase "vector addition and scalar multiplication" in a different sense than I meant. I was referring to component-wise addition between two vectors and to multiplication between a scalar and the individual components of a vector. You could choose different operations to construct a vector space, as long as they meet the requirements of vector spaces.

You used the phrase to refer to the constructing operations of a vector space. So yes, a vector space is indeed constructed out of the operations it is constructed out of. You could have been more charitable in your interpretation of my words, rather than assume I was saying something equivalent to "four-cornered triangle".

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

#260

Post by cogman10 »

pron wrote: post #250
cogman10 wrote: post #237

Earlier quoted context omitted.

> programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10 Notable exceptions from the links you've provided: C#, Java, Go, PHP. All appear to have an upward trajectory today. Javascript has also seen a similar penetration boost when nodejs came on the scene. With rust looking to get integration both into the Linux kernel and GCC,…

> All appear to have an upward trajectory today. They might have an upward trajectory, but they're not posed to break well beyond their respective records. With the possible exception of Python, how popular a language is at age ten is a reasonable rough indicator of how popular it's ever going to be. At its current growth rate Rust would reach 1% market share at age ten. Again, there can certainly be surprises, but I…

> That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success.

I'd simply point to the fact that there are very few languages that have tried to get into the same space that rust exists in. Even something like D came with an optional GC which has pulled it out from consideration for things like the kernel or embedded devices.

When you say "most languages are peaked at 10 years" I'd simply point to the fact that rust is substantially different from most languages. It's not tackling the same market spaces. The ones it is hitting have been slow moving for a while now.

Post reply on HN