虽然说没有银弹，但是我感觉 c++完全可以设计成更友好，开发速度更快的语言

举个例子？

更友好的 c++，是在说 rust 吗

我想确认一下你的意思，因为你没说清楚，你是指：

A 、让带着非常沉重的历史包袱的 C++ 吸收别的语言的优点，对已经被不断魔改的 C++再继续改改改。

还是 B 、创造一个新语言，以现代 C++为基础（抛弃历史包袱，比如不考虑兼容 C 语言），同时吸收其他语言的优点。

是哪个？

dlang: 你好

rust: 起开， 正是在下

你是需要 Java 吗？

这句话有点像是 “我感觉汇编完全可以设计成更友好，开发速度更快的语言”

说起来可能你们不信，我已经在 CPP 文件里偷偷加了 JSX 关键词，全部源代码通过 preprocessor 处理一次后再走编译流程。

而预处理模块就是负责读取 JSX 部分的 XML 模板，再转换为 HTML 节点。

@cmdOptionKana
细想一下 我的想法是比较偏向于 B，A 肯定是实现不了了，C++到 23 已经快走火入魔了，B 的话，估计有人会推荐一些例如楼上楼下说的 rust dlang 啥的....然而平心而论，这些玩意感觉还不如 C++呢，别的不说，就那高(鬼)级(畜)的语法就让人望而生却

@zxCoder B 肯定可以，但放弃历史包袱就要同时放弃几十年积累起来的生态，一个好语言，达到 C++的质量需要投入极多资源，然后生态何年何月能建立起来还前途未卜。

java 吧，除了性能其他都可以了

我觉得 C++就是瑞士军刀，什么都有，但是不代表什么都得用。

我是支持 CPP 走一条新的路线的，CPP 现在的做法让我觉得是不可持续的。

改了这么多版本，到 C++ 20 为止，对 UTF 的支持还是个笑话，网络库还是没有。反而是整了一堆语法糖，让人感觉学不完。

当然，毕竟 C++太老了，早些年 IDE 没这么发达，有些理念也不够先进，像 python23 一样断崖修改会有人骂，像 C++这样永远向前兼容也有人骂。 只能出个新语言干掉一部分 C++的地盘。

你是说 rust 还是说 C++23 ？但是最后你不是还得回来写 plain old C++吗。

那我们来写 C 吧，简单却美

@inhzus C 我觉得除非必要（比如单片机编程），否则刚开始写觉得很爽了，写了一会就得自己造轮子了。

您是在说 Rust?

你说的好像就是 Java 。。。

还得是 Java 啊

Rust 更友好、开发速度更快？难道不是相反？
符合楼主说的显然是 C#。地球上不可能找出另一个特性比它更丰富的语言。

CLion + CMake + C++17 + https://conan.io/

相信我，爽到飞起。

说到特性丰富，Scala 默默路过。

不用操心内存就好了，兼容 C ？嗯，语法上兼容。但是总之基于 class 的面向对象永远滴神于是我们有了 Java

@zxCoder
看标题就有一堆 Rust 推荐, Rust 是不错, 不过确实也复杂...
我在关注 Jonathan blow 的 JAI 语言, 不过还得等段时间
https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

@wangxn 只要理解并接受了 rust 的所有权机制，rust 的曲线可谓是一马平川

'兼容'在软件开发中是很重要的

大 js 即将一统江湖

如果你需要用到其他语言那些各种特性，那说明 C++其实不太适合你的项目，C++现在没事干也是各种抄袭别的语言新特性，个人觉得路走偏了，C++的核心应用场景根本不是靠那些新增乱七八糟的特性能解决的

@dynastysea 其实那些特性都还挺重要（还嫌不够）。

就我所知很多大厂的 C++开发都是加了额外的强制限制，甚至是把 C++当成了 c with class 来用，总之就是避免太过灵活

@ipwx 比较好奇是什么业务一定要用到那些新特性

@dynastysea 也有很多不写业务的程序员啊

C++++ == C#

@wutiantong 我知道啊， 正是因为不写业务我才好奇，不用来写业务的 C++为什么要用到哪些乱七八糟的新特性

@dynastysea 主是写起来就需要。
----

我上半年写了个 3.5 万行的 C++ 项目，需要低延迟高性能。如果没用 C++17 估计得 5 万行了。

