Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0].
The comments are wildly fragmented in this thread. I agree with @torginus, the article has less and less of anything useful to people that want to get into compilers.
Anyways, the "Who .. hires compiler engineer?" section is fairly vague in my opinion, so: AMD, Nvidia, Intel, Apple, Google definitely hire for compiler positions. These hire fairly 'in-open' so probably the best bets all around. Aside from this, Jane Street and Bloomberg also do hire at the peak tier but for that certain language. The off beat options are: Qualcomm, Modular, Amazon (AWS) and ARM. Also see, https://mgaudet.github.io/CompilerJobs/
I seriously attempted getting into compilers last year before realising it is not for me but during those times it felt like people who want to be compiler devs are much much more in number compared to jobs that exist (yes exist, not vacant).
The common way to get going is to do LLVM. Making a compiler is great and all but too many people exist with a lox interpreter-compiler or something taken from the two Go books. Contributing to LLVM (or friends like Carbon, Swift, Rust) or atleast some usage experience is the way. The other side of this is doing GNU GCC and friends but I have seen like only one opening that mentions this way as being relevant. University level courses are rarely of any use.
Lastly, LLVM meetups/conferences are fairly common at most tech hubs and usually have a jobs section listing all requirements.
A few resources since I already made this comment too long (sorry!):
Good synopsis! I enjoyed my time doing some compiler-type work in the past, but there are so few job openings that it can feel quite cramped after awhile, especially without great experience/credentials.
Definitely worth some self-study, however, if only for the healing effect of being exposed to a domain where the culture is largely one of quality instead of...everything except that. :)
I assume they mean those firms hire compiler engineers to work on the specific languages they use. Jane Street famously uses OCaml for pretty much everything. Not sure about Bloomberg, though a quick search shows that they have Bloomberg Query Language and Bloomberg Scripting Language, both proprietary.
I am whole off the vim (&friends) trend but my 2c-
The helix situation is still miles better for up and running asap compared to dancing with files/lua on lazyvim. Just having to refer to docs to install a plugin, writing sane remaps etc eats up time. If you really just speedrun everything under an hour good for you. But for the rest, a lsp is a one package manager install away (even on windows scoop seems to have become the de facto), editing a toml is much easier than fiddling with the lua api/vimscript "just" to set some variables.
(Not a helix user though I have tried both vim/nvim/helix)
The only problem for me was the keybindings work good unless my vim instincts kick in where I become slow. The other one was lack of plugins.
I agree with all you said. Its an improvment over nvim situation. I still think for common languages like python and markdown lsp should be setup by default. I am not sure if i am willing to forget all the muscle memory I have just yet.
Also I miss being able to ZZ to exit my file
I don't know about LazyVim but my LSP configuration in Neovim is really simple:.
Use Mason to install the LSP server (just type :LspInstall or use the Mason UI) that will then activate automatically and reuse an existing configuration from lsp-config.
Slightly off topic here but do you (or anyone) happen to know how to get old Eglot behaviour back of showing entire types and parameter information instead of only the first line? It has been bugging me whole week and I cannot seem to find any fix for this.
Are you referring to the eldoc help text in the echo area at the bottom? Hard to know without more specifics, but maybe one thing to check might be the value of eldoc-echo-area-use-multiline-p. I have mine explicitly set to `nil` because I find the default eldoc behavior of constantly resizing the echo area to fit more information to be very distracting. I instead have a keybinding to call `eldoc` (an alias for `eldoc-print-current-symbol-info`) on demand, which opens a side split that shows the full symbol information.
Yes I am talking about the help text in echo area. In newer versions apparently they only show a single line by truncating the eldoc-doc-buffer content(not super sure on this but they do truncate to 1 line). eldoc-echo-area-use-multiline-p does not work for that sadly.
Apparently this was changed only recently. I am surprised not many people know/talk about this change. Still looking for a fix.
Edit: I do agree it is annoying but for unknown codebases it helped me a lot.
I also like to view entire doc even jumping. I created some Eglot additions here https://github.com/cxa/eaglet which have an option to enable this behavior if it would help.
> Applications are written in the Limbo programming language, which provides static typing, garbage collection, and built-in concurrency features. Limbo code is compiled into architecture-independent bytecode executed by the Dis virtual machine. The Dis VM can interpret the bytecode or compile it just-in-time into native instructions, allowing applications to run consistently across different platforms.
Can you port existing software to it, or do you have to rewrite everything in Limbo? Because if you do, that right there almost completely kills it IMO.
You could port as much as what was already on Plan 9, so same restrictions apply as UNIX to Plan 9.
The C compiler is there, the same way as in Plan 9, Inferno is the evolution of Plan 9, in one way it was Bell Labs response to Java, in other way it was another take to what went wrong in Plan 9 like the failure to design Alef to be usable.
Naturally Limbo was prefered as the main userspace language, from safety and usability point of view.
Ah, okay, I thought limbo was the only userspace language, which would massively hinder adoption. If that's not the case then I know of no particular technical reason inferno wouldn't be a good option. I do wonder if other people had the same misunderstanding as I did.
As someone who tried to use both, there is little you can do with it in practice when compared to Plan9. There was a _great_ baremetal port of Inferno to the Raspberry Pi, but there aren't any modern versions for other SBCs.
How far are the problem sets doable for non Harvard people? I want to do the psets as well as maybe extend the OS with some ideas but the license is not there as well? @ekzhang
These look like the fonts from the IBM Selectric with the changeable typeballs.
When you needed a greek letter you had to stop there, change typeballs, type the greek letter, then put the regular typeball back on.
On the equations the big stuff would be drawn in by hand from stencils.
On a diagram it could be a mechanical (assisted) drawing that was labeled by typing the same font size, like sketch (a).
When you get to sketch (b) though, this one is a reduced photocopy of the original page that was typed on when labeling the mechanical drawing to begin with.
You can see the way that all of the equations and illustrations could very well be place-held in the text draft until a perfect equation or diagram could then be added later by cutting the proper size horizontal strip of paper containing the original drawing, and "pasting" it over the blank spot in the text where the figure goes. Before photocopying to arrive at the priceless original like this where you couldn't always tell where it was cut-and-pasted.
The Fortran printouts from the IBM line printer look like they could be pasted in both at full-size and photoreduced, on one page at page 20.
But a good typist could avoid that for most equations, they could blaze through the text but when an equation came up it took more time to get one equation right than to type many more pages of text.
[0]: https://www.youtube.com/watch?v=_qZliI1BKzI