Or "Java is fine if your fingers aren't sore yet and if you don't mind the latency spikes for your interactive application or if you're basically programming like C with training wheels and less performance".
;-)
I'm using it in embedded devices and needed a few tight loops a week or two back. With a bit of work and a few odd contortions, I got it to compile to almost the exact type of C code I'd write by hand to run a fast inner loop using preallocated arrays, etc. It turns out that code wasn't noticeably faster than more idiomatic Nim code with a few tweaks to ensure move's were able to be used. So I ended up going back to the more readable/idiomatic version while still roughly doubling the overall speed.
The new `move` semantics with Nim's ARC system really do help make it easier to write fast code. Now I understand why the C++ ecosystem is so bullish on `move` in the C++ stdlib now. It really can take code which looks like straightforward C code but performs closer to painstakingly optimized C code. Mainly since it result in less copying of objects/structs and reducing the number of malloc's. Overall it means less effort to design a fast system.
UB in C has some unfortunate historic problems, and is _probably_ way too complicated. But UB per se is needed for a number of really important optimizations - for example, for array indexing using 32-bit integers you need to be able to assume that index-scaling operations (implemented as multiplications/shifts) don't overflow.
> null terminated strings
null terminated strings are like 10-50% space savers compared to string + length tuples for realistic strings (which are small). They're also easy to pass around and require no bikeshedding what's the best string type.
You can easily make your own type if you want (struct String { const char *buffer; int length; }) or you can just use C++ and one of the more terrible full featured string types with all sorts of badly matching built-in memory management and what not.
(By the way, the issue with SetLength() that I described in my other comment applies to Pascal Strings, too)
(Oh, and Pascal/Delphi also wants you to choose between PChar, String, AnsiString, WideString and what not, and for every little thing you're doing you need to locate and use the proper API for whatever string type you've chosen. Or you need to do conversions before the calls, with all the necessary implicit memory allocations. Enjoy!)
(Oh, this is basically how I achieved a 100x-1000x speedup in a module of a business application in a short Delphi stint. I converted the string data to chunk-allocated bytes with manually computed indexing - instead of allocating thousands of little strings and throwing them back and forth. That reduced the total application startup time (including a lot of code that I never touched) from minutes (in some cases) to something bearable (1-5 secs).
> with the attendant buffer overflows are not fundamental constants of low level programming
Of course they are. If you're not controlling bytes directly, and deciding about data layout and tradeoffs, I wouldn't call that low-level programming. YMMV. But - while my code is never fuzzed - it's been years since I've been bitten by a string bug. The importance of this stuff is way overblown, and knowledge and experience how to program with simple data structures is only found in more obscure corners of the internet. Also, very little in systems programming is about strings.