7 ms·

Comparing Rust to Carbon

94 points by pykello 1y ago

anon-3988 1y ago
> The thing is, there is a lot of existing software in the world written in C and C++. This is true, and I think that there is a type of language that I don't think have been explored yet: Cross language ABI language. That is, the language is fully designed for being the glue between multiple languages to allow for migration in the future. I think it would probably end up being C. > There are several languages that have managed a transition away from a base language into a more capable, flexible successor language, though: TypeScript is an evolution of JavaScript, Swift is an evolution of Objective-C, and C++ itself is an evolution of C. And yet none of these have fully escaped the chain of their predecessors. And that is almost the point, people actually wanted to do what JavaScript could do, what C could do, what Objective-C could do. Then we put cover on it, but it is still a wooden table at the end of the day. Have Hyrum's Law teach us nothing? Unless you consciously make the effort to REMOVE features, it will always be there. The fact that cross language boundary is complicated is a sign that the new language is actually shedding off technical debts. If I wrote a massively complicated function in C that leaks file handles, the answer isn't to read /proc/fd before and after, then manually unlink the new FDs. The answer is to actually dig through the code or rewrite it.
- jcranmer 1y ago
  > That is, the language is fully designed for being the glue between multiple languages to allow for migration in the future. I think it would probably end up being C. Unfortunately, C is woefully insufficient for such a language. At a minimum, you'd want to have a language that can distinguish between nullable and nonnullable pointers, pointer-with-array-len (so C++'s std::span or Rust's slice), and read-only versus read-write pointers (which const only kind of does). Expressing no-alias relationships and very basic lifetime relationships is also pretty critical for several languages. Multiple return values is something I'd love to see, in addition a success-object-or-error-object (something like a Result type). Having a dedicated not-necessarily-null-terminated UTF-8 string type is also useful.
  - PeakKS 1y ago
    While raw C is not super helpful for generating nice bindings, I think you could get most of the way there if there were annotations for everything, e.g. like how the __counted_by__ attribute was added.
  - lelanthran 1y ago
    The problem with almost all of those is that most languages won't support it; that's a FFI specific to Rust. I mean, what do you do with those languages that don't have the concept of lifetime relationships, like Python? Or those in which read/write pointers make no sense (Tcl)? How about languages with linear datatypes? Or languages that don't allow self-referential data structures (like Rust)? The only practical approach is to have an interface that is the lowest common denominator of most languages, which is what we already have with C. I did work in CORBA in the 90s (and someone else mentions COM down below, which I also worked a little with), and the way I'd go about it[1] is similar to swig but in a CORBA/COM type fashion - an IDL that will generate bindings for specific languages. This requires quite a lot of prescient thinking - after all, lifetime ownership is a fairly new thing, so who knows what new requirement will come in the future? In some future language, you may want FFI to encompass closures, in which case you'd have extra syntax for capture by value vs capture by reference, and you may not necessarily want ownership change in the function call (for example on a single-threaded callback function, the value captured by reference is safe for either party to modify). Nail down the data interface and you're 80% there. ====================== [1] The best way to go about it would be using something like s-expressions: allow some basic execution to encompass every type of object a language might ever need.
- kachapopopow 1y ago
  The answer is obviously to have a background task that periodically frees the leaked handles made by a program written in Carbon using a c library.
- cybergoat 1y ago
  As hairy as it is, COM is an example of a cross language API/ABI. It's workable from C, C++, C# etc etc and even accessible in MacOS as "NSPlugin".
  - carlmr 1y ago
    >As hairy as it is, COM is an example of a cross language API/ABI I think the reverse will also be true. Any cross language API will get issues.
    - pjmlp 1y ago
      Indeed, example all the languages that target JVM, CLR and WebAssembly, and the missing bits between what the platform can do, what the "systems" language exposes, and what everyone else is able to expose or consume.
  - pjmlp 1y ago
    Also the design macOS drivers use. However on Windows, given its prevalence, especially since Vista, one would expect that by now Windows team would have bothered to make it less hairy, but elas it has never been a priority, when when they actually did something (WinRT) is was woefully mismanaged and now no one cares.
