Live data from Hacker News

Ask HN: What should a systems/low-level software engineer know?

news.ycombinator.com

181–190 of 231 posts

Re: Ask HN: What should a systems/low-level software engineer know?

#181
post #47

Earlier quoted context omitted.

Huh. I always perceived C to be a subset of C++.

Current versions of C have some features that are not present in current versions of C++ (e.g. designated initializers). But that's not the point. C and C++ are in practice used completely differently, so writing C++ using C concepts with some additions rarely happens in the wild.

... except in the firmware space, where important C++ mechanisms (especially RTTI and exceptions) tend to be unavailable, giving rise to a (useful, powerful, fun) hybrid of the two.

Re: Ask HN: What should a systems/low-level software engineer know?

#182

I'm an embedded software engineer. Here's my $0.02 on how to get started: 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. 2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on. 3. Learn what a programmer's memory-model is. 4. Learn what peripherals are, and what they do. You may have to dig a bit in…

> 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. I'd recommend something cheaper and simpler like the STM32F4 discovery boards. You won't get linux and will have to program via JTAG but the documentation for the STM32F4 is not as overwhelming as Broadcom's.

I like this suggestion. Their F3 disco boards are also nice.

For a related twist the OP might check out the Nordic Semi's M4 with radio SoC offering, the nRF52840DK. It has an onboard, breakout-able segger JTAG programmer and is easy to get going with Segger's freebie take on a GCC IDE.

Re: Ask HN: What should a systems/low-level software engineer know?

#183
post #121

The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well. For me, low-level is assembly, not C.

Does anyone beside compiler writer write in assembly? For what systems? Why wouldn't they use a compiled language?

When trying to solve the worst bug I ever encountered, the critical clue came when I looked at the assembly output that the compiler produced.

You don't have to write it (much). You should be able to read it (with the instruction set manual if needed), and maybe be able to write a little bit of it in a pinch.

Re: Ask HN: What should a systems/low-level software engineer know?

#184

A systems programmer will specialize in subdomains much like any other programmer, but there are some characteristic skills and knowledge that are common across most of them. Systems programmer coding style is driven by robustness, correctness, and performance to a much greater degree than higher up the stack. Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. - Know ho…

> Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future.

I don't disagree, but at least anecdotally a lot of the shops I've been involved with/worked with are really excited about Rust and Go. A previous employer that used C++ exclusively has even shipped a few Golang based tools, and is planning to introduce it into the main product soon. No new projects are being started in C++ either.

Definitely recommend learning C, but having Rust (or Golang) exposure will likely be helpful in the near future.

Great post btw.

Re: Ask HN: What should a systems/low-level software engineer know?

#185

A systems programmer will specialize in subdomains much like any other programmer, but there are some characteristic skills and knowledge that are common across most of them. Systems programmer coding style is driven by robustness, correctness, and performance to a much greater degree than higher up the stack. Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. - Know ho…

> Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. I don't disagree, but at least anecdotally a lot of the shops I've been involved with/worked with are really excited about Rust and Go. A previous employer that used C++ exclusively has even shipped a few Golang based tools, and is planning to introduce it into the main product soon. No new projects are being started…

[deleted]

Re: Ask HN: What should a systems/low-level software engineer know?

#186

Embedded programing pay sucks compared to the web. I wouldn't do it. Just look at the number of web jobs vs system programmer jobs.

The number of web jobs is higher. The number of web programmers is higher, too. I don't think you can tell from the number of jobs how the pay situation is going to play out. (Look at the number of fast food jobs. It's huge. That doesn't result in high pay, though...)

I really can't tell whether an entry-level systems programmer gets paid better than an entry-level web programmer. But it seems to me that in web programming, you hit a wall at about ten years, where more experience quits translating into more pay. In embedded, you can find at least some jobs where 30 years experience gets you more pay than 20 years experience.

Re: Ask HN: What should a systems/low-level software engineer know?

#187

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Are you sure about your epoll statement concerning complexity? 1 thread per client connection that blocks is as simple as it gets to reason about in my experience, and if you don't care about the stack space the thread occupies (mostly virtual anyways) your contemporary Linux kernel handles lots of threads very well.

Sure, there is no complexity to speak of when your threads do not need to cooperate nor share any data.

But then someone has a bright idea that e.g. a global cache to share some state between all threads would be a good optimization, or that threads need to be able to store some global settings, etc. and complexity related to threads start to creep in to your application.

Re: Ask HN: What should a systems/low-level software engineer know?

#188
post #68
post #58

Earlier quoted context omitted.

I learned it with "Advanced Programming in the UNIX Environment". > as a self-respecting software engineer Then you probably already know more about C than you realise: if, while, for, etc. all work the same as most other languages. What you're probably not used to is needing to define functions in advance, pointers, and memory (de)allocation. If you learn by doing, then with google and github, you can create a few s…

> I learned it with "Advanced Programming in the UNIX Environment". Agreed. APUE is perhaps one of the best book available covering SUS, POSIX layer in detail .

APUE is good, but I believe it has now been superseded by The Linux Programming Interface.

Re: Ask HN: What should a systems/low-level software engineer know?

#189
post #62
post #20

If by low level you mean embedded systems programming, you will definetly need to be proficient in C. The other knowledge depends on the product that you will make. For example I work in the automotive industry, where you need to be interested in cars and how the different parts work. Knowledge of electrical engineering and control theory is also valuable. There is a good book about it if you wat to learn how cars wo…

What if -and I'm sorry to hijack- by low-level OP means a position as a C/C++ developer (asking for ~a friend~ me)? I've always been insanely attracted to the C variants and messed around with them to minor extents, but what might someone _need_ to know to be competitive if they're trying to make a move to that area of SE?

For C:

Pointers, stacks (one in ever 23.7 bugs is a stack smashing bug), bit bashing and endianness, types and coercion at the byte level (see also: pointers, bit bashing), C strings, the stupid rules about when a variable's value is actually written to memory that need to die in a fire, memory allocation/clearing/copying/ownership/freeing, ALWAYS CHECK RETURN CODES, what the heck an lvalue is.

This book is fun:

http://shop.oreilly.com/product/0636920033677.do

Post reply on HN