| ▲ | grapesodaaaaa 5 days ago |
| I can’t help but wonder what the use-case is for optimizing Java to these levels. I would expect C or asm to be a better choice at ultra high levels of optimization. I know Java can get somewhat similar performance if you put the work in, but I’d assume you want to do manual memory management at minimum. |
|
| ▲ | pjmlp 4 days ago | parent | next [-] |
| Using Java gets many companies almost to the goal line, while paying less, and having a bigger pool to hire from. "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... |
| |
| ▲ | grapesodaaaaa 4 days ago | parent [-] | | I’m not saying it can’t be done, and I understand the economics can work. I still just feel like a non-GC language (maybe even Rust) is a better choose when nanoseconds matter. | | |
| ▲ | pjmlp 4 days ago | parent [-] | | The only non-GC language that offered Java like capabilties in productivity, without being either C or C++, was Delphi, which has stuck being mostly for Windows shops, and is taited with the way Borland went through re-inventing itself. Ada is not something that these companies would bother using, even though there are about 7 vendors still in business. Likewise with either FreePascal or Modula-2. Most likely a few of these exchanges are writting new code in Rust for such deployment scenarios. |
|
|
|
| ▲ | mcosta 4 days ago | parent | prev [-] |
| C or asm IS a better choice at ultra high levels of optimization and crashing the process. |
| |
| ▲ | grapesodaaaaa 4 days ago | parent [-] | | 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). | | |
|
|
|