最常用的新特性：

1 、for (const auto& : ...)
2 、T&&，这能让我明确指定一些情况下不需要拷贝而是移动栈对象。（对高性能程序很重要）
3 、template <typename Args...>。我用了很多这个来简化写代码。
4 、template <typename Fn> void someWrapper(const Fn& fn)。这就是所谓的高阶函数，特别简化代码。
常见用法比如 void wrapError(const Fn& fn)
还有就是需要对不同 fn 的进行相似的初始化、返回值进行相似的操作。
5 、template <bool XXX> void f(...) { if constexpr (XXX) { } }。这个特别好用。因为有些分支在有些情况下是不运行的，你想要减少 latency，就用 constexpr 去直接暴力优化掉这些代码。（ constexpr 是编译期判断）
6 、std::unique_ptr, std::shared_ptr 。这不是新特性了。但是配合 T&& 和 std::move 就很好用。

上面这些都挺省我代码量的。一些其他零碎可能我用到的不够多就不记得了。

@dynastysea 还有，一开始就考虑 C++ 是因为 Java/C# 这些带 GC 的语言有 GC 延迟。而我这里需要非常确定性的低延迟执行时间，又是各种多线程的，所以只能配合 shared_ptr 用 C++ 了。

@janus77 现在还在质疑 java 性能就落后了：半解释半编译，热点代码即时编译，可以说运行时间越长速度越快，跟 C 和 C++ 没什么差别

现在的大系统都是多语言的了 只能说单一语言更适合某个模块

@ipwx #37 Java ZGC 可实现最大 STW 时间 0.05ms

@frankHB

@ipwx 那感觉你的要求 rust 完全满足啊，快来搞 rust 吧

本身就不是什么“现代”编程语言。

@dqzcwxb 太慢。我的需求是每个事务稳定的低延迟，到 1ms 以及以下量级。有些地方我日后可能还得考虑做无锁，因为内核调用 20us，不太能接受。

@Austaras ummm 生态问题吧。至少 conan.io 上 c++库随便搜。还有就是我挺熟 c++

@dqzcwxb 啊看错了一个单位。0.05ms 确实挺厉害，不过我这边也没有 jvm 大神不懂这些

@dqzcwxb 呃我查了一下，zgc 最大停顿是 10ms 啊，不太行。我这边要求每个请求都非常稳定低延迟，这不是概率问题，是全部都要。

能不能做一个 C++ 的子集，然后搞个 gc 功能

不要说 golang

@ericgui 好，那就 ponylang （

很难搞吧

Java 在设计字符类型的时候用了两个字节，当时两个字节完全够了，但是没想到字符集后面会扩充到这么大一坨，所以后面的版本只能增强实现而不是推倒重来，更别说 C++这种需要完全兼容 C 的了。

@ericgui 其实 shared_ptr 很好用，相信我。

@ipwx 确实好用，只是是微软家的 debug 版本百倍慢比较拉胯

需要友好的 C++ 请学习 Rust，需要开发速度更快的 C++ 请学习 Go

我认为 c#符合你的需求 性能和 c++没有数量级的差距 语法又十分友好

还是用 go 吧，我是 go 吹

@janus77 其实 Java 性能也差不到哪里去，同样的最优逻辑的前提下，性能差异其实并不多。至少没有量级上面的差距。

@abcbuzhiming 是的语言太过于灵活就会变得不可控，跟 js 一样会进行很多编程规范或者限制来避免花里胡哨的。
@likefly 哈哈 JVM 说实话，JIT 后性能飞起，这并普通人写的 C++ 项目能比的，但是他们不懂、
@keepeye 低端语言，跟大 java 比不了，也跟 C# 比不上。跟 js，python 可以比下。go 只不过那些个人喜欢，团队要不得这样的语言进行开发，太拉胯了。连 class 都没有，只有一个结构体，写出来的东西全是面向过程，函数式编程之类的。非常有限。

@xuanbg 差不差那要看什么样的项目，要是都 curd 确实差不了多少，但是如果是追求性能的项目，比如数据库高性能网关，或者算法类项目，那性能差距好几个数量级

我是一枚写了多年的 C++的程序员，C++20 发布之后，感觉我已经看不懂 C++了。

我之前也写过 Javascript，对 Javascript 里面的 promise 机制还算熟悉。但是，我在看 C++20 里面的 coroutines 的时候，真的看了好久都没看懂。

