What does HackerNews think of carbon-lang?
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
https://github.com/carbon-language/carbon-lang
https://compiler-explorer.com/ (pick Carbon)
Remote: Yes (only Remote)
Willing to relocate: No
Technologies: Rust, C++, C, Typescript, Linux, Nix
Résumé/CV: https://drive.google.com/file/d/1pGym37bYcIpii781pNC9HvjQe9n...
Email: [email protected]
I'm a student, and am looking for a job. I can join in June, 2024. I'm particularly interested in open source, system programming and associated software.
I am currently a Google Summer of Code contributor at the Carbon Language[0]. I'm a regular contributor to Fedimint[1]. I'm currently re-imagining the shell[2].
For more info, check out my GitHub at https://github.com/maan2003
[0]: https://github.com/carbon-language/carbon-lang
Rust is a famous example; there's also Carbon[1] and cppfront[2].
Even so, this may be a controversial opinion, but with C++20, it has become fairly straightforward to program relatively safely and avoid some old footguns.
Cpp_front and Carbon are not C++.
Parts of Cpp_front might become part of C++, but adding more stuff to C++ (usually increasing the overall complexity) has not been an issue for C++. That could be seen as part of the problem why C++ is so large and complex.
By way of comparison, Carbon calls itself: "fundamentally a successor language approach, rather than an attempt to incrementally evolve C++." (https://github.com/carbon-language/carbon-lang) It aims to be a successor to C++, not the evolution of C++.
>> Bjarne is quoted to have said that there is a smaller C++ inside the current C++.
To officially be C++, the Standards Committee must agree to deprecate the features that give a smaller C++ in a future release of the C++ Standard.
Good luck getting the C++ Standards Committee to agree on what to remove.
>> a clean reboot can converge on a "better" solution
Yes, but would it be backward compatible with existing C++ codebases? If the "clean reboot" is too different or not backward compatible enough would it be adopted by existing C++ users / the community?
If it required significant effort to port old C++ code to the rebooted version, why would the rebooted version be chosen over another language?(for example: Rust, Go, Ada, Zig, etc.)
Perl tried an ambitious rewrite from Perl 5 to Perl 6 and it did not work very well: it took too long, did not see wide adoption, and ultimately Perl 6 was renamed Raku.
Perl did not have to push Perl 6 changes through a standards committee or try to get a dozen or more compiler implementors to agree. (https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil...)
While it is possible that C++ could evolve into a smaller, cleaner version of itself, I do not think it is likely given all of the forces involved.
Well, I'm unfortunately not in a place where doing so makes sense. Unless you mean only auditing Rust code.
> nag managers
I already do so. This doesn't change much. There are still too many must-be-evolved C++ projects (no easy incremental rewrite path forward), it is impractical to have engs put significant effort into rewriting in Rust. It's really difficult to convince someone to fix something ain't broken.
People coding in C++ are just as desperate as you, that's why someone bring up Carbon [1], a half-baked experimental project to the world last year, instead of just using Rust. Sure, they would like to use a memory safe language as possible. No, they still have to get their job done.
> refuse to by hardware that only supports C
If it supports C, we can make it support Rust, it's a very fun weekend project to bring-up some nostd Rust code on it.
If I read e.g. "Why build Carbon?" on https://github.com/carbon-language/carbon-lang I dont find any concrete reasons or proves that show why C++ should be abandoned for something completely new but somehow very similar. There are so many question around the actual language definition like who maintains it, how is the standardization process. Who will adapt to it or to something else. ... This seems all so utopic.
I have been using C++ for many years with fantastic success. It allows me to create all I want/need from embedded to high performance projects. That you may shot you in the foot is in fact not bad. It compels you to be careful and think deeply about the design and only use what you completely understand.
With other languages your program might not crash but probably will do wrong things like eat up memory or access still references outdated data. You will find error much later in the process when it costs multiple magnitudes more.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
If you're not changing how const works, then this has limited utility in C++ because C++ const has all sorts of problems (e.g. not transitive). Also, what does the "mutable" annotation for a free function (i.e. main) mean? That just seems weird.
> - Lambda capture lists must be explicit (no [&] or [=], by themselves)
[&] is pretty valuable in cases where you do something like invokeSynchronously([&] {...})
I don't know that your changes will ever see much adoption because it won't be able to compile anything more complex than a "hello world" program as all the things you disallow are used & the porting effort is not cosmetic. Additionally, you're not actually fixing any of the problems people have with C++. So:
1. Consider fixing const semantics if you're going down the path of defining a new language
2. Think about how to fix memory safety and issues around UB which are the #1 sharp edges for C++
I don't know if you're achieving the goal of a safer, less error-prone language with the changes outlined. Have you looked at the things Carbon [1] is doing? I'd say that's an attempt to define a spiritual successor to C++, one that can easily interoperate with C++ but when you stay within the language it's safer.
The Github Page[1] says this: "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."
https://github.com/carbon-language/carbon-lang
Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.
> The Chrome security team is working to make a cross-platform memory safe language available to Chromium developers. This document describes how to use that language in Chromium. The language, at least for now, is Rust.
Could this mean that the "at least for now" part might hint to the language discussed in this thread? Memory safety seems to be a core goal of Carbon [1]:
> Safer fundamentals, and an incremental path towards a memory-safe subset
This approach could make sense, looking at their large C++ code base in Chrome.
[0]: https://news.ycombinator.com/item?id=31830020 [1]: https://github.com/carbon-language/carbon-lang