ilovecaching

Nice bait. A professional embedded developer doing serious work would never in their right mind forgo C for embedded development. The fact that these people are working on porting Rust to increase safety over C is laudable and it's sad that you are either too naive or just don't care enough about your users to see why using a language that catches simple mistakes that allow for exploits and crashes is a good thing.

I don't think they are asking to not take a cost of living adjustment. I think they are asking to be able to work somewhere in the world other than Seattle.

Anyone have tips for how they manage their ADHD, specifically when you aren't able to get yourself motivated at all with the task at hand or feel like you have too may balls to juggle?

I really struggle with yak shaving and perfection being the enemy of good as well, my ADHD often devolves into OCD like behaviors.

That's not how that works. Rust can actually make power usage worse because it generates larger code sizes which causes more I-cache churn and thus more power usage. Making efficient use of caches, power states, and reducing polling are all things that you don't just get for free because "I'm using Rust and Rust is efficient". Rust lets you write something efficient after you've spent tons of time working on making it efficient and understanding how power is consumed on a particular platform for a particular app.

Once again, you could just use a language where they do this for you in the runtime instead of trying to reinvent (probably poorly) these ideas yourself.

As a "systems" programmer I feel strongly that Rust is the wrong fit for most applications, but is suffering from web and application programmers needing that next fix of rewriting the world in a new shiny toy.

You could have a garbaged collected language with an actor model, implicit yielding, easy runtime inspection, easy to learn, easy to teach, but instead you're picking Rust because it's cool. The author could have just used Elixir, or Go, and they'd spend half of the time they did learning and writing Rust code on the millionth web framework/userspace work stealing scheduler. I mean, they know Erlang, so why not Elixir? Why not Phoenix which they've been working on for like 10 years now. It actually astonishes me how often these very well trodden wheels get reinvented for no reason at all because web frameworks are apparently all developers work on these days.

Systems programming absolutely needs Rust, but this "it's a great fit for everything" has to stop. You don't need manual memory management. You don't need to think about lifetimes. You don't need explicit yielding. If you're choosing Rust because you just want to use a complicated language, learn a new toy, feel like your web app needs to go at light speed, maybe stop and consider that you're doing yourself and whoever your building your software for a disservice when something like Go is way easier and will cover the 95%. I have seen these garbage collected languages scale to incredible loads with good engineering that focused on good architecture rather than magic tools.

If on the other hand you actually need to write software that's going to run on a TPM, or in the kernel, interface with a new hardware protocol, ok, use Rust. C is obviously a huge danger and we've known that for a very long time. That's what Rust is good at, and trying to use it for everything just leads to code bases that are way more complicated than they ever needed to be. And truly, being as simple as possible is almost always the right way to go.

But C++ is an outlier in systems software. Systemd is written in C. Grub is written in C. The Linux kernel is written in C. Firmware is written in C. Sure there are some kernels that use a bit of C++, but it's an outlier, not the norm. C++ never proved the is was so worthwhile to have a higher level language that we should drop everything and write C++. C++ only dominates in performance critical applications where there is a bridge to higher level languages and you're interfacing with software.

The strongest argument for Rust is its safety features. Abstractions have made C++ an unusable mess that even C++ developers complain about on a constant basis.

Being easier than C++ or Haskell isn't really saying much at all. Neither of them have improved code readability and are notorious for their learning curve.

With all due respect, writing one program with a small memory footprint doesn't disprove my point. I'm referring to writing very large, complex programs that interact directly with hardware - kernels, boot loaders, firmware, all of which must be as clear as possible. And I say this with many years of experience dealing with other companies badly written device drivers and firmware.

I absolutely need to worry about what assembly I get. I am often checking my assembly or looking for optimizations in my assembly. And I'm doing this across multiple architectures.

As a systems programmer any mention of the word Haskell next to the word Rust sends shivers down my spine. Haskell is the king of yak shaving abstractions and is almost the polar opposite in all the ways that made C the most practically successful language on the earth.

I do not want abstractions where they aren't needed. I want control, simplicity, a clear correspondence between what I'm writing and what logical assembly I'll be generating (logical, not physical). Most of all I want my code to be stupidly clear to the next person reading it. Systems programming isn't like writing a Java app, the domain is complicated enough that there's no room for abstraction astronauts to create problems where there are none.

I am still very wary of Rust. I have used it and will continue to use it, but it still teeters on being too complicated to be useful in the same way as C.

Absolutely. Tech companies already learned their lesson with the transition from the personal PC to the phone. VR will be even worse.

How bad was the recovery? When could you start reading a computer screen?

My doctor keeps saying all the side effects will clear up within a few months for most people. But I hear a lot about light sensitivity and halos as being permanent. Is zero side effects just marketing? Does the light sensitivity include computer screens? I like to keep my brightness up.

Any side effects? It must be really frustrating to go months with vision that isn’t as good as just glasses.

I’m worried about trading good vision with glasses for less that perfect and light sensitivity.

Would you do it again?

How do I bypass the paywall

Were you trying to make your own config, or use something prerolled like Doom?

You can try using emacsserver remotely. I would recommend using SSH proxying instead of messing with emacs over tcp.