大佬们来搞 go + rust，这两加起来能搞定很多东西了

@YUCOAT 老哥，C++ coroutines 是个半成品啊，面向库作者的。就好像只教了你极限的概念，却不教你怎么用微积分，这看得懂才怪。我又不想 contribute to boost，那我选择等一等。

一句话就是，c++路走偏了，而且越走越偏。一大堆语法糖

后端 golang，PC+手机（ iOS/Android ）用 flutter ；体验还是很好的哈

@ipwx 能举几个 crates.io 上没有的例子吗？

同意，那为什么 C++就不能学习下 Python2 -> Python3，强行变道。

@Austaras ummm 我又不熟 Rust，我怎么和你讨论这个问题。

反正前段时间我找 lock-free non-blocking mpmc queue 的时候，github 资料很多，论文也是用 C++ 写的。Rust…… 它太新了啊，这种偏门玩意儿万一找不到怎么办呢？对吧。

@Austaras 哦我知道了。我项目用了个类似 NumPy 的 C++ tensor template library 。

https://github.com/xtensor-stack/xtensor

这个 Rust 估计不太行。别的不说，这个库超级依赖 C++ template metaprogramming，在接口一致的情况下可以分情况自动使用 simd 。

rust+1!

rust 不如 c 优美，但 c 又过于简陋了。

@ipwx 听起来有点像交易系统

@ipwx 盲猜量化交易或者对接了柜台系统

c++ 2a

@ipwx #47 JDK 16 中的 ZGC：平均暂停时间 0.05 毫秒 - Glavo 的文章 - 知乎
https://zhuanlan.zhihu.com/p/359249269
知识需要更新

@ipwx lock-free non-blocking mpmc queue: https://github.com/crossbeam-rs/crossbeam
numpy: https://github.com/rust-ndarray/ndarray
Rust 的 proc macro 比 C++ template 强多了, 别的不说, c++的 json 库一个比一个难用, 和 serde+serde_json 根本没法比

更友好，开发速度更快 是可以

但是 zero-cost abstraction 怎么办？明明这才是 c++的立足之本


虽说零开销本身肯定是过于理想化了，但直到今天世界上能有多少语言能做到写出一行代码你能确切估计开销，而且你有信心开销只会来自可控的自己产生的代码中的呢？



另外“更友好的 c++” 我不知道这些吹捧者是怎么想的，rust 想解决的 c++中最大的问题（对象生命周期）在今天 c++基本已经自行解决了，两个差不多复杂的怪物我至今没看到哪里能解释到底所谓的“更友好”从何体现。从 c 和汇编学上来的 c++我基本能搞清楚运行时都会发生什么，虚表、构造函数、空间分配、ABI，这些东西在汇编上的反映写 c++的都心里有数。尽管 c++加入了非常多的编译期和语言特性，但运行时或者说成品机器码一直没怎么变（换了一套 ABI 但抽象的实现方式没变），我可以一边写抽象的容器模板一边考虑 CPU 缓存友好性，甚至能用 constraint 去约束这个容器的空间分配策略是缓存友好的。（比如要求空间连续，即要求实现随机迭代器这种方式）

可以说 c++虽然从复杂的怪物正在变成复杂的缝合怪物，但它逼近问题解决方案的“精神”其实没怎么变，只是绝大多数学过 c++的人还体会不到或者不需要这种求解方式而已。

@GeruzoniAnsasu 是的是的。因为过于熟悉这套我甚至忘了这才是 c++ 最值得称赞的东西，只记得用起来很好用。

不过楼上几个老哥说起的 Rust 不知道有没有这个特性，看上去好像也有点意思。

@ipwx mpmc queue 这个应该有的吧，crossbeam 用得非常广泛

@GeruzoniAnsasu 谁告诉你 rust 不是 zero cost abstraction 的。。。借用 rust 团队里一个人吹逼的话，给一段 llvm ir，他可以人肉还原成 cpp 或者 rust

此外生命周期的问题不要以为用了几个智能指针就算解决了

Swift 照理说是一个很有优势的语言，同样是静态强类型，无 GC，基于 LLVM，但性能还是被 Rust 吊打..