b_e_n_t_o_n 1y ago
I think languages that take C++ interop seriously will win over the long term. And that means I'm saying Swift is a better bet than Rust long term. So yeah.
- ameliaquining 1y ago
  Unless Rust adds Swift-like C++ interop, which is a real possibility.
  - pornel 1y ago
    This has been recognised as the next important milestone for Rust and there's work towards making it happen. The details are uncertain yet, because move constructors are a big change for Rust (it promised that address of owned objects is meaningless, and they can be simply memcpy'd to a new address).
    - zozbot234 1y ago
      The Rust folks want a more usable Pin<> facility for reasons independent of C++ support (it matters for the async ecosystem) and Pin allows objects to keep their addresses once pinned.
- pjmlp 1y ago
  The problem is that it is too Apple centric. I have no doubts that is what will happen on Apple world, outside I am not so certain.
  - b_e_n_t_o_n 1y ago
    How so? Maybe 5 years ago that would be the case but they've been steadily making it cross platform and it's a great choice now for CLI's, servers, embedded etc.
    - pjmlp 1y ago
      Just like Objective-C is a great choice for a GNUStep based distro, since 2000's. We have been here before. The investment of Apple into a cross platform Swift ecosystem is a fraction of what Microsoft is doing with .NET, and even it isn't without issues. Outside Apple ecosystems there are much more mature options for CLI and servers software.
ultimaweapon 1y ago
My observation is most people who suggest Rust alternative don't use Rust. People who actually use Rust known it is worth to rewrite C/C++ software in Rust, either the whole or part by part. There is a tool to convert C source into Rust too so you can retain the whole functionalities while migrating to Rust. I have done this with Lua and it work wonderfully. The good news is Linux now adopt Rust. In the end it will be all Rust although it may take a long time to migrate from C.
- alberth 1y ago
  > I have done this with Lua Do you by chance work at Cloudflare, who has migrated away from Lua to Rust? Curious to hear observations on productivity hit going from Lua to Rust.
  - pornel 1y ago
    In Cloudflare's case, Rust is much more productive. Rust modules can handle any traffic themselves, instead of a split between native code and Lua that is too slow to do more than config (Lua is relatively fast for a scripting language, but on the critical path it was a "peanut butter" slowdown adding latency). At the size and complexity of a server serving 20% of the Web, Lua's dynamic typing was scary. Modules in Rust can enforce many more requirements. Rust's solid dependency management also helps share implementations and config logic across modules and even different products, instead of everything having to go literally through the same server. https://blog.cloudflare.com/20-percent-internet-upgrade/ https://blog.cloudflare.com/20-percent-internet-upgrade/
    - alberth 1y ago
      > instead of a split between native code and Lua that is too slow to do more than config In case you’re not aware, Cloudflare ran on LuaJIT (not just for config) until not that long ago. https://news.ycombinator.com/item?id=23856875 https://news.ycombinator.com/item?id=23856875
      - 1y ago
MangoToupe 1y ago
> In short, Carbon is a project to create an alternative front-end for C++ Well this was a shocker, to say the least! Why would you intentionally pick the same name as the transitionary gui framework from macos classic to macosx when the demographic you're targeting is the most likely to confuse the two terms?
- Philpax 1y ago
  How often do you, in all seriousness, reference the transitory UI framework that was introduced two decades ago and deprecated over a decade ago? At some point, it's okay to reuse names.
  - ameliaquining 1y ago
    Also last I heard Carbon was a temporary codename that they were going to replace with something else if/when the language ever became production ready, though I don't know whether that's still the plan.
    - steveklabnik 1y ago
      I haven’t heard this, and with the number of conference talks and media done about it, if that were the plan I’d expect it to be pretty front and center so that those interested would be aware.
  - MangoToupe 1y ago
    Sure it's ok to reuse names, but why would you want to opt into such confusion? It's jot so much that someone is seriously going to be confused so much as just bad branding. You could pick any name.
    - steveklabnik 1y ago
      There is no realistic confusion. Heck, I wrote code in that Carbon back in the day and the association never even crossed my mind. Many professional developers weren’t even adults yet when that Carbon was sunset, or weren’t involved in the Apple ecosystem.
