[HN Gopher] Will Carbon Replace C++?
___________________________________________________________________
Will Carbon Replace C++?
Author : redbell
Score : 54 points
Date : 2023-02-27 15:04 UTC (7 hours ago)
(HTM) web link (semaphoreci.com)
(TXT) w3m dump (semaphoreci.com)
| pjmlp wrote:
| They keep pointing out Typescript and Kotlin, without
| understanding that the first only adds type declarations, while
| the second fakes to be Java at the JVM bytecode level (try javap
| on a .class generated by kotlinc).
|
| If Carbon ever goes beyond an experiment it will be for Google's
| own internal purposes.
| sdkgames wrote:
| >without understanding that the first only adds type
| declarations
|
| https://www.typescriptlang.org/docs/handbook/enums.html
| pjmlp wrote:
| Not forever if this ever comes through,
|
| https://github.com/Jack-Works/proposal-enum
| iudqnolq wrote:
| Barely https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=1
| 2&pc=4...
| bradhe wrote:
| No. Next question, please?
| andrewstuart wrote:
| Why would it use let to define a const?
| synergy20 wrote:
| Help improving c++ first please.
|
| then create a profile for whatever Google needs instead.
|
| and also please create a C profile off C++ that is safer than C,
| and make C a true subset instead of diverging them even further.
| steveklabnik wrote:
| Carbon was seemingly borne out of Google's frustrations that
| they could not get the C++ committee to agree with their
| desired improvements and direction for the future.
|
| That is, they've already been doing what you ask. Yet here we
| are.
| SleepyMyroslav wrote:
| Low effort take from gamedev: to start talking about replacing
| anything Carbon needs to start presenting 'solutions'. The only
| thing they presented so far is their inability to work with
| others.
| dmead wrote:
| No
| [deleted]
| ape4 wrote:
| Maybe there are too many (C++)++ languages? So its too hard to
| pick a winner.
| vasilipupkin wrote:
| why does every attempt to replace C++ make syntax of the new
| language significantly uglier than C++?
|
| why do I need to type "let" and "fn", etc?
|
| why not make the syntax very similar if you actually want to make
| it easy to migrate?
| audunw wrote:
| It's somewhat related to solving one of C/C++'s real problems:
| the syntax is very context sensitive. That makes tool
| development harder.
|
| Personally I think it's great that most new languages seem to
| move in roughly the same direction when it comes to syntax..
| like
|
| "x: int" instead of "int x" for variable declaration, and
| something similar on functions "fn", "fun" or "function" prefix
| before functions "let"/"const" for constants and/or single
| assignment variables "var" for variables etc.
|
| I think there's a reason so many language designers are making
| similar decisions on these things.
| vasilipupkin wrote:
| why is this great? what's the reason? x: int is significantly
| less readable than int x and involves typing one more
| character. Why?
|
| what is the advantage of type int fn foo versus int foo() {}
| ?
|
| why type var in front of a variable when int x makes it clear
| its a variable?
| kps wrote:
| Even C can't be parsed purely syntactically; you need to
| know whether or not an identifier names a type. C++ is
| worse: https://en.wikipedia.org/wiki/Most_vexing_parse
| vasilipupkin wrote:
| right, so some simplifications or improvements are fine,
| but it doesn't follow that we should now have to type
| var, let or fn everywhere - it just makes the body of
| code a lot uglier
|
| auto time_keeper = TimeKeeper(Timer());
|
| this is nice and clean
| Koshkin wrote:
| Copy constructor much?
|
| (Also, I would take var over auto any day, to be honest;
| but no, they _had to_ override the old useless keyword
| for some mysterious reason.)
| steveklabnik wrote:
| "Significantly less readable" is subjective.
|
| It is simpler to parse, and degrades better with type
| inference. That's 90% of it, I'd imagine.
| vasilipupkin wrote:
| sure, well, it's not subjective if you have to type more
| characters to basically achieve the same thing. I guess I
| just don't really understand why you have to fix C++
| shortcomings while also changing things that work fine.
| Is there a C++ developer who is having trouble declaring
| variables as int x?
|
| By making big changes to syntax, you are just making it
| less likely this ever gets truly adopted.
| runevault wrote:
| A language with good type inference lets you type less
| because you don't need the colon or the type, where as a
| language with it first you always have to type something
| like var for a "figure it out" type.
| aardvark179 wrote:
| Simple types may be easier, complex types are a real pain
| for both humans and compilers, and they end up hiding the
| name in the middle of the thing. Brevity is neither the
| only nor most important thing on which to judge syntax.
| nayuki wrote:
| It sounds like you are not familiar with the most vexing
| parse. https://en.wikipedia.org/wiki/Most_vexing_parse ,
| https://stackoverflow.com/questions/14077608/what-is-the-
| pur...
|
| Also pointer/multiplication ambiguity:
| https://medium.com/@bartobri/exploring-the-ambiguous-
| nature-... , https://softwareengineering.stackexchange.com/
| questions/1245... ,
| https://stackoverflow.com/questions/41331871/how-c-c-
| parser-...
| pjmlp wrote:
| Not every, see Circle.
|
| The only that really has a chance.
| pornel wrote:
| In the context of a language that needs to coexist with C++
| codebases, it is a weird decision.
|
| However, Carbon's syntax makes technical sense, and is in line
| with many contemporary languages (Rust, TypeScript, Swift,
| Kotlin). It is easier to parse, which is important for tooling
| and IDEs. `fn name` is easy to grep for. `let` works well with
| type inference and destructuring assignment, which are becoming
| standard features in modern languages (although Carbon still
| supports C-style aggregate initializers, which is not so
| great).
| [deleted]
| v3ss0n wrote:
| It was never heard after announcement. Really doubt anyone need
| it .
| SoylentOrange wrote:
| There are many well known problems with C++, not least of which
| are the long compile times, exception handling, and dependency
| handling. Anyone who has worked with a sufficiently large C++
| code base has run into these issues.
|
| The overwhelmingly negative comments here on HN remind me of
| the pushback that Rust Linux kernel modules received on HN when
| they were first announced around 2015/2016. Now they're seen a
| much loved feature (I understand they solve different problems
| so the analogy isn't perfect). I'm not confident that Carbon
| can be used to solve the issues that arise in large C++
| projects as I've never tried it but that's very different from
| pretending C++ is some kind of perfect language that doesn't
| have these flaws and doesn't need fixing.
| TheRealPomax wrote:
| The article is about creating a potential successor to C++ in the
| same way JavaScript lead to TypeScript, or Java lead to Kotlin,
| or C lead to C++, and in giving those examples immediately
| undermining its own thought because none of those _replaced_ the
| thing they came out of. Heck looking at whose still writing new
| code bases in what, C++ didn 't even replace C, and Swift didn't
| replace Objective C. C++ and Switft just became "more dominant".
|
| So based on the article's own observation: no, of course not. The
| more interesting question is "will it stand on its own?" to which
| the answer is "only if it actually solves so many problems with
| the thing it's trying to supplant that it makes sense to give it
| a serious try".
|
| And C++ just... doesn't have that many real problems. It has a
| lot of irks, but the problems people run into are problems that
| others already solved, a thousand times, over the last half
| century, in many different ways for many different iterations of
| the language.
|
| Pretending you can replace C++ is like pretending you can replace
| cars. Not just "create EVs" but straight up replace cars. Good
| luck, you won't succeed if that's your goal, so hopefully you
| realise you need to focus on making a decent language that some
| folks might consider using instead of C++ for some of their work,
| instead of creating "the successor to C++".
| credit_guy wrote:
| > And C++ just... doesn't have that many real problems.
|
| It does not have many, but it has one and it's big. It's not
| memory safe.
|
| Check out this talk by Herb Sutter, around minute 43:
| This is the first time a government [see note] has actually
| issued guidance to industry broadly that was the barest
| paraphrase away from "where possible don't use C and C++"
|
| [ Note: in this context, the "government" is the US Department
| of Commerce and NIST, which, according to Herb, have issued a
| detailed guidance in response to the Executive Order on
| Cybersecurity [2]. While I couldn't find that guidance, I found
| one by the NSA [3], which saw quite a few comments here on HN
| in December last year [4] ].
|
| [1] https://www.youtube.com/watch?v=ELeZAKCN4tY
|
| [2] https://www.whitehouse.gov/briefing-room/presidential-
| action...
|
| [3]
| https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
|
| [4] https://news.ycombinator.com/item?id=33560227
| zik wrote:
| > It's not memory safe
|
| Modern C++ has made big inroads into removing memory safety
| issues though. Memory safety bugs are relatively uncommon in
| modern C++ compared to pre C++11 times.
|
| You could argue that C++ is still "unsafe by default" and
| you'd be right. But most C++ programmers use smart pointers
| and unique pointers rather than raw pointers now, vectors
| instead of raw arrays, etc.. And it does make a big
| difference.
| s9w wrote:
| [dead]
| hulitu wrote:
| > or C lead to C++,
|
| As "Unix haters handbook" says: C++ is to C, what lung cancer
| is to lung.
| pjmlp wrote:
| I love how it ignores that C++ was developed on the same
| place, even on the same corridor as C and UNIX devs used to
| work.
| TheRealPomax wrote:
| A profoundly idiotic statement, but on-brand for that
| manifesto.
| RcouF1uZ4gsC wrote:
| > As "Unix haters handbook" says
|
| As they compile their C code using a compiler written in C++.
| (GCC and Clang are both written in C++).
| jcranmer wrote:
| To be fair, that wasn't true when the Unix haters handbook
| was written, almost 30 years ago.
| pjmlp wrote:
| Nonetheless it was true that C++, C and UNIX share the
| same birthplace.
| guestbest wrote:
| If a language helps a developer create a solution, it is
| fundamentally not a cancer.
| xiaq wrote:
| Your definition of "replace" is too strict: the idea of a
| successor language is not replacing all existing code, but
| rather making it possible for individual projects to painlessly
| evolve from the old language to a new one. Some old code -
| whether entire inactive projects or inactive parts of active
| projects - may never get rewritten in the new language and that
| is OK.
| pizza234 wrote:
| > And C++ just... doesn't have that many real problems.
|
| From Carbon's README:
|
| > C++ [...] is struggling to improve and meet developers'
| needs, as outlined above, in no small part due to accumulating
| decades of technical debt. Incrementally improving C++ is
| extremely difficult, both due to the technical debt itself and
| challenges with its evolution process. The best way to address
| these problems is to avoid inheriting the legacy of C or C++
| directly, and instead start with solid language foundations
| like modern generics system, modular code organization, and
| consistent, simple syntax.
| dralley wrote:
| The question is not whether C++ has issues, it's whether the
| rest of the ecosystem cares about them as much as the Carbon
| devs, enough so that they would adopt Carbon instead of C++.
|
| Carbon will face the same issue as Dlang. Everyone agrees
| that Dlang is an improvement over C++ in many significant
| aspects, and a very impressive one at that, but in order to
| gain meaningful adoption the benefit has to be high enough to
| justify the pain of swimming upstream against the rest of the
| ecosystem. D never quite made it above that threshold, though
| perhaps in an alternate history where Google picked it up
| instead of pushing Go, it could have.
| pornel wrote:
| D has two problems:
|
| 1. Being "C++ but nicer" is an awkward niche. It's not
| differentiated enough to overcome switching costs for C++
| users. It's hard to justify risks of a new language, costs
| of hiring and/or code rewrites just for quality of life
| improvements.
|
| At the same time being similar to C++ is a turn off for
| users who don't like C++ and look for something different.
|
| 2. D with a GC is not really competing with C++ in its core
| niche where C++ is irreplaceable, but rather with many many
| other GC languages for programs that can use almost any
| language. The idea of GC being optional is a hard sell,
| because it's an obvious switcheroo -- without the GC you
| don't get all of the nice features, so GC-less D is even
| less differentiated from C++.
|
| Carbon at least avoids the second problem. I'm not sure if
| Carbon's new syntax and semantic tweaks are different
| enough.
| TinkersW wrote:
| None of those are 'issues' for me. The language isn't perfect
| but the Carbon approach seems to not solve any meaningful
| issues.
| [deleted]
| ActorNightly wrote:
| The problem is that people take for granted that [insert code
| organization method here] is good and lack of it in another
| language is bad. This is a rehash of the conversation between
| Java and C++ proponents about the correct way to do multiple
| inheritance.
|
| In practice, none of this really matters. For example,
| generics are just one way to do code organization, you can
| write codebases that are clear, maintainable, and reliable,
| without ever touching generics once.
| IshKebab wrote:
| Your threshold for "replace" is too high. Did cars not replace
| horses because horses still exist?
| kalcode wrote:
| > So based on the article's own observation: no, of course not.
|
| This had very little to the discussion. Of course it can't be
| replaced. Code is created by humans, and as long as we have
| opinions nothing gets truly replaced. Just decreased usage over
| time.
|
| > C++ and Switft just became "more dominant".
|
| Yup, like this. Of course a general statement is no.
|
| I have very little interest in this topic. But I seen this SAME
| comment a million times on anything thats new that attempts to
| challenge something. And as usual whether something "dethrones"
| something is less interesting than what changes or ideas that
| it offers.
|
| Just like ALL those you listed, they didn't replace any of
| those, but they definitely challenged the ecosystems, or
| improved the old ones.
|
| Naunce discussion is far more interesting.
|
| For example, why do you think Carbon won't be able to gain
| dominance over time? I mean I think thats a huge hurdle too.
| TheRealPomax wrote:
| You've apparently read the reverse of what I said. I said the
| new thing didn't replace the old thing, and that therefore
| the idea that "we are doing the same, and it will replace the
| old thing" is nonsense. I did _not_ say that because it can
| 't replace it, it is therefore not worth doing. It absolutely
| is, like all attempts at making things that "solve the
| problems that C++ has" have been varying degrees of worth it.
| But the idea that it can, let alone will, _replace_ the
| original is such an obvious "no" that the title is
| clickbait. Or slide-bait (since it was originally a conf.
| talk)
| jameswryan wrote:
| > And C++ just... doesn't have that many real problems.
|
| 70% of security bugs are memory safety issues. That's a lot of
| real problems.
|
| > It has a lot of irks, but the problems people run into are
| problems that others already solved, a thousand times, over the
| last half century, in many different ways for many different
| iterations of the language.
|
| People run into memory safety issues more often in new C++
| code.
|
| https://www.chromium.org/Home/chromium-security/memory-safet...
|
| https://security.googleblog.com/2021/09/an-update-on-memory-...
|
| https://github.com/microsoft/MSRC-Security-Research/blob/mas...
|
| https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
|
| https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20pre...
|
| https://advocacy.consumerreports.org/research/report-future-...
|
| https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
|
| https://github.com/google/sanitizers/blob/master/hwaddress-s...
|
| https://security.googleblog.com/2022/12/memory-safe-language...
| dxhdr wrote:
| > 70% of security bugs are memory safety issues. That's a lot
| of real problems.
|
| Run your code in a WASM sandbox or on a GPU, problem solved.
| adgjlsfhk1 wrote:
| "Run your code in a WASM sandbox" and then your C++ is way
| slower (and speed is the only reason you were using C++ in
| the first place)
| iudqnolq wrote:
| Unless you write software that processes input from one
| user while having data private to another user in memory.
| So ... quite a lot of software
| josefx wrote:
| Which is quite risky even with memory safe languages, if
| the big exploits in the last decades had anything to show
| it is that both RAM and CPU can be abused into bypassing
| any protections in place.
| treis wrote:
| >70% of security bugs are memory safety issues. That's a lot
| of real problems.
|
| Are these really real enough problems, though? If you're
| defending against state level attackers it's a problem. But
| how much do these really impact Joe Schmoe average computer
| user?
| throwaway894345 wrote:
| Of course, I agree that C++ isn't going to entirely disappear,
| but I don't understand what you mean by "C++ doesn't have many
| real problems, only irks". Surely the lack of memory safety is
| more than a mere irk--certainly Mozilla felt strongly enough to
| develop an entirely new programming language (as did Carbon's
| developers), and of course entire domains have moved away from
| C++ entirely (often in favor of GC languages). Yes, there
| remains some contingent of people for whom things like
| "deterministic memory management" or "immaturity for $domain"
| are bigger problems than those presented by C++, but that
| doesn't mean that C++ is without real problems, right?
| JustBreath wrote:
| Betteridge's law holds up as usual.
| TheRealPomax wrote:
| It'd be quite nice if HN automatically flagged that to
| submitters. "Please rewrite this title to describe the
| article, as it is currently a question and the answer is no".
| andrewstuart wrote:
| If the idea is to retain the modern features, focus attention on
| them and peel off all the superseded old stuff then I'm all for
| it.
|
| Seems to me languages that focus on backward compatibility end up
| with a great modern core but it kinda gets lost because how do
| you know that the modern core? Developers learning can't know
| what's new and best and recognize what's old noise.
|
| It has to be said though that googles reputation for killing
| projects overshadows anything they do.
| andsoitis wrote:
| The core hypothesis is that for a replacement language to be
| successful, it cannot only be great for new projects. Besides
| building on and extending tooling already in wide usage, you want
| the successor language to interplay elegantly with existing code,
| affording things like gradual replacement. Of course, that also
| means that you're making less of a leap, but considering the vast
| landscape of active C++ code based, I would put my money behind
| this _successor_ language argument.
| asow92 wrote:
| > Dart is a language on top of JavaScript
|
| Isn't Dart a compiled language that can be compiled to JS via
| dart2js and not "on top of JavaScript"?
| giancarlostoro wrote:
| Originally it was built on top of v8 itself if I'm not
| mistaekn, so the author might be referencing some historical
| knowledge that has kind of changed.
| mraleph wrote:
| > it was built on top of v8
|
| Was never built on top of V8 in any shape of form. Dart VM
| does not even share any code with V8.
|
| Dart 1 was designed by people who originally started V8 (Lars
| Bak and Kasper Lund), that's the only connection.
| synergy20 wrote:
| yes, Dart has little to do with JS now, it's made for Flutter
| for the most part nowadays, and it is great.
| doodlesdev wrote:
| Yes, at first it reminds me a bit of Haxe [0], which compiles
| to a multitude of languages. Originally it was made to
| "replace" JavaScript, there's Angular Dart for instance as an
| example of what that would work like. But nowadays Dart can
| compile to JavaScript or "Dart Native" [2] which instead of
| Haxe reminds much more of Java or C# since it runs inside a VM
| in JIT mode.
|
| It can run on ARM32, ARM64 and x84_64 natively as machine code
| through the Dart runtime when compiled AOT and performance is
| of course much better than compiling to JavaScript so you can
| see why it's a really interesting option for the development of
| Flutter which targets web, desktop, and mobile. You write the
| code once and get to have JIT for development with hot
| reloading, debugging and live metrics, and AOT compilation for
| your desktop and mobile targets while also getting a JavaScript
| bundle for your web target.
|
| [0]: https://haxe.org/
|
| [1]: https://github.com/angulardart
|
| [2]: https://dart.dev/overview#platform
| danpalmer wrote:
| No.
|
| Carbon is an experiment to solve Google's challenges with C++,
| which look very different to, say, the challenges of the games
| industry or those of embedded software development. C++ is widely
| used enough that it would take decades of sustained development
| specifically targeting replacing it across all the areas it is
| used to make a dent.
| nine_k wrote:
| Indeed. C++ will be displaced (not replaced) by the usual
| suspects: Rust, Zig, Golang, maybe even niche languages like
| Nim in certain areas, where C++ used to be the only sane
| choice.
|
| It's a bit like Fortran has been displaced by C, C++, Julia,
| even Python (with Numpy / Scipy) from the realm of numeric code
| where it used to reign supreme. It does not mean that important
| Fortran code does not exist any more, or even that new Fortran
| code is not written every day. It just means that Fortran is no
| longer dominant, and in many areas is definitely not the first
| choice.
|
| Same is happening to C++.
| [deleted]
| staunton wrote:
| There is nothing to replace here. You should only start a new
| project in C++ if you absolutely have to, and if you really have
| to, perhaps due to legacy code, then complicating your smoldering
| dumpsterfire of a build system even more with this stuff is
| masochistic at best. Meanwhile, that dumpsterfire will burn on
| for maybe a century and people will have to keep "learning" C++.
| The only way to make this situation less painful is to finally
| stop trying to incorporate into C++ every new language that comes
| out.
| klodolph wrote:
| The main selling point of Carbon is direct C++ interop, which
| is extremely rare and makes Carbon unique.
| usrusr wrote:
| The other big selling point is "developer interop". If you
| work on a stack that is locked to c++ (interop) and need to
| get developers productive who grew up with the go, rust,
| kotlin generation of languages, carbon looks extremely
| promising compared to trying to force-feed them forty years
| of c++ quirks.
| guitarbill wrote:
| Sadly, if it's interoperable with C++, you'll likely need
| to know forty years of C++ quirks at some point...
|
| It all just seems like a band-aid (adhesive plaster for
| non-native speakers).
|
| I wonder if having a stable ABI wouldn't be better.
| Specifically the CXX project shows how this kind of
| capability is extremely powerful.
| usrusr wrote:
| Not really, not when the carbon-only team can throw
| things back over the wall to the legacy experts who
| promised proper interop. And that the new devs aren't
| even _tempted_ to solve it on their own, which would
| inevitably happen if instead of carbon they 'd try to
| achieve the same by sticking to some modern subset of
| c++. With carbon, the new generation who don't know
| better don't have to be painstakingly supervised to not
| use any bad subsets of those "~4 languages". Saving the
| man-hours that would otherwise be spent on arguing about
| the exact composition of that subset would likely be
| enough to make the switch worthwhile (yeah, I might be
| projecting, I'd get nothing done at all)
| staunton wrote:
| Yes. I believe that doesn't affect my argument. Instead of
| the ~4 programing languages found within C++20 you would be
| adding one more to the codebase. Does that sound like a good
| idea?
|
| Maybe my comment was too harsh. It's great someone's trying
| to make the C++ situation better. I hope they succeed. I just
| think they won't and C++ should go the way of C and stop
| "evolving", while this thing is very similar in spirit to
| blowing it up even further. (I've actually liked working with
| C++ for the past 15 years, but not because it's productive
| but for the stockholmy "challenge" of it)
| usrusr wrote:
| Being no expert at c++ (far from it..) and knowing nothing
| about carbon I'd expect that you'd usually need to do at
| least _some_ cleanup amongst those "~4 languages" (nice
| way to put it!) on the c++ side before enjoying interop.
|
| But I'd also assume that much (all?) of that cleanup would
| be stuff that would be worth doing anyways, even if you
| sticked to c++, but that you keep postponing...
| staunton wrote:
| The issue is that it's very hard to "clean C++ up"
| because backwards compatibility must be upheld (there are
| obviously good reasons for that). C and C++ have terrible
| defaults that mostly cannot be changed anymore. You can
| try to add warnings for everything (people dislike and
| disable them), static analysis, valgrind, (not trivial to
| set up and use correctly) etc. etc. You can add new stuff
| (e.g. smart pointers) and mandate (e.g. C++ core
| guidelines) that the old ways (new/delete) should not be
| used. I could continue forever describing measures aimed
| at making C++ safer.
|
| In my opinion all these things have failed. The language
| is old, has insane amounts of legacy beurocracy and
| process tied to it, has terrible unchangeable defaults,
| unchangeable ABI, and is insanely complicated to "get
| right" (write a function that adds two signed integers
| and returns the result, that _has no undefined behavior_
| ) to the point where there is an established tradition
| _not to try_ to get it right. Yes, smart pointers are
| nice, concepts are also nice, but this patchwork does not
| work well with other features, and what this
| "improvement" process does is make it more complicated.
| Almost noone really understands it anymore.
|
| It's time to retire it and start over completely, as well
| as reconsider if all the things that C++ has been
| traditionally used for warrant such a language. Things
| like GC languages or Rust/Zig should fill that space.
| They have decent interop where needed. Meanwhile C++ is
| not going away for a very long time. I see this project
| as building another language into C++ that makes it even
| more complicated.
| usrusr wrote:
| Yes, c++ (the language) can't be properly cleaned up
| because support for not just some but all legacy
| codebases isn't optional at all. But I wasn't talking
| about cleaning up c++, the language, I was talking about
| cleaning up c++ codebases to align them with whatever
| subset of c++ that will play nice with carbon. Surely
| won't be everything, whatever obscure leftover from 1984
| you dig up, but will likely aling well with good somewhat
| modern (or modernized) codebases. That would mean ending
| up with code that cleanup process will likely end up
| restricting itself to a certain subset of c++ that might
| in fact be a good candidate for a "somewhat cleaned up
| c++ language", but I agree, that wouldn't be worth it: a
| properly different thing designed for interoperability
| with a large subset of c++ will be much easier to learn
| than a literal subset.
| vips7L wrote:
| Can't D interop with C++?
| TheRealPomax wrote:
| https://xkcd.com/927
| zwieback wrote:
| If you add "... in field [x] or application space [y]" to the
| question it might lead to a useful discussion but as-is the
| question is too broad.
| taraharris wrote:
| Has anyone else looked at Herb Sutter's cpp2?
|
| For those that don't use C++, Herb is chair of the ISO C++
| standards committee, and holds the position of "native languages
| architect" at Microsoft.
|
| https://twitter.com/herbsutter/status/1609307537261617154
|
| This is a good introductory talk on cpp2 by Sutter at CppCon
| three months ago, where he demonstrates _cppfront_ , the cpp2 ->
| C++ transpiler. One of the things I like about it is that the
| code it generates is human-readable and fully backwards-
| compatible with C++. If you use cpp2 in your project and end up
| not liking it, you still have the same (very reasonable) C++ code
| that you'd write by hand today if you followed the guidelines
| you're supposed to already.
|
| https://www.youtube.com/watch?v=ELeZAKCN4tY
|
| I think this is very promising, and I'm interested in using it my
| next project. We don't need a total replacement for C++, we just
| need to let out the awesome language that's always been hiding
| inside it.
| pjmlp wrote:
| Yeah, he tries to sell cpp2 as being different to the other
| alternatives, due to his position at ISO, however it is just
| the same thing being an alternative language, compiling via C++
| translation doesn't change that.
| taraharris wrote:
| The thing I like about it is that it is the easiest thing to
| switch to. It provides the path of least resistance for my
| existing workflows, and that alone is reason enough for cpp2
| to win.
| pjmlp wrote:
| That would be Circle, not a language with another syntax.
| lanza wrote:
| He didn't staff a team of compiler engineers to do it. Doesn't
| matter how good it is when mature languages that reach the
| mainstream all have compilers funded by 10 people at a tech
| giant and cppfront is just Sutter screwing around in his free
| time.
|
| Google threw the weight of their top C++ engineers behind
| Carbon. It's happening. That's really what matters in the world
| of programming languages. Not how good it is.
| taraharris wrote:
| Just watch what happens to Google and their ad revenues in
| this downturn, by the way. I knew people that were hyping
| Fuschia, and then Google cut deepest from that on their first
| round of layoffs. It wouldn't be a shock to me if they yank
| out the carpet from this Carbon thing one day, or have it
| limp along like Dart.
|
| In summary, Google can do what it wants, but I'll just keep
| using C++ no matter what it does. I spend all my time in and
| on HaikuOS now, so for me C++ here here to stay :)
| pjmlp wrote:
| Fuschia is shipping on Nest devices though.
| pornel wrote:
| It's on a device that is unimportant to Google, and it's
| just an implementation detail. Fuschia could disappear
| entirely in one software update, or with cancellation of
| the Nest product line.
|
| I like the ideas Fuschia is trying to implement, but
| unfortunately it still looks like a small experiment with
| an uncertain future.
| pjmlp wrote:
| Even if it dies tomorrow, it already achieved more than
| many wannabe OS out there, so there is that.
|
| And who knows, just like it happened with Singularity and
| Midori having an impact on .NET design since WinRT, some
| Fuchsia ideas can be brought into Android in that case.
| [deleted]
| matt3210 wrote:
| The next step in software is a language optimized for ai
| generation. Rust and carbon are for humans and are a side step at
| best
| Borg3 wrote:
| I love such comments. Humans got here because they are able to
| solve abstract problems and analitical thinking. Go ahead and
| pass it all to AI. Whats left? An useless consumer... (go go
| Skynet :)
| jcranmer wrote:
| I suppose Betteridge's Law of Headlines provides the answer, but
| the article doesn't even do a great job of attempting to answer
| the question.
| deagle50 wrote:
| Low effort TL;DR of the CppNorth presentation to drive traffic to
| a commercial site.
___________________________________________________________________
(page generated 2023-02-27 23:01 UTC)