Live data from Hacker News

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

news.ycombinator.com

201–210 of 231 posts

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

#201
post #38

There are good general rules in a few comments here, but I think it's ok to say that in 2018 the specialization arrived to a point where system/low-level is too large to reply in a good way? One thing is to write games engines, another is to write networking code, yet another embedded systems, device drivers and so forth. There are certain common aspects, but the details of what you need to know change significantly.

This 1000x. The field is huge. Get the common basics down, then pick a specialization that seems interesting or useful.

On that, unless you ABSOLUTELY love games and game engine design... the field is relatively flooded and comparative pay may not be great. Not to discourage, but making a decent living isn't a bad thing.

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

#202
post #39

Earlier quoted context omitted.

A quick word of warning: be sure to treat C and C++ as two completely separate languages that just happen to have similar syntax. Yes, you can use C++ as "C with classes" (I and many others sure have at times), but you're doing yourself a disservice most of the time if you do.

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

I like to think what is JSON to Javascript is C to C++ (not capability wise). JSON and Javascript are completely, entirely different things even though JSON is technically a subset of Javascript (every valid JSON sentence is a valid Javascript sentence). C and C++ are extremely different languages -- mostly due to cultural reasons -- even though every valid C program is a valid C++ program (not strictly true, C and C++ diverged slightly, but you got the point). I, for example, write C-ish C++ and compile it with g++ but call it "C" because it's "nothing like C++" and "it's basically C with some extra keywords". I know this comment sounds absurd but C++, especially modern C++, is a very complicated beast with a complex ecosystem and culture attached to it. If you inherit a C program and add one C++ line and compile it with g++, even though it's "technically" C++ now, I really wouldn't call it C++. The way you solve problems in C and C++ are extremely different, and this matters.

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

#203

Earlier quoted context omitted.

> 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…

Golang is garbage collected. I thought due to this, system programmers don't like it.

Yes this is a problem for some things, but at least when I was working in systems you'd be surprised how frequently GC doesn't matter, especially with all the huge GC improvements in recent versions (and future versions) and the trend toward breaking apart monolithic code bases.

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

#204
post #24

Earlier quoted context omitted.

I don't do embedded systems, but as a self-respecting software engineer, I am intending to develop proficiency in C/C++ over this next year. Does anybody have any recommended books/courses/projects?

K&R,and Richard Stevens's books

Please, please, please don't suggest people use the k&r book to learn C. It is one bad practice after another and many of the suggestions in that book have given C much of its reputation for buffer overflows, stack smashing, etc.

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

#205
Take a look at

Nand to Tetris: https://news.ycombinator.com/item?id=18519883

Nand to Tetris II: https://news.ycombinator.com/item?id=14526344

I asked a question in a here before that might have some relevant answers: https://news.ycombinator.com/item?id=17282466 (not exact topic)

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

#206
post #111

I was also curious about choosing or creating a file format, when creating a low level program that outputs a lot of data. Any recommendations or popular reading? I realize some choices are for proprietary reasons, then compression, but that aside, there seems to be thousands of choices available. Compared to the web, using json etc, and releasing a schema, but not necessarily creating a new file extension.

My current go to for this is using SQLite. It's basically made for this purpose. If that doesn't serve, I like the idea of Apache Avro, but some of it's C++ bindings are a little lacking in my opinion.

This is a fantastic first choice, particularly as it sets you up for using a more "real" database for sharing data/scaling in the future.

OTOH, you have to know when no to use it and step up (down?) to something that is text editor hack-able (XML!?) or has barn burner I/O abilities (yah actually just dumping raw buffers with regularized binary data to disk). Or for that matter is used to exchange data with other apps with other services (JSON, and the long list of other data dependent formats, although for at rest exchange I have to point at XML again).

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

#207

If your are looking towards embedded: * put a cap between power and ground * get some nice ESD-birkenstocks * don't listen to anybody telling you how it's done The start of the art is BS and we need a revolution. There will be so many people who tell you that you can only do it in C and if you don't, you can't be taken seriously. The result is that everybody is keeping to C and nobody invests time in bringing new ide…

What would putting a single cap directly between power and ground be? Wouldn't that be a short circuit or boom?

It's not a single cap. It's a cap near each power supply pin.

People already explained the reasons. I just wanted to add that point.

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

#208
post #111

I was also curious about choosing or creating a file format, when creating a low level program that outputs a lot of data. Any recommendations or popular reading? I realize some choices are for proprietary reasons, then compression, but that aside, there seems to be thousands of choices available. Compared to the web, using json etc, and releasing a schema, but not necessarily creating a new file extension.

My current go to for this is using SQLite. It's basically made for this purpose. If that doesn't serve, I like the idea of Apache Avro, but some of it's C++ bindings are a little lacking in my opinion.

I agree, thanks for the reminder. As an example, I was working with Mass Spectrometry data recently, and found a list of about 20-30 possible formats for that topic alone (mostly proprietary) [0]

[0] https://en.wikipedia.org/wiki/Mass_spectrometry_data_format

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

#209

I'd start with everything by Hennessy and Patterson. That should cover most of how CPUs and memory systems work. I grew up with Tannenbaum for networking, though most people went toward Comer and Stevens. Maybe there's something even more current. I honestly don't know anything as good for storage, which is funny since it's my own specialty. I can try to cobble together a reading list if you'd like. Something on oper…

I would be keen to see the list on both storage and distributed systems.

For compilers the dragon book has fallen out of favor (especially as a first compiler book/source). Modern Compiler in ML (don't touch the Java or C versions) and Engineering a Compiler tend to be the goto books now.

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

#210
My two cents - keep the books/papers/resources on the shelf and go out and build an embedded project. Sure, you could read about interrupts, registers maps, chip datasheets, etc. but the rate of learning will be much greater if you learn by building.

For example, why not build a home automation system?

Start with a Raspberry pi and start hooking up peripherals...light switchtes, timers, sensors, etc. You'll stumble across buses like I2C/SPI, you'll learn about networking. You'll figure out what registers are and learn what interrupts are and what they mean.

You'll get lazy rewriting communication code and stumble across messaging frameworks like MQTT to communicate with devices on your network. You'll run out of money using Raspberry Pis for each new device you build, and you'll find cheaper ways of doing things like desiging devices using MSP430 or ESP8266s.

You'll make mistakes, and you will learn. Best of luck on this new adventure!

Post reply on HN