Personally I use emacs on a large dev machine running in a container in a terminal emulator. I can work from my iPad Pro, iPhone, MacBook Pro, Windows Desktop, Linux Desktop, or any guest machine by just adding one public key. Terminal Emulators are still just GUI apps and fit into the GUI ecosystem. Modern emulators also have true color support, GPU based rendering, full unicode support, support for custom fonts that add additional graphics, etc. You can make a terminal editor look like something incredibly modern if you want to. I personally don't find any value in that, for me the basic appearance of a terminal editor is less distracting.

I highly recommend modern Emacs over VSCode. If you don't want to tinker, Emacs has multiple levels of preconfigured distributions like Prelude, Nano, and Doom Emacs that give the same out of the box working experience. Modern Emacs includes all of the great features of VSCode, plus much more. You get things like:

- LSP support for completion, refactoring, listing.

- Tree sitter support for super fast highlighting.

- File supporter just like VSCodes.

- Project management tools.

- Fuzzing finding for everything, including files, commands, and buffers.

- Probably the best git client out there (magit). It's seriously magical.

- Terminals (can pipe terminal contents directly into other buffers).

- DAP mode for debugging, ctags, cscope.

It's all FOSS, worked on by a non-profit foundation and volunteers, it can be used as a GUI or in the terminal, and it's insanely extensible thanks to it being a small C core running a lisp environment. Lisp is easy to learn and fun, and if you don't like lisp there's still a bazillion more packages you can install for extra features.

That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++. We can innovate without throwing things away, even if it may seem boring to the uninitiated.

They sound like someone that is attracted to chasing the high of the next technology to learn rather than picking a language like C/C++ that would have worked and given them way more career stability.

Rather than mastering a bunch of programming languages they should have focused on one and built clout as a problem solver that doesn’t see a new shiny tool as a way to label their career. Boring popular language + focusing on building stuff and solving problems are the key to actual career growth.

Web apps are applications and are the opposite of systems software. Systems software would be the web server itself, or something that runs beneath the application layer.

Yes definitions are sometimes nebulous but that doesn’t mean words should lose all meaning and we should stop trying. Systems programming is a useful label for the boot stack, kernel, protocol implementations etc. which support the application layer.

The best language to learn and use right now for systems programming is C/C++. It is by far the most marketable skill with 99.999999% of all low level systems written in C or C++. Large scale systems used by companies that pay top salaries for developers (Google/Meta) are written in C++. There is more material out there for learning and mastering these languages than any other language save maybe Python or JavaScript.

If you are not an expert at C or C++ and being paid to learn Rust or Nim, you’re actively harming your career by not mastering the languages that people want today. If learning hot new fads brings you joy, then perhaps the intrinsic value outweighs the real world loss, but it’s the hard to swallow truth.

I think you’re very confused about the purpose of a systems programming language.

I use an iPad Pro 12.9 inch and a Magic Keyboard as my primary dev machine and I love it. I have large bare metal servers I can connect to where I run vim+tmux using Termius. I also have a desktop, MacBook Pro, and a Thinkpad so I actively choose to use the iPad. The beauty of the iPad is I can tote it around in a small bag everywhere, it has cellular, and when I’m not deving I can pull it off and watch movies, play games, draw using the best tablet out there.

My whole setup can also be used with emacs. I have an emacs config as well and have tested using Eglot etc - basically the same setup as what I have in Vim.

The real power move here is to stick to a terminal based workflow. GUIs lock you down to a machine and a platform. Using a terminal based editor, tmux, etc. allows you to be instantly portable, infinitely flexible, and allows you to work anywhere.

SSH is also the other power tool. I mean SSH is actually insane. If you understand SSH agent forwarding, port forwarding, proxy jumping, you can actually be anywhere with any keys you want, proxy dev as a prod environment, use services on any computer anywhere you want, it’s absolutely incredible what you can do with SSH.

I wish I could use mosh, but unfortunately it can't use ProxyJump to tunnel through a bastion host which is how I always use SSH, which makes sense as it's use Proxy commands itself.

You might be able to convince me that for certain languages and tasks, a Jetbrains editor is better than using a plugged up Vim or Emacs. And the up front cost is well known, and their corporate model is easy to understand.

You’ll never convince me, however, that Microsoft’s embrace, extend, extinguish partially proprietary editor that uses the same LSPs as any other LSP client should be used by anyone. I wouldn’t touch it with a 100 foot pole.

There are turn key solutions for both Emac, Vim, and Neovim. They can all talk to LSPs, have DAP clients, fuzzy finders, file tree explorers, project managers, remote editing (terminal editors are by nature the ultimate remote editors).

Why isn’t he world would you put neovim inside of VSCode when you could just use neovim directly via GUI or terminal.

We already have eBPF.

I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true.

The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment.

But of course updating the API surface isn't as sexy as writing in a new cool programming language.

Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.

Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C.

Edit:

Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*

I think bringing Rust into Linux was a really bad idea. IMO Rust has yet to prove it isn’t another overly complicated C++ waiting to make projects almost incomprehensible to understand. It does not provide the same easy ramp up that C provided when working on most of the system software stack on Linux. There’s also still too few standalone projects using it to consider it a proper candidate for folding into such a large project forever.

I am surprised Linus agreed to this given that he doesn’t like C++ and usually errs on the side of clear over clever, and we have yet to see tangible benefits of using Rust.

Now is probably a terrible time to be looking for a job in tech.