C or asm IS a better choice at ultra high levels of optimization and crashing the process.

Yes, C or asm get a bad reputation. They are definitely harder.

I’m just saying that this company seems to be throwing a lot of money at the problem, and at those levels you can squeeze more performance out of them and get them reasonably right.

After all, many, many pieces of reliable software are written in C. If you wanted a “safer” modern language, you could pick Rust.

I would just assume those would be easier picks rather than optimizing around GC pauses, which can be notoriously difficult when nanosecond matter.

▲

Joel_Mckay 4 days ago | parent [-]

High level languages tend to hammer the allocator like a Piñata. C++ can improve code smell of C, but different languages have their own specific use-cases. The reason llvm and GC based languages is a problem in low-level real-time code is bewildering for many.

Java is unique in that it often ran a dual stack for byte code, and platform specific binary objects.

My advice often is to use high-level languages if you can get away with the convenience, and a low-level language with proper design patterns if you must.

Many programmers I've met shouldn't write C/C++, but mostly because they can't be trusted to use memory or thread safe code.

Cheers, =3

▲

grapesodaaaaa 4 days ago | parent [-]

Agreed on a lot of that.

C doesn’t inherently have to be bad (and can often be better than C++) if you are strict about adhering to standards.

I like to point to OpenBSD as a successful and well-done C project. As a bonus, if you develop on OpenBSD, your program is more likely to have correct memory handling operations (OpenBSD has a lot of very aggressive memory protections. Many issues in ported applications like Firefox were found and fixed by OpenBSD users, but would happily keep running on Linux).

	▲	Joel_Mckay 4 days ago \| parent [-]
		Indeed, many wished the OpenBSD Debian project had succeeded. =3