Getting into Rust (or Systems Programming in general)

Looking for a bit of guidance..regarding getting into professional systems programming (perhaps in Rust).

I am an experienced "full-stack" developer with decades of experience in mostly javascript, python etc. I have no formal computer science education, but many co-workers/managers are often shocked that I don't because I really like to delve into things even when they are not necessarily related to my immediate task. I have consistently found throughout my career that such curiosity ALWAYS becomes practical at some point.

I now have a job working on restful and gRPC APIs in golang along with a small amount of ReactJs work. I have played around with rust a bit (some of it is not too foreign as I've studied functional programming in both JavaScript and a bit of Haskel). I then moved on to playing with C, as some of the lower level concepts like stack and heap and pointers were a bit foreign to me working on higher level languages.

I increasingly find myself frustrated because I'd like to create tools for other developers instead of just customer facing products. I would like to learn about lower level considerations such as memory and performance in an environment where failure has more severe consequences. In other words, I'd like to be more of an engineer than a "programmer," and I'm particularly interested in tooling. I am a bit older with lots of other financial responsibilities so going back to school for CS is not an option for me.

I am currently working through some algorithm books. I'm trying to see the best way forward. Seems to the next thing would be to start contributing to an open-source project either in either Rust or C (not so interested in getting into C++)...even if it's something like writing tests or docs. I have also considered trying to learn about OSs by trying to contribute to Linux, but I wonder if that's reaching too high.

Any advice for this frustrated developer is appreciated. I realize Rust isn't the most used systems programming language, but I figure enough people here have both C/C++ Rust and systems programming experience to offer some insights.

Hopefully you'll get some practical advice from someone actually working in the field (I'm not), but just a few comments that come to mind:

Perhaps for others answering you could clarify what your frustration is -- is it your current area of work, or rather your attempts to get into (or learn) Rust / systems programming that frustrate? Different answers might ensue.

If you don't actively hate the work you're already in, you may not be in a hurry, so why not just follow your interests for a while? Finding a specific area/project/topic that really grabs you might be the most motivating thing to do. Rust seems to be used in so many really interesting areas you'd be spoilt for choice.

Finding germane open-source projects to contribute to strikes me as a fruitful course of action. Not only will you develop skills, there's a non-trivial chance it will lead to contacts that might help you find work using related tech. See, for example, this recent HN thread: Ask HN: Anyone joined a company after contributing to their OSS projects?

I don't hate my work. My frustration is that most web work (even backend work) is basically gluing things together. On top of that there seems to be a culture of getting it done as soon as possible without concern for maintainability, testability (often one and the same), or performance.

I wonder if in the systems programming, where the consequences are often more severe, if there's more of a focus on design and processes.

A tough question.

I have to ask: What is your concept of "systems programming"?

For most of my career I would have interpreted "systems programming" as working in assembler or some low level language like C on embedded systems where there was no operating system. Or perhaps working on some real-time operating system required to support the above.

But then I find writing an OS kernel like Linux is "systems programming". And then of course creating the essential user space programs to make that kernel useful is "systems programming"

Fast forward I find writing a web browser is "systems programming". After all it is essentially the operating system for many things. But then so is creating something like node.js.

Another view of "systems programming" is pretty much anything that requires the use of a compiled language. Rather than some interpreted language. Be it to achieve performance or fit in the available space.

In short "what is a system?".

In my old age I have come to the conclusion that everything we write is a system or part of a system. If it's important and you have pride in your work you will care about correctness and reliability. As such Rust is the best tool we have today to achieve that.

On the other hand, if it is not important, if correctness and reliability are not a concern, then why are you doing it? I don't want to be doing it.

Where I am going with my rambling is that you have expertise in web development. Front end, back end, so called "full stack" as you say. That is "systems programming" as far as I'm concerned. So rather than throw that expertise out the window and try and move over to some other kind of systems programming how about looking for ways you can use Rust to create correct and reliable code in that area?

That may not be possible in your current work environment but I feel sure there will be others who welcome the idea. I have read of quite a few cases where "web stuff" has been re-implemented in Rust already.

2 Likes

