LLVM deprioritizes helper scripts such as update_analyze_test_checks.py, and the build infrastructure is far from perfect. Scripts like the ones categorizing PRs are very much unpaid work.
LLVM also deprioritizes general cleanup work, such as getting rid off passes that don’t work, and are rotting in the tree: of the top of my head, I can think of GVNSink, LoopFusion.
There are additional problems unique to LLVM, as it doesn’t have a dictator: there are multiple different dependence analysis in tree, for instance.
LatexML has come a long way. Even arXiv uses LatexML internally to offer HTML5 versions as of late 2023. It does have limitations in not supporting all packages, or producing a high-quality translation in all cases.
If you don't need to convert entire LaTeX documents, MathJaX and KaTeX are really good at rendering a subset of LaTeX as MathML/SVG. I run MathJaX + an xypic extension for commutative diagrams with server-side rendering on my website, and it works great in practice.
Honestly, everyone working with C++ sticks to a select subset of the language that they've chosen for their project, or the project they're contributing to. Nobody knows all of C++. Personally, I don't mind C++ forking out in different directions and accepting diverse proposals; while I wouldn't bother to use them myself, I realize that it may be useful to other people.
C++ is an engineer's language, and it's ridiculous to imagine that we'd ever need a C++2.0 that cleans it up. Subjectively, you could say that some features are "ugly", but this is an evolutionary process, and there are bound to be vestigial features.
Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. Sure, the Pass Manager needs to build passes, and the IR needs to be allocated, but that's about all the manual memory management there is.
Personally, I couldn't care less about standardized argv-parsing, as each project has its own set of complex requirements. There are JSON parsing libraries available for C++, and I don't see why it should be standardized. Faster hashing in std could be a low-priority feature, but projects like LLVM have their own optimized version of std data structures and algorithms.
I suppose a module system could be useful; most C++ projects are built with CMake which is already very good at finding and linking dependencies. Personally, my biggest pain point is compile-times, but that's really an LLVM/Clang problem.
Overall, the article doesn't seem to be written by someone who has a lot of experience with large C++ codebases.
The example described in this post is JSON parsing in Haskell, but I've implemented a complicated compiler transform that lifts loops to static control parts (SCOPs), in the past, in C++. Each inner function in the lift would switch on valid constructs, either returning a lifted integer set, or throwing an exception on match failure. Although exceptions have a non-trivial cost in C++, it was the cleanest design I could come up with at the time.
Is tree-sitter really slower than TextMate grammars? Some benchmarks indicate that this isn't really the case [1]. On the other hand, breaking parse trees is a real issue, because the error-recovery in tree-sitter is pretty rudimentary [2][3], but as you said, it's not an issue for Shiki.
Several TextMate grammars suffer from inaccuracy bugs, and issues of maintainability. Perhaps the biggest hindrance in the adoption of tree-sitter, is that the most popular editor, VSCode, still doesn't support it.
Unfortunately, even the LLVM community has chosen a combination of Discord/Discourse, and deprecated their mailing list/IRC channel. This is a very unhealthy trend, and only the most ardent of communities such as Linux/Git/GCC stick to old-fashioned publicly-archived mailing lists.
Hehe, perhaps when I'm older. My collaborator on the LICS paper also tells me that the countryside is very beautiful. It will take time to get used to, as I've lived in big cities for the entirety of my life, and participate in activities like book clubs.
I initially kept that option open, yes. However, there are surprisingly few available positions in formal methods outside of academia, and Coq is very very hard: my ability to prove things with Coq is quite modest.
Probably worth noting that I did have an PhD offer earlier, to work with Coq. However, since it was in a small village in Germany, I had to turn it down.
On a more general note, I don't know if formal methods is that promising today: proof assistants are very immature, and proving even little things involves a lot of trial-and-error and is very time-consuming.
It's less a question about what changes, and more a question about how well you can recall your past experience (I had the big picture, but forgot the details of several optimizations I'd written in the past, as well as certain CS fundamentals), and how well you can do online coding interviews (I've only written Coq, at a glacial pace, over the last three years).
I will mainly be working on the middle-end and back-end for RISC-V.
I used to work as a compiler engineer in the US for several years, before deciding to try starting over at the age of 30, in pure mathematics. I moved from the US to Paris in pursuit of an affordable mathematics education, and spent two years in a Masters program. I did have a considerable amount of savings, but it was very risky nevertheless: if it didn't work out, I'd be out-of-touch with compilers, and it would be hard to interview again, with a considerable career gap in my résumé.
For various reasons, mathematics didn't work out, and I was forced to interview again. Fortunately, I did manage to find a job as a compiler engineer again, and will be moving to London soon.
Now, the price of my adventure was quite steep. I uprooted my life when I moved from the US to Paris (especially because I didn't know French at the time), and the upcoming move to London will once again be difficult. I nearly halved my savings, by studying mathematics at my own expense, and will be back to earning the equivalent of my starting salary in the US.
However, I'm an adventurous person, and view my experience in positive light. I'd been wanting to study Jacob Lurie's books for the longest time, and I finally did it. I worked on a mathematical manuscript, which is now up on arXiv [1], and on a type theory project which has been submitted to LICS '23 [2]. I've had a good life in Paris, and my French is decent.
There's the larger philosophical question of "What is a life well-lived?", and for me, the answer is to pursue those things that you're truly passionate about, even if it doesn't work out.
I think Lua was always seen as a bit obscure, and not enough people invested in the language to write useful utilities. It has a solid C foreign function interface, and the compiler is quite fast, which leaves me puzzled about why it never gained traction. I think it's an embedded scripting language in the majority of use cases (e.g. NeoVim, LuaLaTeX, scripting in some game engines).
The story of Ruby is altogether different: they made the fatal mistake of not defining a C foreign function interface in the standard, otherwise I imagine we'd be seeing numerical computation and ML libraries with a Ruby interface today. Still, Ruby lives on in Metasploit, and in Sorbet and Crystal.
I still love the language, and maintain my SSG that was written in Ruby over a decade ago. Shame that it's nearly dead now.