23 ms·

The year of C++ successor languages

176 points by nikbackm 4y ago

zozbot234 4y ago
Article fails to mention that autocxx and crubit are aiming for much improved interop between Rust and C++. Sure they're experimental, but not more so than Val. Rust devs are also pushing for making more of its core and std library "unsafe" friendly, to reduce the risk of unsound calls to Safe Rust from an unsafe environment with possible aliasing, pinned-in-place objects, self-references, uninitialized ("write-only") memory etc. etc. So that in itself will also deliver improved semantics between Rust and C++.
- c-cube 4y ago
  It's pretty strange. Rust is dismissed because interop with C++ is hard, but then Val is cheered on despite its C++ interop basically being a big "todo" item.
  - epolanski 4y ago
    Author admits his own bias and preference at the end.
    - ModernMech 4y ago
      > I do need to confess: in my spare time, I have started working with the Val team Indeed, I think this should have been made clear in the first section. I thought when the author said they have a bias it was more in the general sense, not that they are working on one of the languages in question.
      - MoscMob 4y ago
        Yes, misleading.
  - sli 4y ago
    Also just saying a language's C++ interop is better simply because it's easier doesn't really pass the smell test for me. If I need to write some interop for a C++ library, I'm going to prefer one that's more reliable than one that's easy but can fail in weird ways. And unless my project is an interoperability library, I'm not sold on "harder = worse" when I'm most likely going to write the interop once, ever, and be done with it. If it takes me a day, but then I can rely on it to function well and fail in predictable ways, I'm still on board. There's nothing wrong with something being difficult if the result removes a ton of mental load. I'm not a fan of this article's conclusions at all.
    - scaredginger 4y ago
      Not to mention efficiency. Sure, it's 'easier' to make a copy of all the data when crossing the FFI boundary
- Ambroisie 4y ago
  Can you explain what you mean, about unsafe friendliness in the standard library?
  - ysleepy 4y ago
    I believe this is referring to the interop abi that is in planning. It aims to expose a nicer way to glue rust idioms to similar or equivalent idioms in other languages. https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586
    - SirGiggles 4y ago
      Not the poster of the comment but I'd like to hear from the downvoter why this was downvoted. As a Rust novice, interpreting the comment GP made (from the perspective of, for example, C++ calling Safe Rust core or stdlib) this seems like a valid response.
      - SirGiggles 4y ago
        Would the downvoter like to comment as to why I too got downvoted?
eps 4y ago
https://web.archive.org/web/20230102100639/https://accu.org/journals/overload/30/172/teodorescu/ https://web.archive.org/web/20230102100639/https://accu.org/... Val: https://www.val-lang.dev/ https://www.val-lang.dev/ Carbon: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang CppFront: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- linuxftw 4y ago
  Great talk on CppFront given recently at cppcon: https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY
