Making Systems Programming Accessible by Andrew Kelley
Vložit
- čas přidán 6. 04. 2023
- The kick-off talk for Systems Distributed '23: systemsdistributed.com.
andrewkelley.me
github.com/andrewrk
mastodon.social/@andrewrk
Join the chat at slack.tigerbeetle.com/invite! - Věda a technologie
Thank you for supporting Zig. God bless you guys 🙏
Talk starts at 8:00
based
THANK YOU!🎉
Da real MVP
great question @ 43:34
asked about takeaways for people who are not systems developers, who don't need to know os-level commands to do their work like writing business logic in js.
answering to share my perspective as someone who fits the description.
the slide @ 36:36 is a great summary for all types of devs.
- make whatever you are building accessible.
- understanding what is going on at runtime is valuable.
- invest in tooling to improve runtime introspection.
i write business logic in js and run it in node.
i rely on message passing (interprocess or rabbitmq) to send messages to where the business logic runs and ask it questions about certain operations or state.
i couldn't name 10% of the syscalls where my code runs, but there's a lot to learn in this talk for people like me.
Zig has been on my radar for about a year as one of those languages "I want to learn someday". About a month ago I finally devoted some time to it, and I regret not having done it sooner. I initially found the syntax off-putting, but within literally a few hours, I came to really appreciate it, realizing how smoothly it allowed you to do perform many tasks and work with the language idioms. The stdlib is a little sparse in the documentation department, but I can hardly hold that against a language that hasn't even hit v1.0 yet.
22:52 The comment that “when your system is accessible, bugs are trivial” is a really thought-provoking comment. That is something that I have subconsciously known but never actually called out when writing unit tests and automated integration tests that use simulated data.
always really good talk
wow u guys are really making software look sexy again. love the dis sys and zig communities.
Printing debugging is about looking for patterns of behavior, in particular with the output going into grep.
fully understand = grok
The intro track was a bit like "Ghost" by Robert Miles.
I dunno about that copy example, the OS should abstain from providing hi-level APIs, I mean does it copy on multiple threads? Does it preallocate space on the destination drive? Does it delete the partial file on failure? These questions don't have a single best answer
Considering that IO is originally why operating systems were invented it’s not unreasonable for there to be syscalls that operate in very specific optimized use cases. Copyfilerange syscall copies a range of bytes from one file descriptor to another provided they are the same file system without the overhead of moving the data into user space. It doesn’t magically copy files like he implies, you still have the option to make all those decisions you described. You still open the files yourself, orchestrate what bytes get written and when, you just don’t get access to the bytes.
Don't think I necessarily agree with his perspective on games not needing systems programming. Games are fundamentally the art of designing systems. Thinking through the interactions of the system, and what can and more importantly what can't be done. The only reason we can play games in the real world with regular objects are because of the arbitrary rules we assign to those objects. I think having a mindset similar to systems programming is vital to being a good game designer.
I get your point but I think this view might be a little reductive (or abstract) of systems programming. Systems programming isn't just "designing systems" thinking through interactions etc. If that were true web development would be systems programming. Audio DSPs would be systems programming. Data science would be systems programming.
All programming is "f designing systems. Thinking through the interactions of the system, and what can and more importantly what can't be done" - systems programming has to be defined differently. e.g. specifically low level engineering with APIs that interact specifically with hardware - like Andrew explains.
Distributed systems are a bad idea. Just don't build them unless you absolutely have to. In most cases problems can be solved without this strategy.
What about databases? They need to be distributed, no? Also, software infrastructure in general (load balancers, kubernetes, etc.).
I think any time you need fault tolerance and reliability/high availability, you need distributed systems. I think it's a necessary evil for high availability, and sometimes a necessary evil for performance and scalability (when the demands of the system exceed what a single server can fulfill).
@@nathanmartinez2630 Yes, all of these things are bad, bad, bad ideas unless you have to use them. That a single CPU is not reliable is complete bs. I have industrial control systems products without any redundancy out there that have basically 100% uptime and zero known bugs. They use a simple watchdog circuit to reset themselves, just in case that a cosmic ray does something bad to the memory content. In most cases the 1ms startup delay is not even noticeable.
Do we need distributed systems? Of course we do, but not for something like a spreadsheet or word processor app. I would claim that even the HR department of Walmart (2.1 million employees) could do all of their hiring and firing on a single PC with nothing but a few extra hard drives (terminals and terminal server excluded, but those are trivial pass-through functions). Just how much data do you think does HR need per minimum wage employee? One MByte? So that is, at most, a couple of GByte of data for everybody who is currently employed by the corporation. That's less than the memory your phone's CPU uses to play one video at a time.