htfy96

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

https://hai.stanford.edu/ai-index/2025-ai-index-report

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%).

Note that most countries in the list are developed countries.

In a separate research at https://www.bloomberg.com/news/articles/2025-06-20/trust-in-... , people found that low income countries have higher trust in AI.

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.

Meanwhile VSCode's terminal still leaks Electron fds: https://github.com/microsoft/node-pty/issues/657

I get this proposal's rationale, but it seems that it would implicitly make fd leaks more prone in python programs

It raises the bar of 'professional 3D artist'.

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.

It appears that some of the links point to obsolete URL. Googling SequenceMiner points to https://catalog.data.gov/dataset/sequenceminer-algorithm

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.

A Tour of C++ for syntax, https://www.cpp-lang.net/tools/ for dev tools

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):

An example: https://github.com/llvm/llvm-project/blob/main/clang/test/Se...

More details can be found at https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-post...

Unfortunately it was never upstreamed according to https://github.com/mgehre/llvm-project/issues/98

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.

Or if you want just some minor additions, try Sun Oracle Type-7 keyboard which has ~10 keys (including Copy, Paste, Undo, Cut - perfect for Stackoverflow-oriented programming) on the left

https://en.m.wikipedia.org/wiki/File:Sun_Oracle_type-7_keybo...

Have you tried https://github.com/CLIUtils/CLI11 ? The subcommand example can be found at https://github.com/CLIUtils/CLI11/blob/master/examples/subco... . It can't generate man pages though

My favorite: Jazelle DBX (direct Java bytecode execution)

There are few times you'd join more than say 5 or 6 tables.

This is only true in new tech where data relationship isn't complicated. Any stored procedure in bank would contain joins with no fewer than that number of tables.

This article only tested two pages, each with millions of data. In corporate developments (and probably the original meaning of "joins don't scale" in the era of Oracle/MSSQL), it's usually the opposite - usually joining half dozen of tables, each with a few data, but their mappings and underlying relationship are usually not explicitly-defined, making joins across multiple tables super slow (RDBMS can only plan the query based on fundamental stats). In other words, joins now scale with table size, but still a challenge in terms of #tables

r/rust and users.rust-lang.org are informative and sensible when it comes to limitations. Twitter and, well, random programming discords are often full of cults

For caching mechanism, there's zapcc (https://github.com/yrnkrn/zapcc) which launches a background server at first compilation, and reuses instantiated template from the server in the following compilation. Sadly this project was discontinued.

This looks nice! https://jonas.github.io/tig/ is another command-line UI for Git with similar two-column layout.

git-fuzzy seems to also support two-column diff view which isn't in tig. Good job.

Curious if Intel BCD ops (https://en.wikipedia.org/wiki/Intel_BCD_opcode) are still a thing in today's SiMD world. Converting chars to BCD code then convert BCD to u32 sounds a little bit easier than this

Did anyone try the J2CL Java to Closure JavaScript transpiler (https://github.com/google/j2cl)? A side benefit of this is to completely eliminate Javascript vs Java joke