@agagega 我感觉 Swift 没发展起来是生态问题，大部分 Swift 开发者都是用来开发 macOS 和 iOS 应用的，写出来的代码很难跨平台。C# 也有类似的问题。

Swift 和 C#真的非常可惜

@xupefei 是 fp 吗

@GeruzoniAnsasu

个人看法，一人就能把 C++新特性玩的好，那当然好。

问题在于工程开发不是一个人的事，C++这样很难协调起来，这样我还不如一起去用 C，成本可能会更低

@Austaras 就是因为 rust 跟 c++在抽象实现上没什么优劣差异，学习成本又一样高，它想“推翻”的 c++痼疾又不一定需要真的重新来过，所以我就没感到 rust 到底颠覆在哪

Java 、C#、PHP 、Python，是你快饿死了，然后直接美团里点单，半个小时到 1 个小时内能解决用餐问题，属于快餐。

C 、C++、汇编，是你想吃什么，从食材、厨具、烹饪手法开始入手，精细化处理，有时一款食材的处理都要大半天，能做出最适合你口味的美味食物。

每款语言的定位都不一样，术业有专攻。

@GeruzoniAnsasu 就比如 c++里经典错误，一个重载函数签名有 int foo(bool a)和 int foo(std::string b)，请问 foo("abc")调用哪个版本。c++语法中就有很多陷阱，因此非常依赖 more more more effective c++之类的最佳实践。
如果让新手写 c++，出来的代码可能能编译能跑，但实际上却有存在内存错误或 UB 等等潜在问题，算不算友好呢。rust 除了强制所有权、引入了抽象数据类型(Option 、Result)等，我觉得最大的优势就是能编译的时候检查许多内存错误，只要改到编译器通过就行。

@ipwx 36 楼
您好我想请教一下，究竟用 unique_ptr 还是 shared_ptr，这个是必须在写程序之前就考虑好的是吗？有好几次我想用，但是总觉得根据自己的水平没法考虑清楚，就干脆还是裸指针算了。

@levelworm 我自己是 unique_ptr 随便用，这个是没有额外开销的。shared_ptr 基本不用，要用时得看需求。

@ysc3839 多谢！

lambda 函数的加入，是巨大的进化，但是 coroutine 实在无法接受

task resuming_on_new_thread(std::jthread& out) {
std::cout << "Coroutine started on thread: " << std::this_thread::get_id() << '\n';
co_await switch_to_new_thread(out);
// awaiter destroyed here
std::cout << "Coroutine resumed on thread: " << std::this_thread::get_id() << '\n';
}

结果

Coroutine started on thread: 139972277602112
New thread ID: 139972267284224
Coroutine resumed on thread: 139972267284224

看起来简单的打印线程 id 的代码，在同一个函数作用域的不同位置，竟然结果不一样，这让我以后可咋读代码啊。

需要手动管理内存上 rust，不需要找个现代语言写就行了。

@gBurnX 话虽如此，但我总觉得这两类之间可以不用分的这么清

比如能不能我也是从食材，厨具，烹饪手法都自己入手细调，但最终又不需要我自己实际动手，美团会给我做好送来

听起来有点离谱，但是总感觉这是一个正确的方向

如果你真的理解的银弹的概念你就不会纠结于语言了

@likefly 性能不落后，但相对底层语言就落后一些了，还有明显的缺点，linkerd 的 proxy 不就因为一些原因抛弃了 java 吗，还错失了市场，最后重构，java 和 c 或 c++就不是一类场景的

@iceheart Go 也是一样的，这是 co routine 的本质所在，也是优点。

@iceheart @wangxn C++20 的 coroutine 和 Go 的 goroutine 是不一样的，前者是无栈协程，后者是有栈协程。
前者可以像回调函数那样使用，具体在哪恢复执行是没有限制的，你可以实现一个单线程的模型。

C++主要是标准太多，导致很不『标准』。

@likefly Java 速度确实不行，致命缺点就是第一次执行速度，虽然多次执行后 jit 能加快速度，提升至少 5 倍以上。但是你不能智网所有场景都是重复执行。

@GeruzoniAnsasu 因为真正的学习成本并不一样啊，一个人读了 trpl 就能写生产用的 rust 代码了，一个人要是只读了 cpp primer 你敢让他写生产用 cpp 吗。。。

我觉得 C++的问题是不同的人写出来的代码差异太大，有时候都跟两个语言似的。