jillesvangurp 1y ago
I migrated some code from Javascript to Typescript and then from Java to Kotlin. What helped in both cases was that I was able to go file by file. I didn't have to rewrite all my software all at once. That's something that is very disruptive and impractical in software that is actively used (i.e. all useful software). With Typescript, all you have to do is rename your .js file to a .ts file and then you can start addressing the warnings. With Kotlin, there's a convenient but imperfect Java to Kotlin converter that ships with Intellij. It will get you 95% there but expect to fix a few things. Basically you modify your build to add the Kotlin compiler and then you start converting files. In my case I started with some simple tests that weren't on the critical path to anything. When that worked really well, I quickly got in a mode where any Java file I worked on was converted to Kotlin. Same with Typescript. Both code bases rapidly shifted to being mostly Kotlin/Typescript but with lots of remaining Java and Javascript. A big advantage of incremental approaches like this is that you get to focus your attention on the most critical parts of the software without really interrupting your development process. The critical parts of your software are those parts that you are actually working on regularly to fix bugs or add features. Another advantage is that you slowly get used to the new language. This takes time. In my case I had to unlearn about 20 years of using Java. Optional is not a thing in Kotlin for example. It's 100% redundant Java clutter. And finally, you organically convert most code that matters in a relatively short amount of time. So, you make rapid progress and make a big impact. Which is always a good thing when learning a new thing. So, I can see the value of Carbon here. Start dropping it into existing C++ code bases. Upgrade files as you work on the code anyway. Put some focus on the typical hotspots where you were fixing lots of bugs anyway. This way, things improve rapidly and the last 20% of the code is the least important part of the code generally. You get diminishing returns from upgrading it. It will be nice to see what happens when this is ready for production usage. Like with Kotlin and Typescript, expect this to stay controversial with some people. Stuff like this never fully converts the target audience. I know lots of people that prefer Java and Javascript. Mostly for irrational reasons IMHO. But they do. It all boils down to people just being a bit change resistant. And the C++ crowd is very conservative.
- pjmlp 1y ago
  JVM is designed for and alongside Java. I will consider Kotlin outside Android, when it becomes relevant for JVM design, being taken into account by all major JVM implementations and JEP proposals, instead of something imposed by an OS vendor, stiffing Java support on purpose. Guest languages always end up eventually going down their own path. Not even C++ developed alongside C and UNIX, managed to take over UNIX clones, or industry standards for OS and graphics APIs. Typescript relevance might wither away when JavaScript gains type annotations, it is after all only a nice linting tool. Despite all WebAssembly craziness, JavaScript still rules the browser and edge gateways. If that is irrational, oh well.

94 points by pykello 1y ago

> The thing is, there is a lot of existing software in the world written in C and C++. This is true, and I think that there is a type of language that I don't think have been explored yet: Cross language ABI language. That is, the language is fully designed for being the glue between multiple languages to allow for migration in the future. I think it would probably end up being C. > There are several languages that have managed a transition away from a base language into a more capable, flexible successor language, though: TypeScript is an evolution of JavaScript, Swift is an evolution of Objective-C, and C++ itself is an evolution of C. And yet none of these have fully escaped the chain of their predecessors. And that is almost the point, people actually wanted to do what JavaScript could do, what C could do, what Objective-C could do. Then we put cover on it, but it is still a wooden table at the end of the day. Have Hyrum's Law teach us nothing? Unless you consciously make the effort to REMOVE features, it will always be there. The fact that cross language boundary is complicated is a sign that the new language is actually shedding off technical debts. If I wrote a massively complicated function in C that leaks file handles, the answer isn't to read /proc/fd before and after, then manually unlink the new FDs. The answer is to actually dig through the code or rewrite it.

jcranmer 1y ago
> That is, the language is fully designed for being the glue between multiple languages to allow for migration in the future. I think it would probably end up being C. Unfortunately, C is woefully insufficient for such a language. At a minimum, you'd want to have a language that can distinguish between nullable and nonnullable pointers, pointer-with-array-len (so C++'s std::span or Rust's slice), and read-only versus read-write pointers (which const only kind of does). Expressing no-alias relationships and very basic lifetime relationships is also pretty critical for several languages. Multiple return values is something I'd love to see, in addition a success-object-or-error-object (something like a Result type). Having a dedicated not-necessarily-null-terminated UTF-8 string type is also useful.
- PeakKS 1y ago
  While raw C is not super helpful for generating nice bindings, I think you could get most of the way there if there were annotations for everything, e.g. like how the __counted_by__ attribute was added.