- tialaramex 4y ago
  That Val site provides the following example, which makes no sense to me: public fun main() { let weight = 1.0 print(weight) // 1.0 let length = 2.0 print(length) // 1.0 } Is the behaviour of print "Just print whatever the first variable was forever" ? Is this example wrong ?
  - sli 4y ago
    That is almost certainly just a typo. That example is meant to help explain Val's lifetimes in the most basic possible way.
  - ngrilly 4y ago
    I wondered the same. I also guess this is a typo.
flohofwoe 4y ago
It's 'interesting' that the author critices Go for having a GC making it 'inappropriate' as a system programming language, but then also critices Go for not having exceptions (which are IMHO at least as 'inapproriate' for that type of language). If anything, the latest round of systems programming languages which all use error unions instead of exceptions have demonstrated quite clearly that exceptions are actually quite pointless.
- zozbot234 4y ago
  Go does have exceptions, via panic/recover. You could argue that Rust lacks true exceptions because a Rust panic can be configured to be fatal at the whole-program level. (Which is actually great for deep-embedded scenarios where even C++ use is with no-exceptions support.)
  - usrnm 4y ago
    Yeah, it's funny how go does have exceptions, but no notion of exception safety. Manual mutex locks/unlocks are everywhere, and don't even start me on defer, which is just terrible
    - mike_hock 4y ago
      That's how you get a "simple" language.
  - IshKebab 4y ago
    Those are not exceptions by most reasonable definitions. Exceptions are a general purpose error handling method. Try, catch and all that. They are almost always objects with multiple types. Go and Rust's panic is for unrecoverable errors. They both have the ability to catch panics because sometimes you really need to do that (e.g. when interacting with FFI or sometimes multithreaded code). They are not exceptions though. I've seen this myth repeated a few times lately (always about Go and not Rust for some reason) and I wish it would die. You wouldn't say C "has exceptions" would you?
uwuemu 4y ago
For me 2022 was the year of learning C++ (background in C# and Php) and I must say that after being intimidated by the language (extensive use of pointers, stack/heap compile/run time allocation and deallocation, templates) for years, when I really took a proper look and got some practice, it is an incredible language. The command an control you get by working with memory and the system on a lower level is amazing. I found it so much easier to learn (once I got the grasp of the cpp way of doing things) than something like Rust. All the higher level advanced concepts work and flow beautifully as you'd expect based on the lower level of the language... and the amount of "magic" is kept to minimum... you can just open std and look at what is being done and it all males sense. I understand why people want to move from C++ but as a newbie in this language, I find it amazing.
- meindnoch 4y ago
  Why was this comment flagged? C++ haters... really?
  - alphanullmeric 4y ago
    [flagged]
    - Yoric 4y ago
      All the Rust programmers I know are really happy to discuss the limitations and shortcomings of the language. It's possible that the problem you're pointing at comes from the word "reddit" rather than "rust" :) Note: I've looked at the parent's comment history. The only one of them which was not a troll against Rust was a troll against the EU. I'll stop feeding the troll.
      - alphanullmeric 4y ago
        [flagged]
        School-Cotton 4y ago
Longhanks 4y ago
...is not 2023.
mdp2021 4y ago
Sorry, I have only a sketchy idea of Zig: I understood it should have been a competitor? Why does the article writer in fact disregard it? The authors of Val state: > Our goals overlap substantially with that of Rust and other commendable efforts, such as Zig or Vale
- flohofwoe 4y ago
  Zig is usually seen as a 'better C', not as a 'better C++'. Whether this is actually the case is debatable though (some of Zig's features are 'leaking' into the territory of higher level languages such as C++ or Rust).
  - fckgnad 4y ago
    I feel this viewpoint is pedantic. Zero cost abstractions is the space we're looking at and from this perspective, C and C++ are in the same space. If not then are we implying a successor to C++ needs to be Object Oriented? Because that's the main difference between C++ and C. Clearly the successor languages mentioned in the article do not have the same heavy OOP bias embedded into themselves as C++ and thus they all can be looked upon as successors to C as well. I think the goal here is just to find a language that does the whole "zero cost abstraction" thing better than the status quo.
    - c-cube 4y ago
      There are so many more differences between C and C++. Templates, RAII, type inference, lambdas, etc. These are the abstractions that try to be zero cost; C has little abstraction overall so it doesn't claim "zero cost abstraction". I don't think you need to be fully OOP to claim to be a C++ successor, but you definitely need to have decent zero cost abstractions, including a form of templates/generics. Having RAII might also be a requirement.
    - pjmlp 4y ago
      All the successor languages mentioned on the article have ways to provide methods and some form of polymorphism directly supported in the language, and not the OOP in C kind of kludge.
transfire 4y ago
Unless there is significant reason to avoid garbage collection (for the vast majority of software there isn’t) then Crystal is the best C++ replacement out there. Its Ruby syntax is easy to read and write, its OOP model derives from Smalltalk (via Ruby). And it has easy interop with C++ code.
- anonymoushn 4y ago
  Aren't users who are okay with GC already not using C++?
  - p0nce 4y ago
    A lot of C++ software out there could afford to use a GC.
    - wiseowise 4y ago
      What’s wrong with RAII?
      - Rochus 4y ago
        nothing
      - Yoric 4y ago
        I can think of a few cases in which GC would really simplify things, both in C++ and in Rust. I want to do some serious D and Go (and Crystal?) some day to see how it changes life.
      - pebal 4y ago
        It is not a solution for all cases.
        wiseowise 4y ago
        Care to give cases where it is not a solution?
rurban 4y ago
I miss pony, rune, nim, crystal and many more. rune has an explicit 'replace C++ in prod' goal.
- auxym 4y ago
  Indeed. And Nim has very good FFI with C++, including templates even.
- chubot 4y ago
  Hm I never heard of Rune, and I have heard of all the others (although this article gave me more info about Val): https://github.com/google/rune https://github.com/google/rune (side project, not Google project) This part is interesting, as I've found many benefits from having a layer of indirection between the app-level data definitions, and the C/C++ struct level. I recall that Jai used to advertise the SoA -> AoS transforms but that was many years ago. It provides many of its features by deeply integrating the "DataDraw" tool into the primitives and constructs of the language. DataDraw is a code-generation tool that generates highly-optimized C code which outperforms e.g., the C++ STL given a declarative description of data-structures and relationships between them. For more information, see the DataDraw 3.0 Manual. I've never heard of DataDraw either .. I wonder who uses it?
  - gavinray 4y ago
    I can field questions folks might have on DataDraw. I'm not Bill, but I wrote the docs PR that recently overhauled the Rune README to highlight a lot of this interesting info about its use of the DD tool. Another neat thing about DD -- the Rune compiler/grammar itself are written as DataDraw types. All user-defined classes/types are compiled under the hood into DD types. One of the builtin things you can do is generate PostScript visualizations of them. Check this out: https://github.com/google/rune/pull/33#issuecomment-1355828317 https://github.com/google/rune/pull/33#issuecomment-13558283...
zer0zzz 4y ago
Very little discussion of swift and how the current work on C++ Interop is in many ways a peak into what carbon and others may be in several years.
awesomegoat_com 4y ago
And the next year will be the year of THE Successor Language And that's (of-course, hands down) zig. Thank me later. :-) Jokes aside, I really like where zig is headed. As a gambler, I am willing to bet on zig over val any time and twice on Mondays.
- FpUser 4y ago
  Zig is really nice language with some good concepts. However it is not a successor to C++.
de_keyboard 4y ago
I am very bullish on Carbon. Using C++ semantics will make switching and integration much easier.
- galangalalgol 4y ago
  Its abstractions and memory safety aren't zero cost though. I do wish ffi between rust and c++ was easier, having just fought that battle again recently, but I'm not willing to give up performance over it. I think it is telling that carbon came out of google, and rust came out of mozilla, but rust is what google is using to make android safer, and to create things like kataos.
  - surajrmal 4y ago
    kataos is a greenfield project. Carbon isn't being created for greenfield applications, it's being created to deal with maintenance of large existing c++ projects. The carbon repo publicly mentions that you are better off using rust otherwise. Using rust in android is indeed interesting, but it's largely not hindered by legacy interop with c++ there either. Rust has struggled to overcome the challenges with c++ interop in chrome. I fear other c++ codebases face this same struggle.
    - galangalalgol 4y ago
      That makes a lot of sense. It is hard enough on small codebases. I'm very familiar with some c++98 behemoths and I can't think of any good ways to go about it piecemeal. The interop truly is painful.
- tialaramex 4y ago
  Carbon got one obvious thing right: Culture. The most important thing Rust has that C++ doesn't is the right culture and so it was correct to focus there very early. Unfortunately on the technical side it still feels as though the intent is to add safety, and IMNSHO that's not a good idea, you want to design safety in from principle, when it's layered on later the resulting joints and discontinuities always end up causing problems. On the other hand I am even less confident Cpp2/ CppFront has the right idea. There's no sign that Herb Sutter groks the culture problem and he's not as focused on safety, preferring to see this in part as a vehicle to give all Herb's rejected C++ proposals a second chance. As WG21 convenor and as an otherwise important person in the C++ community Herb has opportunities for Cpp2 that don't exist for Carbon, but if this language isn't enormously safer than C++ I don't see the point. Val certainly has the "from principle" thing. Like Rust there's a clear and articulable rationale for why this way to do things is safe. I don't know much about Val's culture, and of course like these other 2022 "successors" it's very young.
azhenley 4y ago
I really enjoyed reading about Austral, though it is still really early, that was discussed on HN this week: https://news.ycombinator.com/item?id=34168452 https://news.ycombinator.com/item?id=34168452
- Taikonerd 4y ago
  Agreed, Austral looks really cool, and the author's explanation of "what a linear type is and why we use them" was the clearest I've ever heard. I was surprised it uses an Ada-like syntax -- I thought the standard wisdom for new languages was to either imitate C or Python ;-)
kibwen 4y ago
Tip for blog authors: if you open your posts with apparently-sincere references to TIOBE, readers will immediately close the tab and conclude that your content is not worth reading. TIOBE is a joke, and has been for decades.
- masklinn 4y ago
  Also stating your affiliations and biases upfront rather than discreetely in the middle of the last section avoids readers assuming you're just shilling, or at least limits such whiplash.
jdlyga 4y ago
There is a much safer and simpler language hiding inside of C++ waiting to be discovered. If anyone can help reform the language, it's Herb Sutter with his cpp2 syntax. It's very much an experimental hero project, but it's promising: https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY
duped 4y ago
These quotes confused me: > The Rust language model is based around the so-called borrow checker, which tracks the lifetime of all the objects; thus, it can detect safety errors at compile-time and does not require the use of a garbage collector > Val solves this problem in an entirely different way: it adds restrictions to references, and ensures that nobody can read an object while somebody else is allowed to change it. Because this is exactly what Rust does (forbid multiple mutable aliasing). After reading the linked reference (1) the difference isn't the program structure but rather that Rust allows references in values whereas Val does not, which obviates the need for ownership semantics and borrow checking (since there are no borrows!). So my understanding is that both Rust and Val are providing the same guarantee to the program (exactly one writer or any number of readers to values) but choose to do it in very different ways. The interesting thing from the PL design side is that both implementations leak into the semantics of the language (Rust through explicit lifetime annotation, Val through implicit references). This is exactly the thing that other newer systems language designers seem to gloss over or not understand - you can't slap static analysis onto a compiler (takes like: "we can add optional borrow checking in the future") and get the same safety guarantees. That will only go so far, since more expressive semantics make the analysis impossible. (1) https://www.jot.fm/issues/issue_2022_02/article2.pdf https://www.jot.fm/issues/issue_2022_02/article2.pdf
- charcircuit 4y ago
  Rust didn't originally have borrow checking. It was bolted on later.
  - estebank 4y ago
    This is technically true, but somewhat misleading. The borrow checker was added pre1.0, and originally wasn't known to be possible to rely on it exclusively for memory management. It was bolted on later, but it changed the language so much that if Rust had been 1.x, after the change we'd be calling the current iteration of Rust "2.0". As such, any production ready language that attempts the same gambit will have to be ready for a painful split that would make the Python 3 migration look like a walk in the park.
MoscMob 4y ago
It was obviously a click-bait as half-way through the article it was clearly written to promote Val, a language practically no one has heard of as compared to Carbon and CPP2. The click-bait worked. Val looks like a real contender, but now I'm forced to ignore it because of the dishonest means by which I was introduced to it :)
- MoscMob 4y ago
  Oh, another thing. There is nothing about Val that places it as a successor of C++ in any way. A C++ successor language starts by supporting interoperability with C++, at the source level. It didn't even attempt to do this. This just looks like someone who likes Val wants it to be considered as a successor to the language, and not be overshadowed by CPP2 and Carbon. My absolute favorite part of the article, which I'm going to steal in the future, is the disclaimer that translates any future failure of Val to a success: "if Val dies as a programming language but all its ideas are incorporated in C++, then I will be delighted." pahleeze
  - michaelmrose 4y ago
    Why would a proposed successor language require compatibility with c++ source? Logically a successor is one in which you write future projects in not one which all existing code must compile now else you'd be stuck with the same tech in 2100 as 1980.
  - duped 4y ago
    I don't think your last paragraph is a fair criticism. That's more or less how PL research is conducted.A feature of a PL is successful if it escapes the lab, not if the research language it was implemented in gets popular in industry. The latter is quite rare while the former just takes a long time, which is why industry lags academia so much.
  - neonsunset 4y ago
    You explicitly don’t need direct source level interoperability with C++. The language just has to become the primary choice in the domains C++ used to be one. Rust appears to fit this definition quite well.
npigrounet 4y ago
[dead]

176 points by nikbackm 4y ago

Article fails to mention that autocxx and crubit are aiming for much improved interop between Rust and C++. Sure they're experimental, but not more so than Val. Rust devs are also pushing for making more of its core and std library "unsafe" friendly, to reduce the risk of unsound calls to Safe Rust from an unsafe environment with possible aliasing, pinned-in-place objects, self-references, uninitialized ("write-only") memory etc. etc. So that in itself will also deliver improved semantics between Rust and C++.

c-cube 4y ago
It's pretty strange. Rust is dismissed because interop with C++ is hard, but then Val is cheered on despite its C++ interop basically being a big "todo" item.
- epolanski 4y ago
  Author admits his own bias and preference at the end.
  - ModernMech 4y ago
    > I do need to confess: in my spare time, I have started working with the Val team Indeed, I think this should have been made clear in the first section. I thought when the author said they have a bias it was more in the general sense, not that they are working on one of the languages in question.
    - MoscMob 4y ago
      Yes, misleading.
- sli 4y ago
  Also just saying a language's C++ interop is better simply because it's easier doesn't really pass the smell test for me. If I need to write some interop for a C++ library, I'm going to prefer one that's more reliable than one that's easy but can fail in weird ways. And unless my project is an interoperability library, I'm not sold on "harder = worse" when I'm most likely going to write the interop once, ever, and be done with it. If it takes me a day, but then I can rely on it to function well and fail in predictable ways, I'm still on board. There's nothing wrong with something being difficult if the result removes a ton of mental load. I'm not a fan of this article's conclusions at all.
  - scaredginger 4y ago
    Not to mention efficiency. Sure, it's 'easier' to make a copy of all the data when crossing the FFI boundary
Ambroisie 4y ago
Can you explain what you mean, about unsafe friendliness in the standard library?
- ysleepy 4y ago
  I believe this is referring to the interop abi that is in planning. It aims to expose a nicer way to glue rust idioms to similar or equivalent idioms in other languages. https://github.com/rust-lang/rust/pull/105586 https://github.com/rust-lang/rust/pull/105586
  - SirGiggles 4y ago
    Not the poster of the comment but I'd like to hear from the downvoter why this was downvoted. As a Rust novice, interpreting the comment GP made (from the perspective of, for example, C++ calling Safe Rust core or stdlib) this seems like a valid response.
    - SirGiggles 4y ago
      Would the downvoter like to comment as to why I too got downvoted?

eps 4y ago

https://web.archive.org/web/20230102100639/https://accu.org/journals/overload/30/172/teodorescu/ https://web.archive.org/web/20230102100639/https://accu.org/... Val: https://www.val-lang.dev/ https://www.val-lang.dev/ Carbon: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang CppFront: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront

linuxftw 4y ago
Great talk on CppFront given recently at cppcon: https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY
tialaramex 4y ago
That Val site provides the following example, which makes no sense to me: public fun main() { let weight = 1.0 print(weight) // 1.0 let length = 2.0 print(length) // 1.0 } Is the behaviour of print "Just print whatever the first variable was forever" ? Is this example wrong ?
- sli 4y ago
  That is almost certainly just a typo. That example is meant to help explain Val's lifetimes in the most basic possible way.
- ngrilly 4y ago
  I wondered the same. I also guess this is a typo.

flohofwoe 4y ago

It's 'interesting' that the author critices Go for having a GC making it 'inappropriate' as a system programming language, but then also critices Go for not having exceptions (which are IMHO at least as 'inapproriate' for that type of language). If anything, the latest round of systems programming languages which all use error unions instead of exceptions have demonstrated quite clearly that exceptions are actually quite pointless.

zozbot234 4y ago
Go does have exceptions, via panic/recover. You could argue that Rust lacks true exceptions because a Rust panic can be configured to be fatal at the whole-program level. (Which is actually great for deep-embedded scenarios where even C++ use is with no-exceptions support.)
- usrnm 4y ago
  Yeah, it's funny how go does have exceptions, but no notion of exception safety. Manual mutex locks/unlocks are everywhere, and don't even start me on defer, which is just terrible
  - mike_hock 4y ago
    That's how you get a "simple" language.
- IshKebab 4y ago
  Those are not exceptions by most reasonable definitions. Exceptions are a general purpose error handling method. Try, catch and all that. They are almost always objects with multiple types. Go and Rust's panic is for unrecoverable errors. They both have the ability to catch panics because sometimes you really need to do that (e.g. when interacting with FFI or sometimes multithreaded code). They are not exceptions though. I've seen this myth repeated a few times lately (always about Go and not Rust for some reason) and I wish it would die. You wouldn't say C "has exceptions" would you?

uwuemu 4y ago

For me 2022 was the year of learning C++ (background in C# and Php) and I must say that after being intimidated by the language (extensive use of pointers, stack/heap compile/run time allocation and deallocation, templates) for years, when I really took a proper look and got some practice, it is an incredible language. The command an control you get by working with memory and the system on a lower level is amazing. I found it so much easier to learn (once I got the grasp of the cpp way of doing things) than something like Rust. All the higher level advanced concepts work and flow beautifully as you'd expect based on the lower level of the language... and the amount of "magic" is kept to minimum... you can just open std and look at what is being done and it all males sense. I understand why people want to move from C++ but as a newbie in this language, I find it amazing.

meindnoch 4y ago
Why was this comment flagged? C++ haters... really?
- alphanullmeric 4y ago
  [flagged]
  - Yoric 4y ago
    All the Rust programmers I know are really happy to discuss the limitations and shortcomings of the language. It's possible that the problem you're pointing at comes from the word "reddit" rather than "rust" :) Note: I've looked at the parent's comment history. The only one of them which was not a troll against Rust was a troll against the EU. I'll stop feeding the troll.
    - alphanullmeric 4y ago
      [flagged]
      - School-Cotton 4y ago

Longhanks 4y ago

...is not 2023.

mdp2021 4y ago

Sorry, I have only a sketchy idea of Zig: I understood it should have been a competitor? Why does the article writer in fact disregard it? The authors of Val state: > Our goals overlap substantially with that of Rust and other commendable efforts, such as Zig or Vale

flohofwoe 4y ago
Zig is usually seen as a 'better C', not as a 'better C++'. Whether this is actually the case is debatable though (some of Zig's features are 'leaking' into the territory of higher level languages such as C++ or Rust).
- fckgnad 4y ago
  I feel this viewpoint is pedantic. Zero cost abstractions is the space we're looking at and from this perspective, C and C++ are in the same space. If not then are we implying a successor to C++ needs to be Object Oriented? Because that's the main difference between C++ and C. Clearly the successor languages mentioned in the article do not have the same heavy OOP bias embedded into themselves as C++ and thus they all can be looked upon as successors to C as well. I think the goal here is just to find a language that does the whole "zero cost abstraction" thing better than the status quo.
  - c-cube 4y ago
    There are so many more differences between C and C++. Templates, RAII, type inference, lambdas, etc. These are the abstractions that try to be zero cost; C has little abstraction overall so it doesn't claim "zero cost abstraction". I don't think you need to be fully OOP to claim to be a C++ successor, but you definitely need to have decent zero cost abstractions, including a form of templates/generics. Having RAII might also be a requirement.
  - pjmlp 4y ago
    All the successor languages mentioned on the article have ways to provide methods and some form of polymorphism directly supported in the language, and not the OOP in C kind of kludge.

transfire 4y ago

Unless there is significant reason to avoid garbage collection (for the vast majority of software there isn’t) then Crystal is the best C++ replacement out there. Its Ruby syntax is easy to read and write, its OOP model derives from Smalltalk (via Ruby). And it has easy interop with C++ code.

anonymoushn 4y ago
Aren't users who are okay with GC already not using C++?
- p0nce 4y ago
  A lot of C++ software out there could afford to use a GC.
  - wiseowise 4y ago
    What’s wrong with RAII?
    - Rochus 4y ago
      nothing
    - Yoric 4y ago
      I can think of a few cases in which GC would really simplify things, both in C++ and in Rust. I want to do some serious D and Go (and Crystal?) some day to see how it changes life.
    - pebal 4y ago
      It is not a solution for all cases.
      - wiseowise 4y ago
        Care to give cases where it is not a solution?

rurban 4y ago

I miss pony, rune, nim, crystal and many more. rune has an explicit 'replace C++ in prod' goal.

auxym 4y ago
Indeed. And Nim has very good FFI with C++, including templates even.
chubot 4y ago
Hm I never heard of Rune, and I have heard of all the others (although this article gave me more info about Val): https://github.com/google/rune https://github.com/google/rune (side project, not Google project) This part is interesting, as I've found many benefits from having a layer of indirection between the app-level data definitions, and the C/C++ struct level. I recall that Jai used to advertise the SoA -> AoS transforms but that was many years ago. It provides many of its features by deeply integrating the "DataDraw" tool into the primitives and constructs of the language. DataDraw is a code-generation tool that generates highly-optimized C code which outperforms e.g., the C++ STL given a declarative description of data-structures and relationships between them. For more information, see the DataDraw 3.0 Manual. I've never heard of DataDraw either .. I wonder who uses it?
- gavinray 4y ago
  I can field questions folks might have on DataDraw. I'm not Bill, but I wrote the docs PR that recently overhauled the Rune README to highlight a lot of this interesting info about its use of the DD tool. Another neat thing about DD -- the Rune compiler/grammar itself are written as DataDraw types. All user-defined classes/types are compiled under the hood into DD types. One of the builtin things you can do is generate PostScript visualizations of them. Check this out: https://github.com/google/rune/pull/33#issuecomment-1355828317 https://github.com/google/rune/pull/33#issuecomment-13558283...

zer0zzz 4y ago

Very little discussion of swift and how the current work on C++ Interop is in many ways a peak into what carbon and others may be in several years.

awesomegoat_com 4y ago

And the next year will be the year of THE Successor Language And that's (of-course, hands down) zig. Thank me later. :-) Jokes aside, I really like where zig is headed. As a gambler, I am willing to bet on zig over val any time and twice on Mondays.

FpUser 4y ago
Zig is really nice language with some good concepts. However it is not a successor to C++.

de_keyboard 4y ago

I am very bullish on Carbon. Using C++ semantics will make switching and integration much easier.

galangalalgol 4y ago
Its abstractions and memory safety aren't zero cost though. I do wish ffi between rust and c++ was easier, having just fought that battle again recently, but I'm not willing to give up performance over it. I think it is telling that carbon came out of google, and rust came out of mozilla, but rust is what google is using to make android safer, and to create things like kataos.
- surajrmal 4y ago
  kataos is a greenfield project. Carbon isn't being created for greenfield applications, it's being created to deal with maintenance of large existing c++ projects. The carbon repo publicly mentions that you are better off using rust otherwise. Using rust in android is indeed interesting, but it's largely not hindered by legacy interop with c++ there either. Rust has struggled to overcome the challenges with c++ interop in chrome. I fear other c++ codebases face this same struggle.
  - galangalalgol 4y ago
    That makes a lot of sense. It is hard enough on small codebases. I'm very familiar with some c++98 behemoths and I can't think of any good ways to go about it piecemeal. The interop truly is painful.
tialaramex 4y ago
Carbon got one obvious thing right: Culture. The most important thing Rust has that C++ doesn't is the right culture and so it was correct to focus there very early. Unfortunately on the technical side it still feels as though the intent is to add safety, and IMNSHO that's not a good idea, you want to design safety in from principle, when it's layered on later the resulting joints and discontinuities always end up causing problems. On the other hand I am even less confident Cpp2/ CppFront has the right idea. There's no sign that Herb Sutter groks the culture problem and he's not as focused on safety, preferring to see this in part as a vehicle to give all Herb's rejected C++ proposals a second chance. As WG21 convenor and as an otherwise important person in the C++ community Herb has opportunities for Cpp2 that don't exist for Carbon, but if this language isn't enormously safer than C++ I don't see the point. Val certainly has the "from principle" thing. Like Rust there's a clear and articulable rationale for why this way to do things is safe. I don't know much about Val's culture, and of course like these other 2022 "successors" it's very young.

azhenley 4y ago

I really enjoyed reading about Austral, though it is still really early, that was discussed on HN this week: https://news.ycombinator.com/item?id=34168452 https://news.ycombinator.com/item?id=34168452

Taikonerd 4y ago
Agreed, Austral looks really cool, and the author's explanation of "what a linear type is and why we use them" was the clearest I've ever heard. I was surprised it uses an Ada-like syntax -- I thought the standard wisdom for new languages was to either imitate C or Python ;-)

kibwen 4y ago

Tip for blog authors: if you open your posts with apparently-sincere references to TIOBE, readers will immediately close the tab and conclude that your content is not worth reading. TIOBE is a joke, and has been for decades.

masklinn 4y ago
Also stating your affiliations and biases upfront rather than discreetely in the middle of the last section avoids readers assuming you're just shilling, or at least limits such whiplash.

jdlyga 4y ago

There is a much safer and simpler language hiding inside of C++ waiting to be discovered. If anyone can help reform the language, it's Herb Sutter with his cpp2 syntax. It's very much an experimental hero project, but it's promising: https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY

duped 4y ago

These quotes confused me: > The Rust language model is based around the so-called borrow checker, which tracks the lifetime of all the objects; thus, it can detect safety errors at compile-time and does not require the use of a garbage collector > Val solves this problem in an entirely different way: it adds restrictions to references, and ensures that nobody can read an object while somebody else is allowed to change it. Because this is exactly what Rust does (forbid multiple mutable aliasing). After reading the linked reference (1) the difference isn't the program structure but rather that Rust allows references in values whereas Val does not, which obviates the need for ownership semantics and borrow checking (since there are no borrows!). So my understanding is that both Rust and Val are providing the same guarantee to the program (exactly one writer or any number of readers to values) but choose to do it in very different ways. The interesting thing from the PL design side is that both implementations leak into the semantics of the language (Rust through explicit lifetime annotation, Val through implicit references). This is exactly the thing that other newer systems language designers seem to gloss over or not understand - you can't slap static analysis onto a compiler (takes like: "we can add optional borrow checking in the future") and get the same safety guarantees. That will only go so far, since more expressive semantics make the analysis impossible. (1) https://www.jot.fm/issues/issue_2022_02/article2.pdf https://www.jot.fm/issues/issue_2022_02/article2.pdf

charcircuit 4y ago
Rust didn't originally have borrow checking. It was bolted on later.
- estebank 4y ago
  This is technically true, but somewhat misleading. The borrow checker was added pre1.0, and originally wasn't known to be possible to rely on it exclusively for memory management. It was bolted on later, but it changed the language so much that if Rust had been 1.x, after the change we'd be calling the current iteration of Rust "2.0". As such, any production ready language that attempts the same gambit will have to be ready for a painful split that would make the Python 3 migration look like a walk in the park.

MoscMob 4y ago

It was obviously a click-bait as half-way through the article it was clearly written to promote Val, a language practically no one has heard of as compared to Carbon and CPP2. The click-bait worked. Val looks like a real contender, but now I'm forced to ignore it because of the dishonest means by which I was introduced to it :)

MoscMob 4y ago
Oh, another thing. There is nothing about Val that places it as a successor of C++ in any way. A C++ successor language starts by supporting interoperability with C++, at the source level. It didn't even attempt to do this. This just looks like someone who likes Val wants it to be considered as a successor to the language, and not be overshadowed by CPP2 and Carbon. My absolute favorite part of the article, which I'm going to steal in the future, is the disclaimer that translates any future failure of Val to a success: "if Val dies as a programming language but all its ideas are incorporated in C++, then I will be delighted." pahleeze
- michaelmrose 4y ago
  Why would a proposed successor language require compatibility with c++ source? Logically a successor is one in which you write future projects in not one which all existing code must compile now else you'd be stuck with the same tech in 2100 as 1980.
- duped 4y ago
  I don't think your last paragraph is a fair criticism. That's more or less how PL research is conducted.A feature of a PL is successful if it escapes the lab, not if the research language it was implemented in gets popular in industry. The latter is quite rare while the former just takes a long time, which is why industry lags academia so much.
- neonsunset 4y ago
  You explicitly don’t need direct source level interoperability with C++. The language just has to become the primary choice in the domains C++ used to be one. Rust appears to fit this definition quite well.

npigrounet 4y ago

[dead]