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

311–320 of 521 posts

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

#311

Post by arinlen »

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's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/, why wouldn't it be possible from D ?

You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does not address OP's point.

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

#312

Post by fluoridation »

xigoi wrote: post #287
fluoridation wrote: post #258

Earlier quoted context omitted.

It depends on how you define addition.

I guess you could make it a vector space through a bijection with the rational numbers, but something tells me C++ programmers don't have that in mind when writing std::vector . And it doesn't solve the problem that C++ “vectors” are resizable.

See my comment above on the subject.

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

#313

Post by detaro »

arinlen wrote: post #311
jcelerier wrote: post #266

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) 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's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/ , why wouldn't it be possible from D ? You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does no…

No, you are misunderstanding their point. If the problem of using Qt from D is that you need the MOC, then the fact that you can work around the need for MOC and use Qt without it seems quite relevant?

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

#314

Post by Jensson »

jb1991 wrote: post #309
Jensson wrote: post #298

Earlier quoted context omitted.

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.

For java the virtual machine provides the GC for everything, but then you can only use JVM libraries and not libraries in other languages.

The reason C and C++ libraries can easily be included in basically any other language is that they don't have a GC, so there are no such issues, just call the functions and things works fine.

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

#315

Post by jb1991 »

Jensson wrote: post #314
jb1991 wrote: post #309

Earlier quoted context omitted.

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

For java the virtual machine provides the GC for everything, but then you can only use JVM libraries and not libraries in other languages. The reason C and C++ libraries can easily be included in basically any other language is that they don't have a GC, so there are no such issues, just call the functions and things works fine.

> Major problem with GC languages is that it is horribly to link against libraries that ships with a GC.

I'm curious which GC languages do this. The most popular ones that come to mind for me are anything on the JVM, JS, and Go, and I've never heard anyone point this out about them.

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

#316

Post by germandiago »

saagarjha wrote: post #218
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...

Google can have many reasons why they do something. Not all of them will always be listed publicly, or even be written down :)

True for sure. This made me laugh. Lol.

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

#317

Post by mtlmtlmtlmtl »

slingnow wrote: post #301
mtlmtlmtlmtl wrote: post #278

Earlier quoted context omitted.

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

I think looking only at the number of dev jobs leaves too many potential confounding factors to be useful. For instance, how many C/C++ jobs are actually companies who need those devs to move away from C/C++? What's the overlap? How much of the C/C++ share is maintaining legacy code vs starting new projects? Sure the data says something about it, can we draw any conclusions from it other than precisely the numbers you listed? Not really, not without more detailed data.

One thing I would welcome is specifically looking at new sysdev projects over time and what languages they're in.

To be clear I'm not taking a view on whether Rust will become the standard. I really don't know, and I've yet to see anything convincing me one way or the other.

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

#318

Post by stusmall »

rvz wrote: post #49
bestouff wrote: post #41

Earlier quoted context omitted.

I'm as tired as you by these cosmetic successors. But for my part I think C++ has already been replaced, and to great benefits. I couldn't thank the people building Rust enough.

I still haven't seen a cross-platform production level GUI app written in Rust. All the time, it is C++ these companies use for these apps, especially having millions of users and generating multi-millions or hundreds of millions of dollars.

Here is one example: https://serokell.io/blog/rust-in-production-1password

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

#319

Post by throwaway17_17 »

JonChesterfield wrote: post #264
AndruLuvisi wrote: post #102

Why do so many new and improved languages still lack tail calls?

It's moderately annoying to implement because it messes with the calling convention in architecture dependent ways. So it isn't an IR transform, it's N lowerings for N architectures. Clang and llvm understand them, and you can require them from the front end, but the cost is some backends will hard error on them as unimplemented.

Just to clarify, are you saying that a language’s calling convention is implemented differently per architecture? Or is it that the tail call implementation needs to be implemented in different ways per architecture and that would mess with the required calling convention?

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

#320

Post by kinjalkishor »

WalterBright wrote: post #296
kinjalkishor wrote: post #272

Earlier quoted context omitted.

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.

Yes it is very useful addition. Hopefully stdlib will also be fully nogc soon. Of all available options I am most hopeful of dlang. While it doesn't still have taken off it still is improving a lot & has high chances of increased usage. (Python also took years).
Post reply on HN