Not for gamedev or protocol stacks since no pointer arithmetic …
I'm not convinced that pointer arithmetic is necessary for gamedev: Odin (which has swizzle built-in!) has pointers but no pointer arithmetic.
Carbon Language: An experimental successor to C++
431–440 of 521 posts
Re: Carbon Language: An experimental successor to C++
#432Earlier quoted context omitted.
The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it
> The problem with C++ is it keeps getting better This is debatable. It keeps getting more complex. Whether all the additions are worthwhile remains to be seen.
every successive C++ standard allows me to remove a lot of code which is a net benefit
Re: Carbon Language: An experimental successor to C++
#433Earlier quoted context omitted.
"C++ also has a very hard-line "you don't pay for what you don't use" This always felt eye-rolling false to me. We can't have a better hashmap since we all need to pay for the std::unordered_map's un-needed features like bucket access. We are certainly paying for what we don't use.
"You don't pay for what you don't use" means the compiler doesn't generate worse code than if you had written the same by hand. Every other adoption of the meaning is misuse of what Bjarne originally meant with it.
"You don't pay for what you don't use" does not mean "the compiler doesn't generate worse code than if you had written the same by hand".
These 2 things are C++ core principle, but they are 2 different things.
"You don't pay for what you don't use" means that I you do not use a C++ feature, your runtime performance won't be affected by this feature. For example, non virtual functions are not slower because virtual functions exist.
In our case here, if you do not use "std::unordered_map" and decide to implement your own unordered map, then it is as-if "std::unordered_map" never existed. You are not forced to use "std::unordered_map" and you own map won't be slower because it exists.
"the compiler doesn't generate worse code than if you had written the same by hand", or rather "What you do use, you couldn’t hand code any better", means that if you decided to implement a C++ feature by hand in C++ or C, your implementation could only hope to match C++ implementation. For instance calling a virtual function in C++ will never be slower than a similar handwritten late dispatch implementation.
Re: Carbon Language: An experimental successor to C++
#434Earlier quoted context omitted.
> All appear to have an upward trajectory today. They might have an upward trajectory, but they're not posed to break well beyond their respective records. With the possible exception of Python, how popular a language is at age ten is a reasonable rough indicator of how popular it's ever going to be. At its current growth rate Rust would reach 1% market share at age ten. Again, there can certainly be surprises, but I…
> That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success. I'd simply point to the fact that there are very few languages that have tried to get into the same space that rust exists in. Even something like D came with an optional GC which has pulled it out from consideration for things like the kernel or embedded devices. When you say "most langu…
Except I didn't say "most languages are peaked at 10 years"; I said virtually all languages reached or neared the ballpark of their peak at age 10, from the most to the least successful ones, and those include C, C++, and D. I think Python might be the only counterexample. So it's always possible that some other language would be another exception, but there's nothing today to indicate that Rust is gearing to be such an exception or that it is substantially different from all the languages in all domains that have exhibited that behaviour.
I do agree that it's more likely that Rust is an exception than, say, Scala or perhaps even Go, but the same would be true for, say, Carbon. I.e. while the likelihood is higher, there's nothing at the moment that would indicate that's what's happening.
Obviously Rust has garnered more enthusiasm among PL fans than D ever did, and its peak would probably be higher, but technical enthusiasm and hype is very weakly correlated with long-term success in the world of programming languages. Most charitably you could say it's a necessary condition, but it is very clearly not a sufficient one.
Re: Carbon Language: An experimental successor to C++
#435Earlier quoted context omitted.
cxx is great but it isn't anything close to what cogman10 is describing. It actually can't ever be, because C++ has move constructors and Rust deliberately doesn't, so you can't for example return `std::string` from a Rust function by value.
It's currently unclear if Rust can interop with C++ with high fidelity. For example https://docs.rs/moveit/latest/moveit/ and https://github.com/google/crubit/blob/main/rs_bindings_from_... provide functionality to use non-trivially relocatable C++ types from Rust.
Bit hard to follow but as far as I can tell those are pinning the C++ types and wrapping them in some other object that allows a move constructor to be called on them to move them to some other pinned location.
It still doesn't let you natively move them, and if you have to wrap them in something you may as well just wrap them in `Box` and not move them, which is what cxx does.
I guess maybe it makes a difference for passing things into existing C++ interfaces?
Anyway it looks insanely complicated.
Re: Carbon Language: An experimental successor to C++
#436Earlier quoted context omitted.
> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming langu…
GP said the standard low-level language. Low-level code will always be a much smaller percentage of all code than the heaps of web apps our industry is shitting out on a daily basis. Thus it would be completely reasonable for the de facto sysdev language to have a small market share overall(unless like for C/C++ there is a lot of legacy stuff to maintain) . Your sources don't shine any light on this at all.
Sure, but even low-level languages have tended to reach the ballpark of their all-time peak market penetration -- however high or low it is -- around age 10.
Re: Carbon Language: An experimental successor to C++
#437Earlier quoted context omitted.
> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming langu…
"... around age 10." C++ (not to mention C)? IIRC, I remember seeing B.S.'s "C with Classes" appear in ACM SIGPLAN Notices in the early 1980s -- 40 years ago. I don't think it hit its peak 10 or even 15 years after its early development. Given that it's C++, that's a pretty major exception.
If C++ hadn't already hit it's all-time peak market share in 1995, it was certainly well inside the ballpark. It's far from an exception.
Re: Carbon Language: An experimental successor to C++
#438Re: Carbon Language: An experimental successor to C++
#439Earlier quoted context omitted.
I'm not following you at all. Carbon was an API for Mac OS X, not a programming language. It was a C API, not an Objective-C API. (Maybe you are mistaking it for Cocoa, which required Objective-C on 64-bit platforms.) What relationship does this have to the new Carbon programming language? Google did clobber another programming language with Go.[1] It was a truly a-hole move. [1] https://en.wikipedia.org/wiki/Go_(pro…
> I'm not following you at all. Not even a tiny little bit? Really? First of all, apologies for my boneheaded mistake, but let me try to see if I can show you the problem. If everything, everything there is, was named "Tom," you can see how it might get confusing determining just what is being talked about. That is hyperbole, but it should illuminate why it is ambiguous to call two things by the same name, but it is…
+1 for this. It is a 'cool' name but this choice has problems.
As a practical illustration, it'll cause confusion when searching for 'carbon programming' or 'carbon apis' on $SEARCH_ENGINE. It isn't current but I would wager that there is still a lot of legacy Carbon code in the Macspace. This won't help the poor devs tasked with maintaining it. Unless they rewrite it in Carbon. See?
We in the trade also know how important it is to avoid giving things confusing names, and how frustrating it is when you find some garbled or ambiguous variable name while debugging or enhancing code. The same principle applies to naming your language too.
Re: Carbon Language: An experimental successor to C++
#440Earlier quoted context omitted.
It's currently unclear if Rust can interop with C++ with high fidelity. For example https://docs.rs/moveit/latest/moveit/ and https://github.com/google/crubit/blob/main/rs_bindings_from_... provide functionality to use non-trivially relocatable C++ types from Rust.
Bit hard to follow but as far as I can tell those are pinning the C++ types and wrapping them in some other object that allows a move constructor to be called on them to move them to some other pinned location. It still doesn't let you natively move them, and if you have to wrap them in something you may as well just wrap them in `Box ` and not move them, which is what cxx does. I guess maybe it makes a difference fo…
[deleted]