True "Systems programming" is pretty fuzzy now-a-days. I'd say that the core of my discontent is that web programming seems to have become more of a case of blindly pasting existing tools together without much algorithmic thinking, nor much thought about resources and maintenance. I'd say the majority of the code I've seen is really just thrown together without much review or thought. Of course it depends on the company, the team etc. And the fact that there are existing tools to do everything is not necessarily a bad thing, but it seems to encourage an intellectual laziness among many (but not all) "web programmers." This is, of course, a generalization, but nonetheless generalizations are sometimes partly true, that's why they are generalizations.

I would think that where essential tools are constructed which run infrastructure (which a lot of others are dependent on), there's more of an emphasis on disciplined design and engineering principles, and that is what I'm interested in. A robust type system, with lack of nulls, and a picky compiler is a superior avenue to that end than most (if not all) languages commonly used in web development. It absolutely shocks me, for example, how many experienced web developers are still using JavaScript over TypeScript, when in my mind that's like flying a plane without instruments. That's just one example.

But perhaps I am wrong.

2 Likes

No not wrong. Perhaps a generalisation. I don't have much experience of web development outside of my little company but I have seen what you describe around and you are not the first to point it out. It's the reason I promised my self never to do anymore web development after working for a web start up back in 1999. Of course I found I could not avoid it many years later.

My take on it though is that even a humble web. page is part of a system. A complex, distributed system. As such it should be subject to as much rigour and attention to detail and performance as any other systems programming. Or what I call just "programming". Lack of performance is an issue. Erroneous behaviour is an issue. For whatever reason these issues seem to get down played in a lot of web world.

My observation is that the entire web stack, HTTP, HTML, CSS, Javascript, etc is put together with express intension of allowing those with no programming experience to get something done. With no regard for performance or correctness. It suffers from a fanatical, and often in appropriate, adherence to Postel's law: Postel's law — FlowMapp. Which accounts for its appallingly bad history regarding security and much else.

Well there's a fine balance...a start-up web company for example can't justify the up-front costs of design and systematic practices that, say, a producer of a pace maker can...unless perhaps the start-up is dealing in a business whose primary focus is performance, security, robustness etc (the vast minority).

The problem is that often times today's prototype, is tomorrow's production product. That's the rub. And once you've built yourself a sea of objects, and a rats nest, well that eats into reliability and velocity. I've seen it over and over again.

Anyway, I think the answer for me is to focus a bit on essentials that make a programmer stand apart from the crowd (beyond soft skills), which are a good grounding in algorithms/data structures. Then it's simply to move in to an area (web related or not) where, as I said, the business model doesn't allow for failure. In many cases, that may be what we call "systems programming," but it could be any area where correctness, security, robustness etc. is not an option.

Maybe getting into low-level programming on embedded systems (microcontrollers, etc.) could be interesting for you? I never used Rust for that, but I think it's a great language for such platforms. (I only did AVR 8-bit microcontroller programming in assembler and C for fun.)

Yes I've seriously considered that. I bought a discovery board and played around a bit with C on it, not much.

Keep in mind there's plenty of ways to be rigorous, systemic and professional about how you approach javascript: in fact it has probably the most accessable tooling ecosystem of any language out there: you are able to verify you don't have any dangerous code patterns (eslint can go way past formatting), use lots of good quality testing libraries including fine-grained coverage, use bundlers to carefully select exactly the right code that needs to be loaded for each page (or even above and below the fold on the same page), optimize the initial load experience with server side rendering, use nodejs snapshots to boost launch time, use the extensive memory and CPU profiling tooling, and so on and so forth.

And Rust is now a part of that tooling too: you can use WASM to optimize any code that needs better performance guarantees or that would be far too ugly to understand as optimized JavaScript, and Rust is probably your best option for large amounts of WASM.

All that said, the most important parts of being professional and rigorous about being a programmer don't have much to do with the coding tools you use: it's about being able to plan and prioritize work, communicating with other team members (including documentation!) and establishing procedures for catching or preventing issues. Rust in an environment that doesn't care about any of that is likely to just take heat for "getting in the way".

On the other hand, depending on the context, they might be right! Shipping value very quickly, even if it's low quality, and getting feedback immediately is often far better than spending a long time getting everything right, then finding out you built the wrong thing. Nobody said this job was easy.

1 Like

All agreed. I am talking about tendencies here, though to be fair I've never worked in anything but web programming, so maybe it's the same everywhere, or maybe just many of the programmers that I've come in contact with (though, of course, not all).