Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

Post reply on HN
Print view View original

131–140 of 200 posts

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

#131

Post by justcuriousab »

tialaramex wrote: post #127
justcuriousab wrote: post #124

Earlier quoted context omitted.

> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. But Rust allows pattern matching on floats. https://play.rust-lang.org/?version=stable&mode=debug&editio... Rust Zulip is C++ WG21 confirmed?

I'm sure you think this was somehow succinctly making your point, but I can't see any connection at all, so if you did have an actual point you're going to need to explain it.

Float matching in Rust is not supported due to correctness concerns, but due to historical accidents and backwards compatibility.

https://github.com/rust-lang/rust/issues/41620#issuecomment-...

https://github.com/rust-lang/rust/pull/84045#issuecomment-82...

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

#132

Post by cb321 »

miguel_martin wrote: post #84
cb321 wrote: post #52

Earlier quoted context omitted.

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily. Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been) "automatic vs. manual".

Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. { See, the subtitle or table of contents of Jones 1996 "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", for example. } Maybe you & I (or Nim's --mm?) can personally get the abbreviation "AMM" to catch on? I doubt it, but we can hope!! :) Sometimes I think I should try more. Other times I give up.

Before the late 90s, people would say "tracing GC" or "reference counting GC" and just "GC" for the general idea, but somehow early JavaVM GC's (and their imitators) were so annoying to so many that "The GC" came to usually refer, not just to the abstract idea of AMM, but to the specific, concrete separate tracing GC thread(s). It's a bit like if "hash table" had come to mean only a "separately chained linked list" variant because that's what you need for delete-in-the-middle-of-iterating like C++ STL wants and then only even the specific STL realization to boot { only luckily that didn't happen }.

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

#133

Post by cb321 »

chandlerc1024 wrote: post #108
cb321 wrote: post #52

Earlier quoted context omitted.

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

Source-to-source translation is definitely planned. We've even done some early experiments. But we need to get the language and interop into good shape to be able to thoroughly test and evaluate the migration.

I see. So, it's just a slide-ware bullet point right now? It would be helpful to really emphasize a word like "planned" in that bullet. It might have been lifted from some future-sounding/plan-oriented list and now the material makes it seem like it's actually available.

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

#134

Post by ncruces »

dazzawazza wrote: post #118
kjksf wrote: post #50

I think this page describes "what" but not "why" of Carbon. Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally. The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon. That's wha…

These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed. I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.

Then wait for Google to adopt it at large?

If it (purportedly?) exists so that Google can move multi-million line code bases from C++ to something better bit-by-bit, because it's otherwise infeasible to do so, why would Google drop it after they have ported the first million?

You can simply wait to see if Chrome adopts it.

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

#135

Post by volemo »

philwelch wrote: post #112
troad wrote: post #106

Earlier quoted context omitted.

I really struggle to imagine an organisation that shepherds a large and venerable C++ codebase migrating over to Swift. For all of C++'s faults, it is an extremely stable and vendor-independent language. The kind of organisation that's running on some C++ monolith from 1995 is not going to voluntarily let Apple become a massive business risk in return for marginally nicer DX. (Yes, Swift is OSS now, but Apple pays th…

Maybe not, but an Objective-C++ codebase might be a good candidate.

Do you have projects with huge code bases of Obj-C++ in mind?

I guess, some Mac apps? In that case I think most platform independent "guts" would be in C or C++, and the Obj-C++ part is tied to the frameworks, so the devs would have to rewrite it anyway.

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

#136

Post by justcuriousab »

omoikane wrote: post #97
kjksf wrote: post #50

I think this page describes "what" but not "why" of Carbon. Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally. The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon. That's wha…

> I think this page describes "what" but not "why" of Carbon. Maybe the page was updated recently, but there is a "why" link near the top: https://docs.carbon-lang.dev/#why-build-carbon What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any referenc…

Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

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

#137

Post by tialaramex »

cb321 wrote: post #132
miguel_martin wrote: post #84

Earlier quoted context omitted.

Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily. Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been ) "automatic vs. manual". Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. {…

The open addressed hash tables basically don't exist for a long time. The various strategies for collision handling in these tables are from the 1980s or later and if you don't have a collision strategy you can't use this as a general purpose container. I'm pretty sure I never used a hash table which didn't use separate chaining until at least the 1990s and perhaps later.

So that's maybe a bad example. In the same way I think it's fine that "Structured programming" is about the need to use structured control flow, not the much later idea of structured concurrency even though taken today you might say they both have equal claim to this word "structured".

In contrast it is weird that people decided somehow "Object oriented" means the features Java has, rather than most of what OO was actually about when it was invented. I instinctively want to blame Bjarne Stroustrup but can't think of any evidence.

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

#138

Post by justcuriousab »

chandlerc1024 wrote: post #108
cb321 wrote: post #52

Earlier quoted context omitted.

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

Source-to-source translation is definitely planned. We've even done some early experiments. But we need to get the language and interop into good shape to be able to thoroughly test and evaluate the migration.

I am trying to run Carbon in Godbolt.

Printing as in the example from Carbon's Github repository, does not work. 'Print("Test");' gives a complaint about not finding 'Print'.

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

#139

Post by imtringued »

This language changes too much and too little all at the same time. It creates a burden on the developers without lifting many of the burdens of C++.

I can imagine the thought process behind the designers of the language went as follows:

"It's not possible to improve C++ without breaking backwards compatibility"

"That's correct, but if we're going to break backwards compatibility anyways, why not use this as an opportunity to change a bunch of things?"

aka the python 3 mentality, where necessary changes were combined with unnecessary changes that caused pointless migration costs. The fallacy is derived from the fact that breaking backwards compatibility is considered a massive fixed cost due to the fact that libraries have to be updated, therefore adding small incremental costs will not meaningfully increase overall cost. In reality the fixed cost of breaking backwards compatibility can be reduced massively if the proper care is taken, which means all the "just because" changes that were thrown in as a bonus, end up representing a much larger share of the migration cost than initially anticipated.

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

#140

Post by TuxSH »

Ygg2 wrote: post #130
ygritte wrote: post #111

What's the pro of not having a stable ABI?

Being able to change things. It's like all downsides of backwards compatibility but on a binary level As to things ABI prevents: - scoped_lock was added to not break ABI by modifying lock_guard - int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated. - unique_ptr could fit in register with language modifications, which would be need…

> Making destructors implicitly virtual in polymorphic classes

Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics).

After all, an abstract base class does not need its destructor to be public.

Post reply on HN