SubjectToChange

I don’t see how running into an OOM problem is necessarily a problem with the GC. That said, Java is a memory intensive language, it’s a trade off that Java is pretty up front about.

I don’t have a horse in this race but I would be quite surprised if Go’s GC implementation could even hold a candle to the ones found in C# and Java. They have spent literally decades of research and development, and god knows how much money (likely north of $1b), optimizing and refining their GC implementations. Go just simply lacks any of the sort of maturity and investment those languages have.

What is your opinion on spam email?

Calling RDBMSs “useful” is quite the understatement. They are among the most commercially successful software products of all time, and the theory backing them has endured with us for over 50 years now.

BTW the question I asked was about querying data without ever using a SQL language, like tapping directly into the data. Of course a DB system is not designed to be used like this, but to me, it should, or at least there should be better alternative to SQL.

This approach has been tried over and over again with little success to show for it. Considering that a good number of working programmers would be hard pressed to recall what ACID even stands for, much less with any rigor, you have to ask yourself if you really want to entrust valuable data to them. Furthermore, mucking around with low level storage and access patterns adds tremendous amount of work to development, it is very unpleasant.

I disagree with it in the sense that I disagree with the statement "A human will always be able to write the same or better assembly than a C compiler, because humans can learn the compiler's tricks and make optimizations which the compiler is not allowed to make." It's a true statement, but it's so detached and irrelevant that it hardly matters.

Generic code has proven itself time and time again, even Go caved in and supported it.

There isn't really any fundamental limitation of Rust for those situations. A better reason why C++ is better than Rust for compute is the support for OpenACC, OpenCL, OpenMP, CUDA, ROCm/HIP, etc.

Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department.

The problem is that even if a "Safe" C++ could be defined, it would need to interoperate with the rest of the "Unsafe" C++ world. Perhaps a programmer can write absolutely safe C++ themselves but all bets are off once you're working with other programmers.

Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.

Seriously? A "couple of valgrind tests" would be insufficient for catching all but the most trivial and/or blatant memory safety issues in C++, especially when dealing with malicious users. Although I agree that dynamic analysis like valgrind and sanitizers should be the default for C++ development, industrial grade static analysis tools are at least as important. And needless to say, if you find Rust complains about code too much then just wait for what static analysis tooling will complain about.

It would be better to say that "Metalness" is a sort of "Feature Set". IMO, most programmers would tend to agree that C++ is far closer to Java than C is, yet C++ is every bit as low level as C is. Indeed, even a managed language like C# supports raw pointers and even inline assembly if one is willing to get their hands dirty.

A library author can spend ridiculous amounts of time refining and optimizing their implementations, far more than any application programmer could afford or justify.

The designers of a generic library can't anticipate the use case, so can't make appropriate tradeoffs.

This is definitely not true. Take C++ for instance, not only is it possible to specialize generic code for particular types, but it's absolutely routine to do so. Furthermore, with all sorts of C++ template features (type traits, SFINAE, CRTP, Concepts, etc) even user-defined types can be specialized, in fact it's possible to provide users with all sorts of dials and knobs to customize the behavior of generic code for their own use case. This functionality is not just a quality-of-life improvement for library users, it has profound implications for performance portability.

For example, compare `std::unordered_map` to any well written C hash table.

std::unordered_map is a strawman. There are a plethora of generic C++ hash tables which would match, if not soundly outperform, their C counterpart. Also, even if we blindly accepted your claim, then how do you explain qsort often being beaten by std::sort or printf and its variants being crushed by libfmt? What about the fact that Eigen is a better linear algebra library than any alternative written in C?

Personally I would like to see a native language which attempts to acknowledge and work with disjoint and/or "far away" address spaces. However the daunting complexity of such a feature would likely exclude it from any portable programming language.

C++ has constructors, it doesn’t really need designated initializers in the first place. They were added primarily for C compatibility.

Reading the initial working versions of a successful project will inform you on how that project used to work. In a sense it’s akin to reading a working draft of a great piece of literature without reading the final product.

This is exactly what Go does. Languages like C++ or Rust make it possible to expose and interact with those complex requirements, whereas Go takes it away in the name of “simplification”. Just look at all of the insane hacking tailscale does on Go to make it work for them.

Apple just doesn’t like making solid commitments to outsiders, especially for something as mundane as legacy support. They want to mold swift into anything they want/need.

"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike

Ignoring complexity on the language level simply passes the buck to application code, and developers end up paying that price across the ecosystem in perpetuity.

They've also kept a laser sharp focus on working on things that really matters and took the time to do things right.

Go's async model is underspecified, its implementation of generics incurs runtime overhead, much of the "wonderful tooling" only exists because of severe shortcomings in the language design and/or compiler implementation, its FFI is... difficult, etc.

To be blunt, the values that Go embraces are none of the values I seek in a programming language or community. And I feel sorry for anyone too heavily invested in Go to turn back.