- lelanthran 1y ago
  The problem with almost all of those is that most languages won't support it; that's a FFI specific to Rust. I mean, what do you do with those languages that don't have the concept of lifetime relationships, like Python? Or those in which read/write pointers make no sense (Tcl)? How about languages with linear datatypes? Or languages that don't allow self-referential data structures (like Rust)? The only practical approach is to have an interface that is the lowest common denominator of most languages, which is what we already have with C. I did work in CORBA in the 90s (and someone else mentions COM down below, which I also worked a little with), and the way I'd go about it[1] is similar to swig but in a CORBA/COM type fashion - an IDL that will generate bindings for specific languages. This requires quite a lot of prescient thinking - after all, lifetime ownership is a fairly new thing, so who knows what new requirement will come in the future? In some future language, you may want FFI to encompass closures, in which case you'd have extra syntax for capture by value vs capture by reference, and you may not necessarily want ownership change in the function call (for example on a single-threaded callback function, the value captured by reference is safe for either party to modify). Nail down the data interface and you're 80% there. ====================== [1] The best way to go about it would be using something like s-expressions: allow some basic execution to encompass every type of object a language might ever need.
kachapopopow 1y ago
The answer is obviously to have a background task that periodically frees the leaked handles made by a program written in Carbon using a c library.
cybergoat 1y ago
As hairy as it is, COM is an example of a cross language API/ABI. It's workable from C, C++, C# etc etc and even accessible in MacOS as "NSPlugin".
- carlmr 1y ago
  >As hairy as it is, COM is an example of a cross language API/ABI I think the reverse will also be true. Any cross language API will get issues.
  - pjmlp 1y ago
    Indeed, example all the languages that target JVM, CLR and WebAssembly, and the missing bits between what the platform can do, what the "systems" language exposes, and what everyone else is able to expose or consume.
- pjmlp 1y ago
  Also the design macOS drivers use. However on Windows, given its prevalence, especially since Vista, one would expect that by now Windows team would have bothered to make it less hairy, but elas it has never been a priority, when when they actually did something (WinRT) is was woefully mismanaged and now no one cares.

b_e_n_t_o_n 1y ago

I think languages that take C++ interop seriously will win over the long term. And that means I'm saying Swift is a better bet than Rust long term. So yeah.

ameliaquining 1y ago
Unless Rust adds Swift-like C++ interop, which is a real possibility.
- pornel 1y ago
  This has been recognised as the next important milestone for Rust and there's work towards making it happen. The details are uncertain yet, because move constructors are a big change for Rust (it promised that address of owned objects is meaningless, and they can be simply memcpy'd to a new address).
  - zozbot234 1y ago
    The Rust folks want a more usable Pin<> facility for reasons independent of C++ support (it matters for the async ecosystem) and Pin allows objects to keep their addresses once pinned.
pjmlp 1y ago
The problem is that it is too Apple centric. I have no doubts that is what will happen on Apple world, outside I am not so certain.
- b_e_n_t_o_n 1y ago
  How so? Maybe 5 years ago that would be the case but they've been steadily making it cross platform and it's a great choice now for CLI's, servers, embedded etc.
  - pjmlp 1y ago
    Just like Objective-C is a great choice for a GNUStep based distro, since 2000's. We have been here before. The investment of Apple into a cross platform Swift ecosystem is a fraction of what Microsoft is doing with .NET, and even it isn't without issues. Outside Apple ecosystems there are much more mature options for CLI and servers software.

ultimaweapon 1y ago

My observation is most people who suggest Rust alternative don't use Rust. People who actually use Rust known it is worth to rewrite C/C++ software in Rust, either the whole or part by part. There is a tool to convert C source into Rust too so you can retain the whole functionalities while migrating to Rust. I have done this with Lua and it work wonderfully. The good news is Linux now adopt Rust. In the end it will be all Rust although it may take a long time to migrate from C.

alberth 1y ago
> I have done this with Lua Do you by chance work at Cloudflare, who has migrated away from Lua to Rust? Curious to hear observations on productivity hit going from Lua to Rust.
- pornel 1y ago
  In Cloudflare's case, Rust is much more productive. Rust modules can handle any traffic themselves, instead of a split between native code and Lua that is too slow to do more than config (Lua is relatively fast for a scripting language, but on the critical path it was a "peanut butter" slowdown adding latency). At the size and complexity of a server serving 20% of the Web, Lua's dynamic typing was scary. Modules in Rust can enforce many more requirements. Rust's solid dependency management also helps share implementations and config logic across modules and even different products, instead of everything having to go literally through the same server. https://blog.cloudflare.com/20-percent-internet-upgrade/ https://blog.cloudflare.com/20-percent-internet-upgrade/
  - alberth 1y ago
    > instead of a split between native code and Lua that is too slow to do more than config In case you’re not aware, Cloudflare ran on LuaJIT (not just for config) until not that long ago. https://news.ycombinator.com/item?id=23856875 https://news.ycombinator.com/item?id=23856875
    - 1y ago

