Not true. China is definitely adopting AI more universally than western countries, and I have friends in China losing designing jobs due to AI. They remain optimistic as (1) the society typically doesn't blame the technology advancement (2) they switched to an AI powered content creator (fortune telling and meme videos) and continued to make money
> In countries like China (83%), Indonesia (80%), and Thailand (77%), strong majorities see AI products and services as more beneficial than harmful. In contrast, optimism remains far lower in places like Canada (40%), the United States (39%), and the Netherlands (36%).
Correct. As someone who maintain a 16-year-old C++ code base with new features added every day, The status quo is the best incremental improvement over deep copy semantics.
There are better choices if everything is built from scratch, but changing wheels from a running car isn't easy.
I have a close friend working in core research teams there. Based on our chats, the secret seems to be (1) massive compute power (2) ridiculous pay to attract top talents from established teams (3) extremelly hard work without big corp bureaucracy.
While I sort of agree on the complaint, personally I think the best spot of C++ in this ecosystem is still on great backward-compatibility and marginal safety improvements.
I would never expect our 10M+ LOC performance-sensive C++ code base to be formally memory safe, but so far only C++ allowed us to maintain it for 15 years with partial refactor and minimal upgrade pain.
There're hundreds of thousands of '3D worker' working behind the scene to create the 3D models for makeshift ads, and as far as I know many of them (including my high school mate) already got displaced by Midjourney and lost their job. This used to be a big industry but now almost entirely wiped out by AI.
Note that there's a more reader-friendly list with support for filtering by category at https://software.nasa.gov/ . Specifically I found DATA SERVERS PROCESSING AND HANDLING especially helpful for general SWEs. Here's a list of my personal picks:
- Shift: Self-Healing Independent File Transfer
- BASSHFS: Bash-Accessible SSH File System: SSHFS but without fuse dependency
- Ballast: Balancing Load Across Systems: load balance for SSH servers
It depends. O0 turns off a few trimming optimizations and could potentially causes more information (code or DWARF) to be included in the objects, which may eventually slow down the compilation. In our large code base, we found that -O1 works best in terms of compilation speed.
To anybody unfamiliar with recent progress, boost::unordered_flat_map is the fastest open-addressing hash map implementation in this field for C++. Coming out just several months ago, it outperforms absl::flat_hash_map and various other implementations benchmarked in https://martin.ankerl.com/2022/08/27/hashmap-bench-01/.
There's also a more blasphemy-ish approach of interop between C++ and Rust if the C++ code already have good Python bindings: C++ <=> Python <=> Rust. It's not bad as you may think. My company uses it to adapt C++ to Rust without rewriting the 40K LOC Pybind11 boilerplate. Going through the Python interpreter is definitely slower than a native call but perhaps <3x since we only rely on Python being a hosted + GC environment, plus it's much easier to express lifetime in Rust given that everything is managed on Python heap.
This reminds me of the -Wlifetime proposal, which provides similar checks but requires annotation of ownership at struct level (hence the check only applies to new structs):
the downside of this is that companies with locked compiler versions won't be able to use the static analysis tool. Up-to-date compiler versions, according to my observation, is more like a privilege of BigTech and startups. Tons of firms are still using the bundled compiler in RHEL and only upgrade every 3-5 years, though in this case the off-tree decision more likely came from the intent of bypassing compiler repo code reviews for faster iteration (very typical at BigTech when you need KR every quarter)
One of my recent project requires a fast awk implementation, and I tried frawk and got surprised by how robust it is. Although eventually we chose https://github.com/noyesno/awka for better native awk script compatibility, it's still wonderful to see a project incorporating recent advances of programming language implementation into the ancient awk.
The motivations in claims unfortunately don't apply to my case:
1. FFI boundary will likely to exist forever in a milions-of-line C++ codebase, especially when the behavior of this system is not possible to be formally specified / tested (e.g., depending on an unknown external system, or some behaviors specified in hundreds of pages "specs" full of jargons)
2. In the above case, when C++ code dominates the FFI cost would be signified as you need to call C++ routines frequently to achieve stuffs. For example, when every struct has some methods returning std::string the std::string needs to be targeted.
In our case, the primary motivation of Rust isn't its safety - we just use it for syntax sugars and ease of extensions (with proc macros).
My preference would be holding normal SPY and hedge the overweighted NASDAQ stocks with short NQ futures. In this way you only need to rebalance the NQ futures which benefits from 60/40 rule with better tax rate.
I guess running an alternative language in kernel is not very challenging. (I tried it two years ago and managed to run i8042 keyboard driver in WebAssembly on Qemu) The hard part is interoperability. Even in languages with automatic C header -> native prototypes conversion capabilities, many kernel features are still not properly handled, especially the macros. Status quo requires the user to manually extract wrappers which could be super tedious.