Live data from Hacker News

Carbon Language: An experimental successor to C++

github.com

291–300 of 521 posts

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

#291
post #250

Earlier quoted context omitted.

> 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 langu…

While others with GC are used without issues on embedded for the last decade when users aren't stuck on ways of the past.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.microej.com/

https://www.astrobe.com/

https://www.wildernesslabs.co/

Ah but that isn't serious enough.

I guess battleship weapons control might be something serious,

https://dl.acm.org/doi/10.1145/2402709.2402699

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

#292
post #250

Earlier quoted context omitted.

> 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 langu…

But every language needs to get a foothold within its hype period. In a few years the hype for Rust will die down, at that point you wont get new blood unless they are forced to learn it so it will be hard to grow.

Programmers are forced to learn C++ since many jobs require it. Students were forced to learn Python since teachers choose it as a language at universities. You need some reason like this for a language to thrive after its hype cycle is over, and currently there are no such reasons forcing programmers to learn Rust and it doesn't look like there will be any within a few years either.

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

#293
post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2…

robotics is primarily c++ and python. that may change to being rust and python, but it will definitely take some time.

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

#294
post #238

Looking at this [0] news from about a month ago, the Chrome team showed that they are trying to bring Rust to the table. However, their wording was: > The Chrome security team is working to make a cross-platform memory safe language available to Chromium developers. This document describes how to use that language in Chromium. The language, at least for now, is Rust. Could this mean that the "at least for now" part m…

Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you.

But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution.

Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched with "Eh, we'll do safety later, I'm sure we don't need to start with it". The ones I'm thinking of all began with their safety principles and then they added cool features which were inspired by those principles.

I reckon that even if that's not directly causal, it means the culture associated with these "We'll do safety later" languages doesn't prioritise safety highly enough. So ambition or not, they aren't going to put the hard work in to make it actually happen.

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

#295

Earlier quoted context omitted.

> In otherwords, what carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interopt. Most don't do that, instead you'd make a C function binding and struct and move data/invoke functions through that. https://cxx.rs

cxx is great but it isn't anything close to what cogman10 is describing. It actually can't ever be, because C++ has move constructors and Rust deliberately doesn't, so you can't for example return `std::string` from a Rust function by value.

It's currently unclear if Rust can interop with C++ with high fidelity. For example https://docs.rs/moveit/latest/moveit/ and https://github.com/google/crubit/blob/main/rs_bindings_from_... provide functionality to use non-trivially relocatable C++ types from Rust.

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

#296

Earlier quoted context omitted.

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

dlang would have been a very serious contender to C++ had it been fully nogc, stable & lean. Also dlang unnecessarily suffered low adoption in start due to competing stdlibs, trying to be both Java & C++ at once.

If you use the @nogc attribute, D is fully nogc.

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

#297
post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

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.

Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve.

Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.

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

#298
post #291

Earlier quoted context omitted.

> 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 langu…

While others with GC are used without issues on embedded for the last decade when users aren't stuck on ways of the past. https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.microej.com/ https://www.astrobe.com/ https://www.wildernesslabs.co/ Ah but that isn't serious enough. I guess battleship weapons control might be something serious, https://dl.ac…

Major problem with GC languages is that it is horribly to link against libraries that ships with a GC. Lets say I want to use 10 libraries, if each has their own GC then my program is now running with 10 GC's each trying to optimize itself, which isn't a tenable situation.

So system level libraries has to work without a GC, even though system level programs can work fine with a GC.

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

#299

Earlier quoted context omitted.

As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2…

My impression as a CS grad is that very few computer science courses require you to learn C++.

what languages you learn at university highly depends on the specific school you are at, the professors, and which companies are donating the most money. it's certainly not a great representation of what is going on in the industry as a whole.

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

#300

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!

D has also taken a big step forward in being able to directly import C code. You can do things like:

    import stdio;
and it will compile stdio.h with the builtin C compiler, making all the declarations in it available to your D code.
Post reply on HN