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

301–310 of 521 posts

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

#301

Post by slingnow »

mtlmtlmtlmtl wrote: post #278
pron wrote: post #226

Earlier quoted context omitted.

> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming langu…

GP said the standard low-level language. Low-level code will always be a much smaller percentage of all code than the heaps of web apps our industry is shitting out on a daily basis. Thus it would be completely reasonable for the de facto sysdev language to have a small market share overall(unless like for C/C++ there is a lot of legacy stuff to maintain) . Your sources don't shine any light on this at all.

You don't think comparing the current defacto standard low-level languages (C/C++) to Rust shines any light on the issue you raised? [1]

C/C++ : 6.17% Rust : 0.29%

This was addressed in one of the linked sources. What would you accept as evidence, then?

1: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

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

#302

Post by germandiago »

boardwaalk wrote: post #251
StillBored wrote: post #223

Earlier quoted context omitted.

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

The problem with the typical rants about C++ is that you guys are outdated.

With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.

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

#303

Post by varajelle »

jcelerier wrote: post #266
LorenDB wrote: post #224

Earlier quoted context omitted.

Honestly, the only thing lacking with D (for me) is the lack of good support from Qt (which I think is something Qt should tackle by making the moc multilingual). But I agree with Walter. D already did what Carbon is trying to do, but the syntax is easy enough to pick up in a weekend.

> Honestly, the only thing lacking with D (for me) is the lack of good support from Qt (which I think is something Qt should tackle by making the moc multilingual) it's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/ , why wouldn't it be possible from D ? it should be even easier considering that D traits allow reflection of member and function names, etc.

It is possible, but nobody did it.

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

#304

Post by jokoon »

pipeline_peak wrote: post #36

All these C++ "successors" that do nothing but change the syntax sugar and find ways to operate with C++ are really tiring to read about. I seem to be the only one on the planet that doesn't think the language needs to be replaced.

I agree.

Although I still think it should be possible to make some things obsolete in C++. The technical debt is real, and the language can hardly improve if old codebases are slowing down the evolution of the language.

I already wrote several times that I would like a new C++-like language, but without the complexity of C++. D, zig and rust are fine but they're not simple languages to use. I want the nice things of C++ (string, a few containers, a bit of syntax sugar, the most useful std stuff), with enough simplicity from python or C.

I just use the simple parts of C++, and I only want those parts. I just want the KISS simplicity. Carbon is not that, neither is rust zig or D.

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

#305

Post by germandiago »

fancyfredbot wrote: post #185
mihaigalos wrote: post #153

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

My impression is that C++ is used in the real world though. :)

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

#307

Post by zozbot234 »

coder543 wrote: post #268
Jabbles wrote: post #194

Earlier quoted context omitted.

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

> Seamless interop where existing, unmodified C++ APIs are made callable from safe Rust requires the C++ code to follow borrow checking rules at the API boundary. > Seamless interop where safe Rust APIs are made callable from C++ requires C++ users to follow Rust borrow checking rules. Their complaints about borrow checking rules at the interop layer ring hollow to me. Whether the new code is being written in Rust, C…

> Their complaints about borrow checking rules at the interop layer ring hollow to me.

It's actually a big problem. There's a whole lot of Rust library API's that are only provided with an idiomatic "safe" interface, but this actually imposes stronger, more demanding preconditions on those API calls than are warranted by the actual code, which could easily work with e.g. raw (possibly aliased) pointers, or owned-but-pinned (non-movable) data. This creates unneeded pitfalls in Rust-C/C++ interop. The counterargument is that future versions of that library code might benefit from those stronger preconditions, but that's more of a theoretical point, it just doesn't apply in most cases.

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

#308

Post by chandlerc1024 »

Erlangen wrote: post #103

Its github repo has a very interesting doc on when it's the right time for Carbon language to go public. https://github.com/carbon-language/carbon-lang/commit/b8750e... > Broader field experience required > Sustained interest to use Carbon from multiple organizations and individuals > Prototype implementation > Demonstration of potential > Learning material > Prepare for new contributions and feedback > Launch event…

It was made public at CppNorth, a C++ conference, earlier today. The page you mention is a bit out of date though, you can find the update to our plans here: https://github.com/carbon-language/carbon-lang/commit/4aa462...

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

#309

Post by jb1991 »

Jensson wrote: post #298
pjmlp wrote: post #291

Earlier quoted context omitted.

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.

> then my program is now running with 10 GC's each trying to optimize itself

Is this true with Java? I thought it's a single runtime that manages memory in all the code/libraries in your process.

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

#310

Post by kzrdude »

notriddle wrote: post #63
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…

It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first. As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the…

There is a lot of Rust in the Carbon syntax.

`fn`, `name: Type`, `i32`, `->` for return type. `impl` as a keyword. `Self` as a keyword.

Nothing unique to Rust, but it's interesting to see.

Post reply on HN