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

451–460 of 521 posts

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

#451

Post by mrits »

kllrnohj wrote: post #367
mrits wrote: post #75

Earlier quoted context omitted.

Designing a language to interop well with a single language is short sighted in my opinion. I want a clean ffi that I know will be able to iterop with Swift, Typescript, C#, C++, C, python etc... In my current project I'm currently using Rust/protobuff to do all of this and it rarely gets in my way of how I want to do things.

It's funny you list typescript there given typescript itself is a language designed entirely around interop with a single other language. Kotlin is another such widely liked language that was designed entirely around interop with a different language.

Kotlin took an entirely different approach, one that I agree with. It can easily interact with dozens of other languages because of it.

Typescript is a superset of javascript and intentionally short sighted to fill a current need.

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

#453

Post by skl131313 »

WalterBright wrote: post #417
dymk wrote: post #399

Earlier quoted context omitted.

@nogc is fine, if you're okay with not being able to use large swaths of the standard library, and by extension, most popular D libraries.

Not much of the library is dependent on the GC. For example, only one of the algorithms is.

There's no "nogc" containers in phobos, or allocators, or an idiomatic way to do safe manual memory management. It expects you to do it the C way. It's also impossible to implement some things because of how D does moving. There's a DIP in the works to change how moving works, but it's overly complicated and bound to introduce even more bugs. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md

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

#454

Post by skl131313 »

mhh__ wrote: post #403
dymk wrote: post #400

Earlier quoted context omitted.

Probably not, or they'd just be written in Java.

There is more to performance than allocating memory. In fact some very performance-centric codebases do use a GC like unreal engine. On the subject of games it always makes me chuckle when I see people complaining about garbage collection but then having 20 calls to malloc in their hot loop. All memory allocation is slow and not necessarily bounded. I have written code that uses SoA, cache aware metaprogramming, inli…

I love when people bring up that UE has a GC, if it was written in Java, do you think they would have built a GC on top of Java's GC?

I guess it depends on the GC at that point, 20 mallocs isn't a lot but like the GC in D, it pauses all threads to do it's collection when you allocate. There's also a few games that use C# that have a really bad stutter because of the GC. There's nothing they can do about that though.

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

#455

Post by CuriousCosmic »

kllrnohj wrote: post #66
yakubin wrote: post #7

Earlier quoted context omitted.

It's std::vector that was weirdly named. In plenty of codebases "Vector", particularly gamedev and scientific, will mean the mathematical object with that name. Other languages don't need to replicate this mistake.

Java's Vector looks around awkwardly, hoping everyone forgets it existed... ;)

With the new versions of the JDK I think they will.

The Java Vector features will be out of incubator in the next year or so and unlike the existing Vector, it's actually useful. For context the new vector features are for SIMD support on the JVM.

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

#456

Post by skl131313 »

WalterBright wrote: post #198
cogman10 wrote: post #21

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 doesn't do it very well. Carbon doesn't require you to write your own interface. There's also problems with extern(C++) not correctly generating the appropriate assembly. Lots of ABI bugs as it's rolling it's own implementation instead of using LLVM.

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

#457

Post by vintagedave »

kinjalkishor wrote: post #273
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.

I am still a big fan of both dlang & pascal & very hopeful of dlang's Bright future ahead.

+1 to Pascal here! Underrated language.

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

#458

Post by mhh__ »

dataangel wrote: post #450
mhh__ wrote: post #403

Earlier quoted context omitted.

There is more to performance than allocating memory. In fact some very performance-centric codebases do use a GC like unreal engine. On the subject of games it always makes me chuckle when I see people complaining about garbage collection but then having 20 calls to malloc in their hot loop. All memory allocation is slow and not necessarily bounded. I have written code that uses SoA, cache aware metaprogramming, inli…

Unreal Engine mostly uses GC for game world objects. Only C++ classes that inherit from a special base class and opt-in are subject to GC. If they used GC for everything the performance would be much worse.

Sure, but I'm saying that most C++ code in the wild is probably firmly in the former category.

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

#459

Post by reindeerer »

mkoubaa wrote: post #341
saagarjha wrote: post #109

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

I work at smaller scale c++ than google and I found most of their proposals reasonable but undoable for practical reasons rather than first principles reasons. For instance compiler vendors who have a veto power over language changes strongly prefer not breaking ABI. ABI changes are fine if you build the world at every commit, but also if you don't have legacy. C++ users 200 years from now would most likely benefit f…

ABI with a clear major version number would solve this. It's what C++11 should have done with CoW strings.

You just ship 2 version compiled targets of std libs

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

#460

Post by [deleted] »

adev_ wrote: post #361
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 and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memt…

[deleted]
Post reply on HN