Richard Hipp (creator of SQLite) had this to say about Rust and SQLite in the comments:<p>> Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt.<p>Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in an unexpected or harmful way. We know this, because we have tested the SQLite machine code – every single instruction – using many different compilers, on many different CPU architectures and operating systems and with many different compile-time options. So there is nothing wrong with the sqlite3.so or sqlite3.dylib or winsqlite3.dll library that is happily running on your computer. Those files contain no source code, and hence no UB.<p>The point of Prof. Regehr’s post (as I understand it) is the the C programming language as evolved to contain such byzantine rules that even experts find it difficult to write complex programs that do not contain UB.<p>The rules of rust are less byzantine (so far – give it time :-)) and so in theory it should be easier to write programs in rust that do not contain UB. That’s all well and good. But it does not relieve the programmer of the responsibility of testing the machine code to make sure it really does work as intended. The rust compiler contains bugs. (I don’t know what they are but I feel sure there must be some.) Some well-formed rust programs will generate machine code that behaves differently from what the programmer expected. In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. But whatever you call it, the outcome is the same: the program does not work. And the only way to find these problems is to thoroughly test the actual machine code.<p>And that is where rust falls down. Because it is a newer language, it does not have (afaik) tools like gcov that are so helpful for doing machine-code testing. Nor are there multiple independently-developed rust compilers for diversity testing. Perhaps that situation will change as rust becomes more popular, but that is the situation for now.
Completely unrelated, but maybe I can use the deep knowledge of HN.<p>Browsing from the article I ended up in the page of tis-interpreter that says "You can also use TrustInSoft to maintain compliance or reach certification according to the norms EN-50128/IEEE 1558." [1]<p>How does this compliance process work? Some of you have experience?<p>[1]: <a href="https://trust-in-soft.com/industries/rail/" rel="nofollow">https://trust-in-soft.com/industries/rail/</a>
I wonder if there are enough statically compiled languages out there.<p>Not to be arrogant, but it doesn't seem new and/or recent languages are picking up fast enough, because their syntax is just not simple enough. I see many languages, and I never really find one that is interesting to me.<p>I recently found volt, and I thought this language was really awesome. Then I realized that it is garbage collected.<p>D is fine, but it has too many high level constructs (OOP and al) which I don't find useful. Rust is okay, but to me syntax matters most, and to me rust is too far from C.<p>All of this shows that you cannot beat C.<p>I just want a language that picks up from C, has the ease of use and readability of python, doesn't include high-level constructs as first class citizen, and compiles to LLVM or machine code. I wish I had the skills to build such language. C++ is close, but its slow compilation and its backward compatibility with C are not good.
Another call for boringcc[0].
[0] <a href="https://news.ycombinator.com/item?id=10772841" rel="nofollow">https://news.ycombinator.com/item?id=10772841</a>