Earlier quoted context omitted.
Swift seems to be doing a decent job of this (and C++ interop for that matter)
> Swift seems to be doing a decent job of this It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.
Carbon Language: An experimental successor to C++
181–190 of 200 posts
Re: Carbon Language: An experimental successor to C++
#182Earlier quoted context omitted.
> Swift seems to be doing a decent job of this It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.
I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI
Re: Carbon Language: An experimental successor to C++
#183Re: Carbon Language: An experimental successor to C++
#184Earlier quoted context omitted.
In which way is C++ an "objectively pretty bad language"? I have done C++ for a living and it is not the easiest but there is tooling and warnings as errors that catch a lot of the errors before even you make a mistake. It is true that packaging is more challenging but it is also true that it is very configurable ro squeeze performance as much as possible (which is on of C++'s niches). And by squeezing I mean beyond…
Explicitly and between the lines, Carruth and Google have made it clear that the “bad” part of C++ from their perspective is the standards committee. In particular, the committee’s unwillingness to make ABI-breaking changes to the language, or more abstractly, to consider the needs of organizations with huge active code bases at least as seriously as those with huge legacy code bases.
Maybe a hybrid approach should be done byt breaking ABI in a so Core-supported language can cascade into so many places.
People say that Rust is great bc of that but that is just a trade-off and anyway there are olenty of dependencies like Boost, Abseil or others that can play that role anyways
Re: Carbon Language: An experimental successor to C++
#185Earlier quoted context omitted.
I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI
Curious, what keywords were those? I think Chris Lattner was not involved with Swift after version 3
Re: Carbon Language: An experimental successor to C++
#186Earlier quoted context omitted.
> the most catastrophic outcome Nah, this is in the context of C++ so UB isn't the most catastrophic situation. Undefined Behaviour is a behaviour, which means we might well be able to avoid invoking the behaviour and then it's fine. For example if your C++ program has a use-after-free in the code invoked only by the "Add file" feature but otherwise works fine, we can just ensure operators never use "Add file" and th…
As I said, UB means that a program has no meaning in the source language. That doesn't change anything I wrote above about the impact of UB. A hardware fault may also make a program meaningless, BTW, yet we all accept that every program written in any language is currently susceptible to UB or to a hardware fault. If you want, you can think of UB like a mathematical singularity in some physical theory. The theory of…
UB is a behaviour, it's unbounded, so it's an immediate disaster, and "time travel" UB can make this harder to reason about, because the as-if rule can mean that although it didn't in some sense "happen" yet the behaviour has consequences earlier. But if we avert the behaviour it won't happen. It is not correct to say that UB means the entire program had no meaning.
You give the "mathematical singularity" analogy, consider division. We doubtless agree than 6 divided by 3 is 2. And 6 divided by 2 is 3. But how about 6 divided by 0? This is not defined, we cannot perform such an operation. But division is not as a result somehow entirely without meaning, it just has this well understood limitation. Likewise for software with UB that we can avert.
IFNDR is a catastrophe because it truly does render the entire software without meaning.
Re: Carbon Language: An experimental successor to C++
#187Earlier quoted context omitted.
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.
Is there a compiler, maybe an online one, for Carbon, or some way to compile and run Carbon code? And if not, what are the plans for that?
Re: Carbon Language: An experimental successor to C++
#188Earlier quoted context omitted.
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++
#189Earlier quoted context omitted.
I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability". Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance…
Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages? A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust. There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common. (Maybe Rust could do this, but they haven't stabiliz…
Re: Carbon Language: An experimental successor to C++
#190Earlier quoted context omitted.
But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.
> But Safe C++ and Circle are different languages, right? Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe…