TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The year of C++ successor languages

176 点作者 nikbackm超过 2 年前

16 条评论

duped超过 2 年前
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 未加载
eps超过 2 年前
<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 未加载
zozbot234超过 2 年前
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 未加载
flohofwoe超过 2 年前
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 未加载
MoscMob超过 2 年前
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 未加载
azhenley超过 2 年前
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 未加载
zer0zzz超过 2 年前
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.
rurban超过 2 年前
I miss pony, rune, nim, crystal and many more. rune has an explicit &#x27;replace C++ in prod&#x27; goal.
评论 #34218881 未加载
评论 #34217828 未加载
kibwen超过 2 年前
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_keyboard超过 2 年前
I am very bullish on Carbon. Using C++ semantics will make switching and integration much easier.
评论 #34221387 未加载
评论 #34219679 未加载
评论 #34222685 未加载
评论 #34222489 未加载
jdlyga超过 2 年前
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>
uwuemu超过 2 年前
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 未加载
Longhanks超过 2 年前
...is not 2023.
mdp2021超过 2 年前
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_com超过 2 年前
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 未加载
transfire超过 2 年前
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 未加载