TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The year of C++ successor languages

176 pointsby nikbackmover 2 years ago

16 comments

dupedover 2 years ago
These quotes confused me:<p>&gt; 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<p>&gt; 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.<p>Because this is exactly what Rust does (forbid multiple mutable aliasing). After reading the linked reference (1) the difference isn&#x27;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!).<p>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 <i>both</i> 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&#x27;t slap static analysis onto a compiler (takes like: &quot;we can add optional borrow checking in the future&quot;) and get the same safety guarantees. That will only go so far, since more expressive semantics make the analysis impossible.<p>(1) <a href="https:&#x2F;&#x2F;www.jot.fm&#x2F;issues&#x2F;issue_2022_02&#x2F;article2.pdf" rel="nofollow">https:&#x2F;&#x2F;www.jot.fm&#x2F;issues&#x2F;issue_2022_02&#x2F;article2.pdf</a>
评论 #34225687 未加载
评论 #34223857 未加载
epsover 2 years ago
<a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20230102100639&#x2F;https:&#x2F;&#x2F;accu.org&#x2F;journals&#x2F;overload&#x2F;30&#x2F;172&#x2F;teodorescu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20230102100639&#x2F;https:&#x2F;&#x2F;accu.org&#x2F;...</a><p>Val: <a href="https:&#x2F;&#x2F;www.val-lang.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.val-lang.dev&#x2F;</a><p>Carbon: <a href="https:&#x2F;&#x2F;github.com&#x2F;carbon-language&#x2F;carbon-lang">https:&#x2F;&#x2F;github.com&#x2F;carbon-language&#x2F;carbon-lang</a><p>CppFront: <a href="https:&#x2F;&#x2F;github.com&#x2F;hsutter&#x2F;cppfront">https:&#x2F;&#x2F;github.com&#x2F;hsutter&#x2F;cppfront</a>
评论 #34222977 未加载
评论 #34219013 未加载
zozbot234over 2 years ago
Article fails to mention that autocxx and crubit are aiming for much improved interop between Rust and C++. Sure they&#x27;re experimental, but not more so than Val.<p>Rust devs are also pushing for making more of its core and std library &quot;unsafe&quot; 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 (&quot;write-only&quot;) memory etc. etc. So that in itself will also deliver improved semantics between Rust and C++.
评论 #34218217 未加载
评论 #34216887 未加载
flohofwoeover 2 years ago
It&#x27;s &#x27;interesting&#x27; that the author critices Go for having a GC making it &#x27;inappropriate&#x27; as a system programming language, but then <i>also</i> critices Go for not having exceptions (which are IMHO at least as &#x27;inapproriate&#x27; for that type of language).<p>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.
评论 #34216759 未加载
评论 #34216531 未加载
评论 #34216566 未加载
评论 #34216541 未加载
评论 #34217059 未加载
评论 #34222892 未加载
MoscMobover 2 years 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&#x27;m forced to ignore it because of the dishonest means by which I was introduced to it :)
评论 #34222776 未加载
azhenleyover 2 years ago
I really enjoyed reading about Austral, though it is still really early, that was discussed on HN this week: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34168452" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34168452</a>
评论 #34220144 未加载
zer0zzzover 2 years 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.
rurbanover 2 years ago
I miss pony, rune, nim, crystal and many more. rune has an explicit &#x27;replace C++ in prod&#x27; goal.
评论 #34218881 未加载
评论 #34217828 未加载
kibwenover 2 years 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.
评论 #34243689 未加载
de_keyboardover 2 years ago
I am very bullish on Carbon. Using C++ semantics will make switching and integration much easier.
评论 #34221387 未加载
评论 #34219679 未加载
评论 #34222685 未加载
评论 #34222489 未加载
jdlygaover 2 years 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&#x27;s Herb Sutter with his cpp2 syntax. It&#x27;s very much an experimental hero project, but it&#x27;s promising: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ELeZAKCN4tY">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ELeZAKCN4tY</a>
uwuemuover 2 years 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&#x2F;heap compile&#x2F;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&#x27;d expect based on the lower level of the language... and the amount of &quot;magic&quot; 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.
评论 #34216748 未加载
评论 #34217323 未加载
评论 #34216732 未加载
评论 #34224637 未加载
评论 #34221924 未加载
评论 #34216610 未加载
评论 #34221072 未加载
Longhanksover 2 years ago
...is not 2023.
mdp2021over 2 years 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?<p>The authors of Val state:<p>&gt; <i>Our goals overlap substantially with that of Rust and other commendable efforts, such as Zig or Vale</i>
评论 #34216625 未加载
评论 #34217157 未加载
评论 #34217118 未加载
awesomegoat_comover 2 years ago
And the next year will be the year of<p><pre><code> THE Successor Language </code></pre> And that&#x27;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.
评论 #34218137 未加载
transfireover 2 years 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.
评论 #34217178 未加载
评论 #34222356 未加载