MangoToupe 1y ago

> In short, Carbon is a project to create an alternative front-end for C++ Well this was a shocker, to say the least! Why would you intentionally pick the same name as the transitionary gui framework from macos classic to macosx when the demographic you're targeting is the most likely to confuse the two terms?

Philpax 1y ago
How often do you, in all seriousness, reference the transitory UI framework that was introduced two decades ago and deprecated over a decade ago? At some point, it's okay to reuse names.
- ameliaquining 1y ago
  Also last I heard Carbon was a temporary codename that they were going to replace with something else if/when the language ever became production ready, though I don't know whether that's still the plan.
  - steveklabnik 1y ago
    I haven’t heard this, and with the number of conference talks and media done about it, if that were the plan I’d expect it to be pretty front and center so that those interested would be aware.
- MangoToupe 1y ago
  Sure it's ok to reuse names, but why would you want to opt into such confusion? It's jot so much that someone is seriously going to be confused so much as just bad branding. You could pick any name.
  - steveklabnik 1y ago
    There is no realistic confusion. Heck, I wrote code in that Carbon back in the day and the association never even crossed my mind. Many professional developers weren’t even adults yet when that Carbon was sunset, or weren’t involved in the Apple ecosystem.

jillesvangurp 1y ago

I migrated some code from Javascript to Typescript and then from Java to Kotlin. What helped in both cases was that I was able to go file by file. I didn't have to rewrite all my software all at once. That's something that is very disruptive and impractical in software that is actively used (i.e. all useful software). With Typescript, all you have to do is rename your .js file to a .ts file and then you can start addressing the warnings. With Kotlin, there's a convenient but imperfect Java to Kotlin converter that ships with Intellij. It will get you 95% there but expect to fix a few things. Basically you modify your build to add the Kotlin compiler and then you start converting files. In my case I started with some simple tests that weren't on the critical path to anything. When that worked really well, I quickly got in a mode where any Java file I worked on was converted to Kotlin. Same with Typescript. Both code bases rapidly shifted to being mostly Kotlin/Typescript but with lots of remaining Java and Javascript. A big advantage of incremental approaches like this is that you get to focus your attention on the most critical parts of the software without really interrupting your development process. The critical parts of your software are those parts that you are actually working on regularly to fix bugs or add features. Another advantage is that you slowly get used to the new language. This takes time. In my case I had to unlearn about 20 years of using Java. Optional is not a thing in Kotlin for example. It's 100% redundant Java clutter. And finally, you organically convert most code that matters in a relatively short amount of time. So, you make rapid progress and make a big impact. Which is always a good thing when learning a new thing. So, I can see the value of Carbon here. Start dropping it into existing C++ code bases. Upgrade files as you work on the code anyway. Put some focus on the typical hotspots where you were fixing lots of bugs anyway. This way, things improve rapidly and the last 20% of the code is the least important part of the code generally. You get diminishing returns from upgrading it. It will be nice to see what happens when this is ready for production usage. Like with Kotlin and Typescript, expect this to stay controversial with some people. Stuff like this never fully converts the target audience. I know lots of people that prefer Java and Javascript. Mostly for irrational reasons IMHO. But they do. It all boils down to people just being a bit change resistant. And the C++ crowd is very conservative.

pjmlp 1y ago
JVM is designed for and alongside Java. I will consider Kotlin outside Android, when it becomes relevant for JVM design, being taken into account by all major JVM implementations and JEP proposals, instead of something imposed by an OS vendor, stiffing Java support on purpose. Guest languages always end up eventually going down their own path. Not even C++ developed alongside C and UNIX, managed to take over UNIX clones, or industry standards for OS and graphics APIs. Typescript relevance might wither away when JavaScript gains type annotations, it is after all only a nice linting tool. Despite all WebAssembly craziness, JavaScript still rules the browser and edge gateways. If that is irrational, oh well.