Well, look at this way, the needs of commerce are going to solve the conflict between practical and the beautiful. I think those of that value the beautiful aspects of coding will find new avenues of expression. For example, I'm about to get back into C programming to build a play.date game engine for an MMO.
Got an idea that you'd need assembly language for - now you can do it instead of..... never doing it because it would have been impossible for you in any practical way.
Look to the positive instead of lamenting something that never would have happened.
It's unbelievably exciting that you can now program a computer virtually without the limitation of your ability to hand code it.
You won’t be able to enjoy your free time playing with computers if anthropic et al make you jobless.
The “you” doesn’t necessarily refer to you. Im addressing 90% of the developers out there. We love playing around technology… but I doubt we will be thinking the same once we become unemployable. But here we are, having fun with the tools of companies that want to finish us. How ironic
Fiddling while our home burns has been a beloved pasttime for many people, from emperors to passengers on ocean liners to prisoners in camps. What else is there to do anyway? Sometimes history must take its course before humanity as a whole recognizes its folly.
If you've got an idea that you need assembly language for, you can use a compiler to create that assembly language. It'll probably do a better job than an LLM. Assembly projects are interesting because they're written in assembly, not because they contain assembly.
You'd be surprised, again.... most compilers don't generate very good code, mostly because
1. the time for optimisation is limited
2. the constraints are overlapping and just completely intractable beyond a single function (do you want to inline this, saving on the call and increasing binary size, or not do it because it's cold?)
3. they don't have domain-specific knowledge about your code, and even with PGO, they might incorrectly decide what's hot and what's not - typical example are program settings. You didn't enable a setting during PGO instrumentation, compiler sees you didn't call that path, shoves it out of line. Now your PGO-optimised code is worse than -O2. And compilers have different levels of adherence to manual branch hinting - on MSVC you get a reorder at best, Clang and GCC try much harder at [[likely]] and [[unlikely]].
4. There's still quite a bit of low-hanging fruit left, mostly because progress is jagged ;) For example our calling conventions generally suck - this is actually why inlining is so helpful - and the inertia makes everyone emit the default calling convention and that's it.
For example, did you know that compilers have very inconsistent support for struct unpacking? It can be much faster to write
because the first one goes through registers on the MSVC ABI, the second one gets lowered to the caller passing a pointer to the stack. Before someone says "oh this just means MS sucks" - fair, but for std::unique_ptr the situation is the other way around... on the MSVC ABI the callee cleans it up so it's truly zero-cost, but on the Itanium ABI using it is worse than using T* as a raw pointer... see the GCC codegen :)
These examples might seem a bit cherrypicked but this is only scratching the surface, not to talk about the codegen in higher-level languages, which is even more dreadful. Manually optimising your code can usually get a magnitude worth of free performance, which is just tragic.
I wouldn't even rule out LLM codegen in the future - although they're quite unreliable today so you'd get miscompiles like crazy - but there's just so much low-hanging fruit left on the table that it wouldn't be too out of step...
As much as I enjoy the novelty of asking anime pictures from chatGPT I do not, for a single moment, consider myself a doer of anime pictures.
And a fair aside, the result will be "good enough" approximation of what I conjured in my head, but never the thing itself. For me to do the exact thing I conjured in my head it will require to pick up the mouse and draw the rest of the owl. I don't know if that's more telling of my imagination being demanding or my standards.
True if you use only chatGPT to do something and accept the generated stuff as the final output.
Probably not the case for anime pictures, but in other domains, you can use chatGPT as a first level and then go on the improve it from there. To make a parallel: if you draw with a pencil on a piece of paper, you would still think of yourself a doer even if you did not manufacture your pencil or paper.
There's still personal skill expression in driving cars and using a pencil for drawing, that makes the difference between drivers and artists visible enough to justify hiring one over another.
So far I can't say the same for leveraging LLM's and, in the off-chance that there is, we have an entire software development industry that doesn't even know how to filter for "it".
When I go on a trek, the end of trek landmark is nowhere nearly as significant as the experience of reaching it.
If I were to be magically transported there without the lives experience it would take almost all of the joy out of it. Some people get a kick out of doing hard things that are interesting but seemingly beyond one's ability. Making it an easy commodity spoils the fun.
As for teleportation, if it were, say, trip to moons of Saturn I can make exceptions.
Have you ever done blacksmithing? It’s tremendously satisfying.
Sure, if you want 300,000 spoons, it’s far better to use a factory process and get essentially identical results. But if you only want a few spoons and accept (or even value) that the spoons will all be a little different, hand-forging them is quite enjoyable.
I’ve written enough assembly and done enough blacksmithing to know that the metaphor isn’t quite apt. But there’s both tremendous effort and satisfaction involved in both.
Hobbies are great. Making a living is usually a separate endeavor. I don’t want to pay for an artisan spoon. There will be a limited market for artisan software. But make no mistake, we are entering the era of software mass production. Say goodbye to your chisels and rasps. If you want to make money you will need to operate the machine that builds the machine.
It has always been possible to do it. LLMs are not a particular enabler for that.
The difference is that now it is worthless: there is no learning, no person caring about the result, nothing aspirational for the public to look towards... we used to enjoy those challenges, used to be proud of solving complex problems... now? Yeah, whatever, execute execute commit push, let another LLM "review" and call it a day.
The difference is not that it’s “worthless”. The difference is that now it’s “practical” to implement given the low effort.
I wouldn’t be sad about defeating lower complexity challenges. There are always higher complexity challenges that arise once we start operating in a world when you can do more. The bar raises.
The point is the death of the celebration of excellence and technical mastery.
Once insurmountable challenges are now trivial to implement with, as you say, "low effort."
For those who were attracted to computing by the grind and the grand narrative that you, too, with sufficient effort, discipline, and merit, could become a revered craftsman, LLMs trivialize an entire lifetime of practice. I can't think of anything more demoralizing.
If your goals were fame, then yes. But you can still pursue excellence even if there is an alternative “easy” path.
The equivalent is something like hand tool woodworking - it’s still a thing despite the advent of machines, but more of a niche. You can still aim to become excellent, but maybe you won’t be famous.
Writing whole software projects in assembly has been worthless and pointless for a couple of decades now. Even the projects who can put together a solid case will limit assembly to very specific components executed only in specific bits of a hot path. Perhaps the most performance-sensitive code we have today is high frequency trading and that field is dominated by C++.
Also, virtually all mainstream compiler suites have flags that output assembly,and that feature is largely ignored and unused.
That's just not true... the flags to get preprocessed output and assembly are quite useful and used a fair bit, in fact. Multiple reasons - sanitychecking your code, finding bugs, or even finding compiler errors.
Yep, another humane thing going to get killed, because people are naive, gullible and basically idiots handing out their expertise on a platter to faceless corpo entities.
What's next, human human contact abstracted away by brain stimulation?
And the transhumanist arsewipes gonna have a field day.
I think for programmers the enjoy is to write it by his own, not to just have a toy. If I just want a web server in asm the easiest is to just decompile an existing one into assembly and call it a day.
Only exciting if you already got a lot of programming under your belt, like Carmack, or a product guy.
> Got an idea that you'd need assembly language for - now you can do it instead of..... never doing
But you're not doing it. The ai is doing it.
If the op can write a web server in assembly language then I'm pretty sure they could have done it in a higher-level language. But they did what they did for the journey and the learning along the way. Vibe coding it omits all that, and misses the point of the exercise.
I do believe this is just a next step in languages. We've come this far trying to make code NLP, now we have the closest thing to a translator in our generation. It's an exciting time, just don't pay attention to talking heads.
> Got an idea that you'd need assembly language for - now you can do it instead of.....
Nobody actually needs a web server built in assembly language, it serves no practical purpose. And I say that as someone who learned to program 6502 assembly language in 1983 and has sporadically used assembly of various architectures since.
The absurdity of building it would have been the curiosity draw pre-LLMs, but when it existing is just a series of prompts away it really loses all of its meaning.
But yeah... hooray for AI. Can't wait until we learn to harness it to supercharge the most important and valuable thing we do as a human society in modern times: stuff increasingly intrusive ads in front of everyone at all times.
> Can't wait until we learn to harness it to supercharge the most important and valuable thing we do as a human society in modern times: stuff increasingly intrusive ads in front of everyone at all times.
Wasn’t it used for that before anything else? Google invented transformers and had LLMs internally before chatgpt got released. Presumably they were using them for ads, because their public demos were insane things like talking to the moon.
> Wasn’t it used for that before anything else? Google invented transformers and had LLMs internally before chatgpt got released.
According to friends who worked at Google (no direct knowledge myself, so don't know exactly how true it is), they mostly sat on the tech. Google News had internal prototypes of using them to expand/contract/summarise and/or add details/context to news articles and translate them to different languages, but it was never fully productised.
Then after ChatGPT got popular, sudden panic to start using them in products company-wide.
This idea that LLMs are going to enable us to do things that we wouldn't have done before, therefore overall productivity and value is going to increase "exponentially" seems naive to basic economics.
If LLMs are good for doing things we aren't already doing, it indicates the overall addressable "value" that LLMs could provide for such things is actually quite low. If the task has necessary prerequisites that you don't currently possess, but you haven't spent the effort to jump that hurdle yet, then it's a good indication the value of completing that task is very low. Even if, maybe especially if, we're talking about personal projects where the value proposition is personal and not momentary, it indicates the person already feels in their bones that the return on doing this thing is not worth the effort.
I'm struggling with this with my leadership at work. We have developed a thing that is going to remove the need to hire temps [0] for data entry when we get clients who send us large amounts of their "data," aka "a thousand 30-slide PowerPoints each with one line graph of interest sitting in the corner of one slide somewhere." It is an ask that comes up a lot, it's always very expensive in both the time and money axes for the client for that task, but overall it's just a small part of the contact budget. I'm all for using what we've built to cut down the time cost for our clients, but my leadership thinking it's going to lead to massive cost savings for our clients seem to forget just how much time we spend in meetings and planning and documentation and testing and reevaluation and more meetings versus actually executing on things.
It's also bad business. To me, giving results faster should be a premium offering. We should be charging more, not less.
[0] We don't actually hire temps, we turn our junior data analyst into temps by burning them out with tons of unpaid overtime. They then leave and we have to back fill them at rather extreme cost of overhead for hiring compared to the direct contract overtime we didn't provide.
> without the limitation of your ability to hand code it.
Isn't that kind of view pathetic and sad, though? Why would anyone pick up and guitar or play a piano if they could just listen to the same song already made by someone else? I struggle to understand this view of people that pretend to not understand why being an expert of some skill is perceived as valuable by some people. This is also belies next problem with this line of thinking which is that it says "we don't need to learn X to do Y because we have AI" but misses the same AI could easily replace the need to have you think to do Y in the first place. I don't know.
In my experience people that did not hand code enough imagine that the hard part is coding, and not clearly defining all the possible edge cases and use cases.
So, in my view, more people will (or should) understand now what is hard when building complex things, if they pass the stage of "I have a nice POC that works for this one case".
I don’t know. The edge cases become very clear when coding, because there are explicit and precise guarantees of how the code will behave that you can reason about (or when there aren’t, you know that you are in trouble and code defensively around it, and you can reason about that defensive code), which isn’t the case when vibe coding. When coding, you can prove the code correct in your head, and the edge cases are revealed by that process. But that process isn’t possible with vibe coding, because what exactly a prompt will produce isn’t predictable, and doesn’t have guarantees attached that you can reason about.
Look at the bright side, it's much more feasible now :)
Yes, it's not deterministic, and if you were using it commercially, the ROI would be terrible, and it's certainly not reliable but for a hobby project.... why not?
Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.
LLMs lower the barrier for execution - they make you faster. The unstated question is: faster at what - they can make you faster at something clever, or faster at the entirely wrong thing...
Your point is correct if we're looking at it through a scarcity lens - the effort to make it certainly decreased a lot - but that doesn't mean that anything is now worthless. We can just move onto doing bigger, better things now, until we hit the next limits...
> Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.
But we know that long term use of LLMs does not lead to better understanding, it leads to reliance on the LLM for the person to be able to function at their job.
You also depend on {computers, the internet, electricity, groceries, etc.}, that's not the discriminating factor.... the question is, are you actually better at your job using it, and are you stunting your own growth?
I'm not claiming to have a definite answer to either, but I think the right question to ask is - are you going to benefit from using it in the long run? If yes, carry on, if no, re-evaluate what you're doing :)
Early in my career, I had a consulting job where the client wanted me to work on their system using their tools. They had nothing and would not provide anything. No compilers, no runtimes, nothing but a regular, run of the mill, desktop office workstation. Instead of performing the task in Visual Studio with .NET like we had planned, I did it in Excel with VBA macros.
If you come to rely on specific tools such that you can't do your job without them, you're no longer doing the job you think you're doing, you're now just a tool operator. If I don't have a computer of some kind, I'm not writing software, I'm just a manager. If my team can't work because GitHub is down, then we've done a bad job of being software developers.
The experience taught me that there are two kinds of tools: those that are necessary and those that are nice to have. Yes, that job sucked, and yes, I quit that job, but more because they refused to pay me the overtime I needed to get it done with such crappy tools.
I had another job where we were one client of many on site with a vendor for a training event and the vendor couldn't get a system configured correctly for our cohort to continue on. Part of the problem was their configuration system was garbage, very easy to get wrong, very time consuming to manually edit. While they were dicking around with throwing edits against the wall, I wrote an HTML page with JavaScript to make a UI to edit the data in an much more natural way and then generate the config file. It took 10 minutes and saved us hours of waiting so that we could continue on with the training. Perhaps the takeaway from that experience was that Valve's engineers write shitty config systems. All I know is we got the training event done and I walked away with a piece of paper that said I was now a Certified Hardware Vendor, which we then used to sell more contracts on our own.
I think that the analogy of recorded music best captures your feeling. Not the exact technological and economic transformation that is happening, but the feeling.
Some 120 years ago recordings music was a living phenomena produced in the moment. Musicians worked at restaurants and coffee shops everywhere, being useful without being super stars.
Music didn’t disappear with recordings, but the works is certainly different.
It doesn't diminish the art form though. If anything, I value these kinds of hand written projects even more now that so many people are pulled in by AI doing their projects for them in a fraction of the time and effort. I love doing these kinds of projects, and I love writing assembly, but I must admit that the temptation of just copy pasting generated code is big sometimes, because it's _right there_. In this context, seeing someone handwriting something awesome by hand is even more valuable to me.
The answer is "no time at all." I used Gemini Ultra earlier this year to see how well it would do with some really gnarly assembler. I asked it to write a whole flat-shaded 3D engine in 8086 assembler that would run in CGA on an original XT and it one-shotted it in a couple of minutes.
I appreciate the effort. But why not put the skills into something that would be genuinely useful to others or solve a pain point? Open source the results or handover to someone who would like to maintain it.
There’s a lot of things people do for fun that don’t have an obvious purpose. Life isn’t about spending your every waking hour doing something useful in my opinion.
I can dig a ditch and cover it up innumerable times. If you are doing something out of boredom, at least make it useful to someone. Probably would give you a sense of purpose in solving a problem.
Haven't used LLMs for assembly yet, I did try to use it on some DSLs with few docs, the results were much less impressive than those with popular, higher level languages AI companies scraped a gazillion repos for.
I used to LOVE getting into a good flow state while programming and was very proud of clever code I made. Now I just think how much faster an LLM could have generated the code.
The problem, at least for me, is that by now I'm so desensitized that I won't even bother looking at something, because it couldpotentially be the product of a few prompts. The LLM noise is drowning out the human signal, so to speak. Same for articles, blog posts, etc. It only takes a few em-dashes, a few "it's not this, it's that" to lose faith in the text's authenticity, and with that, any interest in its content.
I have a (relatively well informed) view that people who aledge that "if you used an llm you did no thinking or problem solving" have never in fact used an a llm to generate anything particular complex.
You do indeed need to do quite a bit of thinking and problem solving, to build things with an llm.
If you disagree, repeat this project, so you can share with us how little thinking it required.
> Ten years ago, I would have kowtowed to someone elite enough to build something like this.
I'm afraid it's an elite skill in the sense that juggling is also an elite skill. It's impressive for the first few seconds you gaze into it, but once the novelty factor wears off you understand that it's wasted effort that leads to a project that suffers from a massive maintainability problem, is limited in which platforms it can run, and brings no advantage whatsoever. It's an gimmick that has no practice use.
This is the software development equivalent of an amateur guitarist posting shredding videos on YouTube.
What an odd take. It is often titled "software craftsmanship". Is the craftsman not allowed to practice? Not everything needs an immediate real-world application. Not everything needs to be enterprise-grade, bulletproof, web-scale or whatever. It needs to work for the creator, and sometimes not even that.
In the same way we appreciate Japanese wood joinery, why not not just appreciate this? Someone might even learn a trick or two reading it.
> What an odd take. It is often titled "software craftsmanship".
No, not really. This is exactly the opposite example of software craftsmanship. Software craftsmanship involves things like technical excellence in delivering maintainable software that is adaptable to change.
Picking assembly, of all things, for a web server represents a complete failure in the analysis of both the problem and solution domain.
This sort of project is more in line with parlour tricks, juggling, and stunt shows. Trying to frame this sort of project as software craftsman is like discussing the whole Jackass series as cinema next to Hitchcock and Scorcese. It may take skill and practice to be punched in the nuts, but that doesn't make it a craft.
I get what you mean but I feel this new profound yearning for "hand-crafted" code is getting a bit out of hand. Software engineers have taken shortcuts whenever possible since software was a thing. Do you also mourn that we don't code airplanes by hand anymore (i.e. the death of the "craft of coding").
We need to stop thinking of software as carpenters where the magic is some physical skill and that is the "CRAFT WE MUST PROTECCT".
And at least your comment was grounded in reality; a lot of people I talk to (who are not coders) seem to think a good software engineer writes every line and every word with thoughtful genius and AI just spams code so one is better than the other. And they are convinced its some naunced smart take and they understand software development on a inner level or whatever.
And the base assumption still holds true (pure AI-generated code is garbage) but its mostly because its badly designed and is still a pretty poor architect. And there is a need to pushback against slop but why do we need to elevate typing code as if its some sacred acctivity? Most of the work a good coder does is in their mind with little connection to the phyiscal reality of the world.
In this case you could even replace "LLM" with "C compiler" and it would change nothing.
Look, I still got my physical copy of Michael Abrash's Graphics Programming Black Book with its genius content about hand-optimizing cycle count on 486 and Pentium processors, beating compilers at that time.
It was an absolute artform, but completely obsolete by today.
I'm oddly enthusiastic about seeing someone who beings the HACKER in HackerNews. But at the same time, this made me remember the days when display of skill and craftsmanship were rewarded in the industry.
Maybe it's finally time to move on from being a career programmer.
What a dismissive comment. Now that anyone can have an LLM write code for them, the only people who have value to bring to a project are the ones who can improve upon the LLM's output. That is, the ones who have a deep enough understanding of the logic and language. And the only people who will ever be in that position are the ones who take the time and effort, out of sheer curiosity, to learn how things work. Whatever your alternative is to this, there is no future in the alternative.
Artisanal code has a future. Maybe not a high paid one but maybe we go back to roots. if you enjoy programming and were never focused on output or on pipelines, LLM doesn't offer the same ezperience
Sometime around when wordpress came out, or at least 2005 or so, I started positioning myself as a bespoke web designer, then app developer. Whereas anyone could get a site done, I turned myself to doing things that hadn't been done before, for which standard solutions wouldn't fit. I turned away 80% of jobs and raised my rate from $25 to $100, then to $300/hr. To me, pricing and only doing bespoke work was a defensive measure against falling into a career hole I didn't want to end up in. But mostly it was just that I didn't want to repeat myself or waste my time doing something that a client could already buy off the shelf.
Artisanal code, or bespoke code, has always been the best paid and most satisfying work. If we no longer have a new generation of curious people who enjoy solving hard problems, it's only going to become more valuable.
Basically coding, explaining, and owning the whole stack from the DB schema to the CSS. In 2005 that meant a client wanted a website but it needed to be driven with live data from a database, with a custom back-end they would use to update it, something that wordpress wouldn't be able to do easily. Or they wanted a data-driven Java or Flash applet embedded, dynamic resizing, or "mobile-friendly" circa 2008. I had worked for a company in 1999 making websites, split between designers (like me) whose job was to make Photoshop comps with rollover layers and split them up into tables, and the "webmonkeys" who got paid more to take that and mess with the javascript in Dreamweaver. The guys who knew how to tie that into Coldfusion or something made the most. Primitive HTML and PHP and inline javascript and mysql. I just figured out how to do all of it together. Then, web apps, multiplayer games front/back, and starting to get into logistics software. Typical gig from 2005-2010 was 9-12 months, single project stuff, hourly and freelance.
What I realized was that knowing what my software did, being able to explain every part of it and being able to rewrite it from scratch if necessary, was much more valuable than just delivering it. The powers that be who run companies are looking for communication, so they understand what they're getting, someone who can speak the same language as them and materialize it into code that works. LLMs are a decent imitation of that, but they're fatally flawed, because they never understand a whole stack.
Don’t be naive. Anthropics (et al) mission is to make us unemployable. They need to sell their tools to companies so that they can finally discard 90% of their workforce. It’s a win win for companies and for anthropic (et al). Obviously we are the losers in the middle. And people around here on HN may think they cannot be affected, that they are the elite class of developers… they are gonna get hurt
I don't see it as dismissive, maybe you two are talking past each other but seem to be on similar side. I think the parent just articulated a sense of resignation that many people probably share. I think you might be saying that maybe there is still some shred to hold onto, possibly.
I don't see anything dismissive here. It is a realistic assessment: if the choice is between code generated by AI or code generated by a human, and the AI is better in an objective manner, then why should a company employ a human? I refer here solely to the code result; naturally humans may do things AI can not do yet, but if the question is solely about code quality and AIs are better here, then why would that comment be dismissive rather than realistic?
> And the only people who will ever be in that position are the ones who take the time and effort, out of sheer curiosity, to learn how things work.
People learn something new all the time, AI does not learn anything, it just simulates and hallucinates. But the core question is not addressed with that. What would you do if you have to compete against AI, and AI is better? We already see these with the new generation of humanoid robots from China. Those things make Boston Dynamics robots look like tinker-toys in comparison - already as-is. Give it ten more years and we finally reached AI skynet for real.
What do you mean when you say AI code is better? I am looking at AI code all day and it's just garbage that happens to work for whatever feature was requested... in no way is it better code. Any human who was so careless as an AI to commit such atrocities would be fired.
I am attempting to write a software renderer in WebAssembly because, for some reason, I feel the need to go against the direction this vibe coded world is going, and I want to feel challenged again. I don't know if I will ever finish it, it is crazy, and by no means useful. But gosh it feels so good.
I did exactly the same and it was so much fun. It wasn't about bringing anything novel to the table, it was just a fun challenge for myself. I finished and now I'm writing a game using it, although now the challenge has gone I am not making much progress on that. But never mind, I had fun! I wouldn't have had that fun or satisfaction if I had vibe coded it instead.
As in 3D software renderer? I cut my teeth on those throughout my teens and the start of my professional career, in x86 and C.
I wanted to see how an LLM would do writing one in pure 8088 assembler for CGA and it one-shot a nice demo (I fed it the vectors for the Elite ship in the prompt):
Yes, exactly, a 3D software renderer. But the goal is to do (almost) everything from scratch and by hand. No LLMs, no std library, no compilers. Just a few imported math functions (such as sin and cos). Not the same as bare metal programming but close
Awesome, do it! I love this kind of thing and do it regularly, mostly as part of the demoscene. I've written a bunch of demos for MS-DOS/VGA/Pentium 100 era hardware. All my own tools, almost all my own code (just using some standard library functions and someone else's mod player although that's on my list of things to write myself). All in mostly C with smatterings of assembly for speed (triangle rasteriser inner loops etc).
I also wrote a demo for 386/CGA hardware last year and I plan on porting that one to an 8086 as I think it is simple enough that it should be able to run on one. I've done a demo for the Sega Master System and I'm about to start a project for the Game Gear.
I also made a bare metal demo for the Leapster Explorer (an ARM-based kids toy).
I don't use AI for any of this because for me the interesting part is the journey as well as the final result. I want to learn how things work, and I enjoy writing the code.
If you actually start writing big stuff in assembly, esp a macro-assembler, you'd quickly realize it is more verbose, but not fundamentally that different from higher level programming. You basically need to get a hang of how to build abstractions with procedures and macros and you'd be good to go. Reading assembly effectively is often much harder than writing it.
Yeah, that's what I realized during this, too. You need to be much more explicit, but the way any given function works isn't fundamentally different. "strlen" will always iterate through a string searching for a NULL byte whether it's in C, Rust, Assembly, or whatever other language. I think it can feel almost more straightforward than other languages, since you're laying out exactly what the CPU needs to do, in what exact order.
> "strlen" will always iterate through a string searching for a NULL byte whether it's in C, Rust, Assembly
Not all languages use NULL terminated strings. I think Rust actually stores the string length alongside a pointer to the start of the string data. You can do the same in C, but you'd have to do it manually using a struct. In assembly you could do the same thing since you get to decide basically everything.
Agreed. And super cool project. After seeing Matt Godbolts Advent of Compiler Optimisations in December I decided to do AoC in assembly. Was the most fun I had in years even though I didn't finish all days!
And super educational. Since then I've been pondering which problems require dropping down to the assembly level. E.g. implementing a JIT compiler, a coroutine runtime, etc.
It's a beautiful project, well crafted. To reflect to the other comments, projects like this are more like a Minecraft map for me. There are giant and amazing maps, small survival maps, local hosted for my friends and myself, and commercial focused high scale servers. Building a house, or designing a new road in the server became extremely easy with AI, put the value created in the world depends on the original purpose of the server and whether creating more houses and roads actually makes sense.
I think it's a super thing that commercial server can build out faster and be bigger with more houses and roads on it, but
The love an art project creates in the world is incomparable.
Thank you! I've been obsessed with this idea for a while, finally decided to start on it, then obsessed over it for a couple weeks. I'd love to see some of your projects if you have anything similar, I'm glad I'm not the only one too! I think most programmers would benefit a lot from taking a few weeks or months to try and learn some assembly, and demystify how CPUs and compiled languages work.
Even though it's a meaningless comparison, I'd be interested to see how performance compares (max requests per second?) for this compared to fully-featured web servers.
Honestly haven't benchmarked it, but I would imagine ymawky would be considerably slower than most fully-featured web servers. ymawky uses fork-per-connection, which is fundamentally slower than what production servers like nginx or Apache use. nginx uses event-driven IO (kqueue/epoll), which can handle thousands of concurrent connections without the overhead of forking the process on each request. Apache uses pools of threads which handle multiple connections without needing to be spawned per-request. A head-to-head against any other web server would mostly measure "fork-per-connection vs event loop/thread pools", which assembly has nothing to do with.
In a comparison between a similar fork-per-connection server written in C and this, I would imagine the throughput would be about the same, because the bottleneck in this model is fork() itself rather than the actual code. It probably matters more for binary size and startup time than requests/sec. Would be fun to actually benchmark, though.
It's a HTML browser for Pi Pico2, CLI, meant to support my in-house project running on a mesh of Pico2's. I really wanted to use RISC-V and it needed a webhook that serves a page on PIO wake. We are at the browser is written about 60%. The server is now already handled ;P I found this awesome project someone posted on HN. When I complete my project the browser will be released alongside. You can very likely reproduce it with less than a handful of prompts. One thing I really do believe, ideas are going to be the next open-source. LLM's can make ideas into things.
Yeah, I know MacOS syscalls aren't stable. Interesting point about Go, I hadn't heard about that. Unfortunately I'm a masochist though, and want to avoid libSystem.dylib as much as possible. The only reason I link against it at all is because MacOS requires it for executables to run, I never actually call into it. Figured I'd just update the syscall numbers if/when they change.
Woah! I honestly feel more intimidated writing a CGI script in assembly than I was writing a server, lol. CGI support has been on my mind for a couple weeks, but I haven't really dug into it yet. I'd love to see yours if it's hosted anywhere! Could be a great reference when I do.
Really? It's a bit of a nonsense that I did so long ago so it's weird to hear someone interested in it...
The script has been lost to time. I wrote it 5+ computers ago and I don't even know where input that backup...
The overall gist is that CGI Bin specification sets Environmental variables, STDIN and STDOUT to various values. A minimal pure assembly that writes <h1> Hello World </h1> over stdout is your minimalist CGI Script.
A bit of research into what those STDIN/Environmental variables is needed for more. I knew this may e 20+ years ago but have long forgotten....
With access to the various input parameters offered over CGI, you can easily access form data (buttons and whatever clicked by the user). Use some smart file writing to store sessions and off you go....
-------
Maybe start with a Perl CGI tutorial. Then go backwards to C, and finally raw assembly by hand
I'm wanting to read this repository as a learning tool, so it'd also be nice to include docs—even AI-generated docs, but obvious I'd prefer docs with your own design notes and decisions—about the architecture of the code.
Thanks, I appreciate it a lot! I tried to comment my code pretty heavily (~3000 lines of code, ~1000 lines of comments all together), since this was a learning project for myself in the first place. Hopefully those will be of some use. But separate in-depth documentation is definitely a good idea, I'll work on adding that. In the meantime I'm always down to answer any questions about it!
Honestly, read the main file, ymawky.S first. Then I'd read through get.S maybe, checking parse.S on an as-needed basis for parsing-related functions. delete.S or options.S are pretty short, too, so give those a read too.
Modularizing it into multiple files was easier than I expected it to be, you basically have other functions/labels in other files, and mark them as .global at the top. The Makefile compiles each file into their own .o, which you then link all together. You can "b" or "bl" to any label from any other file, as long as it's global and linked together. Same with data in .bss or .data, mark them as .global and they can be accessed from elsewhere.
Love the honesty in the title. I'm 49, learned to code two years ago after 30 years as a carpenter, and "to give my life meaning" hits closer than most career ladders ever did.
Bookmarking this — going to read the source on my Sunday off.
Thanks for the link, bookmarking. I should note ymawky's main portability issues are unfortunately at the syscall layer rather than the asm layer. proc_info() and getdirentries64() are pretty Darwin-specific, so making it portable would require reworking that whole area rather than adjusting register/calling conventions.
I feel the guy’s suspicion towards any high level language. I exclusively programmed in assembly on C64, Amiga and the recognized that this ain’t sustainable on PC because there are more and more edge cases or different machine configurations.
I had a very hard time simply using and even utilizing C++ or Java.
C and Turbo Pascal especially was easier because the compiled code was very much resembling to hand written code.
As the author described, you can do in 4.000 lines what others can do with way less pain in 100.
So you build macros, come up with your own library and in the end you kind of build a meta language build on top of assembly because some lines are so hard to grasp that you delegate working code into a library for reuse.
It is funny how much we take conventions for numbers for granted. If you happen to know assembly and its intricacies you immediately will learn to work with a sign bits which mark negative numbers. But how do you know? Maybe you use the whole addressable space only for positive numbers.
Small things that make a huge different.
Nice article, I enjoyed your adventures and would do the same.
Thank you! The thing about eventually building your own meta language ends up happening all the time with bigger assembly projects. I do have a fair few quality-of-life macros too, but probably fewer than I should. I did end up needing to implement by hand what would be standard functions, things like atoi, itoa, strlen, memcpy, streqn.
Higher level languages are more convenient for 99% of things, but the directness of Assembly gives me a rush unlike any other. I didn't live through the C64/Amiga, but I was obsessed with old C64/ZX emulators growing up.
I don't know. Certainly the PC had a lot of options, but it wasn't impossible. My first piece of commercial software was written entirely in x86 assembler and had to navigate things like graphics card options and multiple sound card options. It could be done, it was just a lot more of a PITA.
Once I was doing 3D I quickly started moving everything but the inner loops to Turbo C, because I'm not a total masochist :)
I suspect that the test suite isn't great. Bun has so many different behaviors compared to other JS engines, sometimes just plain wrong or contradicting the spec. Test suite didnt catch those..
Honestly, just reading existing assembly to get a feel for how it works, and then violently googling everything that goes wrong. The ARM Architecture Reference Manual (aka "The ARM ARM") ended up being really helpful for looking up what specific instructions do and how they're called. Another really helpful tool is writing something in C/C++, and compiling with "gcc -O1 -S file.c" to see the assembly gcc generated. It helps to mess around a lot with smaller programs in gdb or lldb.
Even after we've all retired (pretty soon for those who can afford it) or transitioned out of software engineering (for those who can't), we'll still get to amuse each other with home-brew projects like this. Warm fuzzy feeling - I'll take it!
Assembly for the correct architecture is only one part of getting an executable running on a machine.
- Dynamic libraries (e.g. for calling into the kernel, but also user space dynamic libraries) are OS-specific (.so for Linux, .dylib for macOS, .dll for Windows)
- Executable format is OS-specific (ELF for Linux, Mach-O for macOS, PE for Windows)
- Dynamic loading and linkage of both the above are also therefore OS-specific
And even if you avoid external libraries, you still need to interact with the kernel to do I/O, and that involves system calls that are also non-portable.
Arm is very nice to write assembly for. Having a proper load/store register-centric architecture rather than a stack-centric like x86 makes the mental load of writing code go waaay down, so the attractiveness of HLLs for ease of writing code is greatly diminished on RISC.
Hell no. Far too many registers, not enough instructions, and (especially with ARM64) weird restrictions that arose from trying to pack things into 32-bit instructions as efficiently as possible.
I've been writing x86 Asm for a few decades. RISCs are simpler in all the wrong ways. After all, "just use a (stupid) compiler" was the whole philosophy.
Arm64 has plenty of instructions (although some convenient instructions listed in the ISA manuals seem to be rarely available in consumer hardware), and more registers is always better. I do find the lack of wide immediates annoying, but otherwise the fixed-width instruction set doesn't bother me at all.
Why stop there? Next, I'm prying open a CPU and poking the transistors with a 9V battery and paperclips to make it execute what I want. Slower, but you get so much control.
It's running in US and EU (helps avoid atlantic routrip tax), in this one i am doing some 100s of checks, not simple CRUD work. With Go you can optimize a lot without complexity of Rust.
Specifically how can you use pgx with sqlite while pgx is a postgres-specific library? Sqlc works great with Postgres or Sqlite, Sqlc works with pgx when connecting to Postgres, but pgx can't be used with Sqlite AFAIK
Woah, that's really cool! I'm glad you did that even if you didn't need to. I honestly think everyone needs to write more assembly, because it's so much cooler.
This post seems to now link to the writeup rather than the repository, sorry! The repo can be found at the top of that page, or directly here: https://github.com/imtomt/ymawky
Whoops that was my fault. Fixed now. (I emailed you, btw, that we'd changed your title, but I forgot to switch the URL back to the repo. Both links are cool.)
I'm sure I'm not the only one who has fantasized about doing something like this as a self-soothing enterprise. Kudos to you for actually doing it!
Hey, thank you! Means a lot. It's an odd sort of meditation, but is surprisingly the most almost-therapeutic project I've worked on. Something about the constraints of Assembly that really pull you into the minutiae and clears your head, maybe.
An agentic LLM should be pretty good at Arm64 assembly generation, but maintainability of large code could become an issue. Why would it not run on Linux?
I wrote it for MacOS because I don't have a Linux machine right now :( Once I get one up and running again, I'll probably work on porting this.
As for why it wouldn't run on Linux, there are some pretty big differences in the actual assembly. One pretty superficial difference is calling conventions -- MacOS uses the x16 register for syscall numbers, Linux uses x8. Calling the kernel in Mac uses "svc #0x80", in Linux it's "svc #0". That's ~120 lines that need to be replaced, but easy enough to just use sed. Syscall numbers are all different, as are the struct layouts for sigaction(), MacOS has an "sa_tramp" field that Linux doesn't have. Enforcing max processes is done here using the MacOS-specific proc_info() syscall, which can be used to get the number of children any given process has. Linux doesn't have an equivalent, so process tracking would need to be done differently. Finally, Linux has the getdents64() syscall, rather than getdirentries64(), which uses a different struct and is called differently.
I'm sure an LLM could make all those changes, but it's a pretty large codebase, so it would probably make some mistakes or miss things.
Example: spend time looking at health/nutrition. I assure you that in 5 years you will get more satisfaction and returns than the assembly code you wrote.
One important caveat - the subject of health/nutrition is SIGNIFICANTLY more complicated than assembly code, and not may sources out there know what they are talking about. Computers are child's play compared to biology.
Today, I just think, "how long would LLMs have taken to write this?"
I mourn the death of a human artform.
Well, look at this way, the needs of commerce are going to solve the conflict between practical and the beautiful. I think those of that value the beautiful aspects of coding will find new avenues of expression. For example, I'm about to get back into C programming to build a play.date game engine for an MMO.
Got an idea that you'd need assembly language for - now you can do it instead of..... never doing it because it would have been impossible for you in any practical way.
Look to the positive instead of lamenting something that never would have happened.
It's unbelievably exciting that you can now program a computer virtually without the limitation of your ability to hand code it.
The “you” doesn’t necessarily refer to you. Im addressing 90% of the developers out there. We love playing around technology… but I doubt we will be thinking the same once we become unemployable. But here we are, having fun with the tools of companies that want to finish us. How ironic
1. the time for optimisation is limited
2. the constraints are overlapping and just completely intractable beyond a single function (do you want to inline this, saving on the call and increasing binary size, or not do it because it's cold?)
3. they don't have domain-specific knowledge about your code, and even with PGO, they might incorrectly decide what's hot and what's not - typical example are program settings. You didn't enable a setting during PGO instrumentation, compiler sees you didn't call that path, shoves it out of line. Now your PGO-optimised code is worse than -O2. And compilers have different levels of adherence to manual branch hinting - on MSVC you get a reorder at best, Clang and GCC try much harder at [[likely]] and [[unlikely]].
4. There's still quite a bit of low-hanging fruit left, mostly because progress is jagged ;) For example our calling conventions generally suck - this is actually why inlining is so helpful - and the inertia makes everyone emit the default calling convention and that's it.
For example, did you know that compilers have very inconsistent support for struct unpacking? It can be much faster to write
than because the first one goes through registers on the MSVC ABI, the second one gets lowered to the caller passing a pointer to the stack. Before someone says "oh this just means MS sucks" - fair, but for std::unique_ptr the situation is the other way around... on the MSVC ABI the callee cleans it up so it's truly zero-cost, but on the Itanium ABI using it is worse than using T* as a raw pointer... see the GCC codegen :)These examples might seem a bit cherrypicked but this is only scratching the surface, not to talk about the codegen in higher-level languages, which is even more dreadful. Manually optimising your code can usually get a magnitude worth of free performance, which is just tragic.
I wouldn't even rule out LLM codegen in the future - although they're quite unreliable today so you'd get miscompiles like crazy - but there's just so much low-hanging fruit left on the table that it wouldn't be too out of step...
For me it's about making the computer do awesome things - I do not care how I get there I just want it to do whatever I can conjure in my head.
And a fair aside, the result will be "good enough" approximation of what I conjured in my head, but never the thing itself. For me to do the exact thing I conjured in my head it will require to pick up the mouse and draw the rest of the owl. I don't know if that's more telling of my imagination being demanding or my standards.
Probably not the case for anime pictures, but in other domains, you can use chatGPT as a first level and then go on the improve it from there. To make a parallel: if you draw with a pencil on a piece of paper, you would still think of yourself a doer even if you did not manufacture your pencil or paper.
So far I can't say the same for leveraging LLM's and, in the off-chance that there is, we have an entire software development industry that doesn't even know how to filter for "it".
When I go on a trek, the end of trek landmark is nowhere nearly as significant as the experience of reaching it.
If I were to be magically transported there without the lives experience it would take almost all of the joy out of it. Some people get a kick out of doing hard things that are interesting but seemingly beyond one's ability. Making it an easy commodity spoils the fun.
As for teleportation, if it were, say, trip to moons of Saturn I can make exceptions.
Sure, if you want 300,000 spoons, it’s far better to use a factory process and get essentially identical results. But if you only want a few spoons and accept (or even value) that the spoons will all be a little different, hand-forging them is quite enjoyable.
I’ve written enough assembly and done enough blacksmithing to know that the metaphor isn’t quite apt. But there’s both tremendous effort and satisfaction involved in both.
The difference is that now it is worthless: there is no learning, no person caring about the result, nothing aspirational for the public to look towards... we used to enjoy those challenges, used to be proud of solving complex problems... now? Yeah, whatever, execute execute commit push, let another LLM "review" and call it a day.
I wouldn’t be sad about defeating lower complexity challenges. There are always higher complexity challenges that arise once we start operating in a world when you can do more. The bar raises.
Once insurmountable challenges are now trivial to implement with, as you say, "low effort."
For those who were attracted to computing by the grind and the grand narrative that you, too, with sufficient effort, discipline, and merit, could become a revered craftsman, LLMs trivialize an entire lifetime of practice. I can't think of anything more demoralizing.
The equivalent is something like hand tool woodworking - it’s still a thing despite the advent of machines, but more of a niche. You can still aim to become excellent, but maybe you won’t be famous.
Or employable. Which sucks if you're over 50.
Writing whole software projects in assembly has been worthless and pointless for a couple of decades now. Even the projects who can put together a solid case will limit assembly to very specific components executed only in specific bits of a hot path. Perhaps the most performance-sensitive code we have today is high frequency trading and that field is dominated by C++.
Also, virtually all mainstream compiler suites have flags that output assembly,and that feature is largely ignored and unused.
What's next, human human contact abstracted away by brain stimulation?
And the transhumanist arsewipes gonna have a field day.
Never too late to ignite the nukes...
Of course! Corona/junta/scarecrowvirus don't transmit over the wire, while ads, taxes and surveillance do alright!
Only exciting if you already got a lot of programming under your belt, like Carmack, or a product guy.
But you're not doing it. The ai is doing it.
If the op can write a web server in assembly language then I'm pretty sure they could have done it in a higher-level language. But they did what they did for the journey and the learning along the way. Vibe coding it omits all that, and misses the point of the exercise.
Nobody actually needs a web server built in assembly language, it serves no practical purpose. And I say that as someone who learned to program 6502 assembly language in 1983 and has sporadically used assembly of various architectures since.
The absurdity of building it would have been the curiosity draw pre-LLMs, but when it existing is just a series of prompts away it really loses all of its meaning.
But yeah... hooray for AI. Can't wait until we learn to harness it to supercharge the most important and valuable thing we do as a human society in modern times: stuff increasingly intrusive ads in front of everyone at all times.
Wasn’t it used for that before anything else? Google invented transformers and had LLMs internally before chatgpt got released. Presumably they were using them for ads, because their public demos were insane things like talking to the moon.
According to friends who worked at Google (no direct knowledge myself, so don't know exactly how true it is), they mostly sat on the tech. Google News had internal prototypes of using them to expand/contract/summarise and/or add details/context to news articles and translate them to different languages, but it was never fully productised.
Then after ChatGPT got popular, sudden panic to start using them in products company-wide.
If LLMs are good for doing things we aren't already doing, it indicates the overall addressable "value" that LLMs could provide for such things is actually quite low. If the task has necessary prerequisites that you don't currently possess, but you haven't spent the effort to jump that hurdle yet, then it's a good indication the value of completing that task is very low. Even if, maybe especially if, we're talking about personal projects where the value proposition is personal and not momentary, it indicates the person already feels in their bones that the return on doing this thing is not worth the effort.
I'm struggling with this with my leadership at work. We have developed a thing that is going to remove the need to hire temps [0] for data entry when we get clients who send us large amounts of their "data," aka "a thousand 30-slide PowerPoints each with one line graph of interest sitting in the corner of one slide somewhere." It is an ask that comes up a lot, it's always very expensive in both the time and money axes for the client for that task, but overall it's just a small part of the contact budget. I'm all for using what we've built to cut down the time cost for our clients, but my leadership thinking it's going to lead to massive cost savings for our clients seem to forget just how much time we spend in meetings and planning and documentation and testing and reevaluation and more meetings versus actually executing on things.
It's also bad business. To me, giving results faster should be a premium offering. We should be charging more, not less.
[0] We don't actually hire temps, we turn our junior data analyst into temps by burning them out with tons of unpaid overtime. They then leave and we have to back fill them at rather extreme cost of overhead for hiring compared to the direct contract overtime we didn't provide.
Isn't that kind of view pathetic and sad, though? Why would anyone pick up and guitar or play a piano if they could just listen to the same song already made by someone else? I struggle to understand this view of people that pretend to not understand why being an expert of some skill is perceived as valuable by some people. This is also belies next problem with this line of thinking which is that it says "we don't need to learn X to do Y because we have AI" but misses the same AI could easily replace the need to have you think to do Y in the first place. I don't know.
So, in my view, more people will (or should) understand now what is hard when building complex things, if they pass the stage of "I have a nice POC that works for this one case".
Yes, it's not deterministic, and if you were using it commercially, the ROI would be terrible, and it's certainly not reliable but for a hobby project.... why not?
Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.
LLMs lower the barrier for execution - they make you faster. The unstated question is: faster at what - they can make you faster at something clever, or faster at the entirely wrong thing...
Your point is correct if we're looking at it through a scarcity lens - the effort to make it certainly decreased a lot - but that doesn't mean that anything is now worthless. We can just move onto doing bigger, better things now, until we hit the next limits...
But we know that long term use of LLMs does not lead to better understanding, it leads to reliance on the LLM for the person to be able to function at their job.
I'm not claiming to have a definite answer to either, but I think the right question to ask is - are you going to benefit from using it in the long run? If yes, carry on, if no, re-evaluate what you're doing :)
If you come to rely on specific tools such that you can't do your job without them, you're no longer doing the job you think you're doing, you're now just a tool operator. If I don't have a computer of some kind, I'm not writing software, I'm just a manager. If my team can't work because GitHub is down, then we've done a bad job of being software developers.
The experience taught me that there are two kinds of tools: those that are necessary and those that are nice to have. Yes, that job sucked, and yes, I quit that job, but more because they refused to pay me the overtime I needed to get it done with such crappy tools.
I had another job where we were one client of many on site with a vendor for a training event and the vendor couldn't get a system configured correctly for our cohort to continue on. Part of the problem was their configuration system was garbage, very easy to get wrong, very time consuming to manually edit. While they were dicking around with throwing edits against the wall, I wrote an HTML page with JavaScript to make a UI to edit the data in an much more natural way and then generate the config file. It took 10 minutes and saved us hours of waiting so that we could continue on with the training. Perhaps the takeaway from that experience was that Valve's engineers write shitty config systems. All I know is we got the training event done and I walked away with a piece of paper that said I was now a Certified Hardware Vendor, which we then used to sell more contracts on our own.
Some 120 years ago recordings music was a living phenomena produced in the moment. Musicians worked at restaurants and coffee shops everywhere, being useful without being super stars.
Music didn’t disappear with recordings, but the works is certainly different.
With LLMs, we can't tell anymore if something is a labor of love with hundreds of hours of work behind it, or half a dozen prompts to Claude Code.
Would we have considered writing a server in C writing it in assembly? No.
https://imgur.com/a/Dy5rUku
Yes, an LLM can write it, it’ll probably work. Yet, it’ll remain meaningless slop while this is not.
You do indeed need to do quite a bit of thinking and problem solving, to build things with an llm.
If you disagree, repeat this project, so you can share with us how little thinking it required.
I'm afraid it's an elite skill in the sense that juggling is also an elite skill. It's impressive for the first few seconds you gaze into it, but once the novelty factor wears off you understand that it's wasted effort that leads to a project that suffers from a massive maintainability problem, is limited in which platforms it can run, and brings no advantage whatsoever. It's an gimmick that has no practice use.
This is the software development equivalent of an amateur guitarist posting shredding videos on YouTube.
In the same way we appreciate Japanese wood joinery, why not not just appreciate this? Someone might even learn a trick or two reading it.
No, not really. This is exactly the opposite example of software craftsmanship. Software craftsmanship involves things like technical excellence in delivering maintainable software that is adaptable to change.
Picking assembly, of all things, for a web server represents a complete failure in the analysis of both the problem and solution domain.
https://en.wikipedia.org/wiki/Software_craftsmanship
This sort of project is more in line with parlour tricks, juggling, and stunt shows. Trying to frame this sort of project as software craftsman is like discussing the whole Jackass series as cinema next to Hitchcock and Scorcese. It may take skill and practice to be punched in the nuts, but that doesn't make it a craft.
To which change, exactly?
We need to stop thinking of software as carpenters where the magic is some physical skill and that is the "CRAFT WE MUST PROTECCT".
And at least your comment was grounded in reality; a lot of people I talk to (who are not coders) seem to think a good software engineer writes every line and every word with thoughtful genius and AI just spams code so one is better than the other. And they are convinced its some naunced smart take and they understand software development on a inner level or whatever.
And the base assumption still holds true (pure AI-generated code is garbage) but its mostly because its badly designed and is still a pretty poor architect. And there is a need to pushback against slop but why do we need to elevate typing code as if its some sacred acctivity? Most of the work a good coder does is in their mind with little connection to the phyiscal reality of the world.
Look, I still got my physical copy of Michael Abrash's Graphics Programming Black Book with its genius content about hand-optimizing cycle count on 486 and Pentium processors, beating compilers at that time.
It was an absolute artform, but completely obsolete by today.
Maybe it's finally time to move on from being a career programmer.
Artisanal code, or bespoke code, has always been the best paid and most satisfying work. If we no longer have a new generation of curious people who enjoy solving hard problems, it's only going to become more valuable.
What I realized was that knowing what my software did, being able to explain every part of it and being able to rewrite it from scratch if necessary, was much more valuable than just delivering it. The powers that be who run companies are looking for communication, so they understand what they're getting, someone who can speak the same language as them and materialize it into code that works. LLMs are a decent imitation of that, but they're fatally flawed, because they never understand a whole stack.
> And the only people who will ever be in that position are the ones who take the time and effort, out of sheer curiosity, to learn how things work.
People learn something new all the time, AI does not learn anything, it just simulates and hallucinates. But the core question is not addressed with that. What would you do if you have to compete against AI, and AI is better? We already see these with the new generation of humanoid robots from China. Those things make Boston Dynamics robots look like tinker-toys in comparison - already as-is. Give it ten more years and we finally reached AI skynet for real.
success through cleverness and inventiveness - not yet fucked by AI
achievement through stubborn persistence - you can still dig deep holes in the garden
you still could have a character, if you were lucky
human agency? not yet fucked up, but it's gonna be
achievement earned through one's own qualities or effort? - intact somewhat
Congratulations to the OP for the accomplishment.
I wanted to see how an LLM would do writing one in pure 8088 assembler for CGA and it one-shot a nice demo (I fed it the vectors for the Elite ship in the prompt):
https://imgur.com/a/Dy5rUku
I also wrote a demo for 386/CGA hardware last year and I plan on porting that one to an 8086 as I think it is simple enough that it should be able to run on one. I've done a demo for the Sega Master System and I'm about to start a project for the Game Gear.
I also made a bare metal demo for the Leapster Explorer (an ARM-based kids toy).
I don't use AI for any of this because for me the interesting part is the journey as well as the final result. I want to learn how things work, and I enjoy writing the code.
You don’t have to. It’s perfectly okay to take your modern car to a mechanic and hire a contractor for your remodeling needs.
But some people like to do it themselves, even when the project is large.
Not all languages use NULL terminated strings. I think Rust actually stores the string length alongside a pointer to the start of the string data. You can do the same in C, but you'd have to do it manually using a struct. In assembly you could do the same thing since you get to decide basically everything.
https://www.youtube.com/watch?v=y8PLpDgZc0E
And super educational. Since then I've been pondering which problems require dropping down to the assembly level. E.g. implementing a JIT compiler, a coroutine runtime, etc.
In a comparison between a similar fork-per-connection server written in C and this, I would imagine the throughput would be about the same, because the bottleneck in this model is fork() itself rather than the actual code. It probably matters more for binary size and startup time than requests/sec. Would be fun to actually benchmark, though.
P.S.: I would love a copy of that book please!
In general, stable syscall numbers are just a Linux thing. Everyone else uses blessed system libraries
Humbling.
One of my first assembly projects was a CGI Script 100% in x86 assembly.
A full web server is certainly more impressive! Though I'd recommend to beginners to look up CGI and mod_cgi in Apache first lol
The script has been lost to time. I wrote it 5+ computers ago and I don't even know where input that backup...
The overall gist is that CGI Bin specification sets Environmental variables, STDIN and STDOUT to various values. A minimal pure assembly that writes <h1> Hello World </h1> over stdout is your minimalist CGI Script.
A bit of research into what those STDIN/Environmental variables is needed for more. I knew this may e 20+ years ago but have long forgotten....
With access to the various input parameters offered over CGI, you can easily access form data (buttons and whatever clicked by the user). Use some smart file writing to store sessions and off you go....
-------
Maybe start with a Perl CGI tutorial. Then go backwards to C, and finally raw assembly by hand
Really cool project though!
Modularizing it into multiple files was easier than I expected it to be, you basically have other functions/labels in other files, and mark them as .global at the top. The Makefile compiles each file into their own .o, which you then link all together. You can "b" or "bl" to any label from any other file, as long as it's global and linked together. Same with data in .bss or .data, mark them as .global and they can be accessed from elsewhere.
Bookmarking this — going to read the source on my Sunday off.
I had a very hard time simply using and even utilizing C++ or Java.
C and Turbo Pascal especially was easier because the compiled code was very much resembling to hand written code.
As the author described, you can do in 4.000 lines what others can do with way less pain in 100.
So you build macros, come up with your own library and in the end you kind of build a meta language build on top of assembly because some lines are so hard to grasp that you delegate working code into a library for reuse.
It is funny how much we take conventions for numbers for granted. If you happen to know assembly and its intricacies you immediately will learn to work with a sign bits which mark negative numbers. But how do you know? Maybe you use the whole addressable space only for positive numbers.
Small things that make a huge different.
Nice article, I enjoyed your adventures and would do the same.
Higher level languages are more convenient for 99% of things, but the directness of Assembly gives me a rush unlike any other. I didn't live through the C64/Amiga, but I was obsessed with old C64/ZX emulators growing up.
Once I was doing 3D I quickly started moving everything but the inner loops to Turbo C, because I'm not a total masochist :)
It would be awesome to read a blog post about the project. Your approach, lessons learned, unexpected stuff, etc.
- Dynamic libraries (e.g. for calling into the kernel, but also user space dynamic libraries) are OS-specific (.so for Linux, .dylib for macOS, .dll for Windows)
- Executable format is OS-specific (ELF for Linux, Mach-O for macOS, PE for Windows)
- Dynamic loading and linkage of both the above are also therefore OS-specific
The last time I did anything in assembler was x86 under DOS. Your code makes ARM64 with a modern OS less scary than I thought it would be.
I've been writing x86 Asm for a few decades. RISCs are simpler in all the wrong ways. After all, "just use a (stupid) compiler" was the whole philosophy.
jk. Metal as fuck. Love it.
https://2ton.com.au/rwasa/
...
Nothing beats Go.
When you use HTMLX (goat) + sqlc (goat) + pgx (another goat) + Chi (yet another goat) and Sqlite (goat).
Most apps will not need anything more than Sqlite, i've several sqlite apps doing a couple of million visits per day.
Compiles to signal binary blazingly fast.
Deploy using systemd service, capture logs with alloy / Loki graphana setup, set up alerts and monitoring and go home.
And you can serve millions of requests on a server with 512MB RAM.
I don't think you'd ever need more speed than this.
Everything else is bloated, slow and doesn't give you enough room for optimization.
Here's the latency of one of my hobby projects (network latency not included): https://i.ibb.co/hJ6FQtyw/d3d6c9d15765.png
Request rate: https://i.ibb.co/Fq80nfJ4/67fcdbdb7491.png
It's running in US and EU (helps avoid atlantic routrip tax), in this one i am doing some 100s of checks, not simple CRUD work. With Go you can optimize a lot without complexity of Rust.
I didn't need to implement an Intel RDRAND streamer in C and assembler, but it was a ton of fun: https://github.com/ehbar/rdrand-stream
OP, I really liked this project. Kudos for publishing it!
I'm sure I'm not the only one who has fantasized about doing something like this as a self-soothing enterprise. Kudos to you for actually doing it!
As for why it wouldn't run on Linux, there are some pretty big differences in the actual assembly. One pretty superficial difference is calling conventions -- MacOS uses the x16 register for syscall numbers, Linux uses x8. Calling the kernel in Mac uses "svc #0x80", in Linux it's "svc #0". That's ~120 lines that need to be replaced, but easy enough to just use sed. Syscall numbers are all different, as are the struct layouts for sigaction(), MacOS has an "sa_tramp" field that Linux doesn't have. Enforcing max processes is done here using the MacOS-specific proc_info() syscall, which can be used to get the number of children any given process has. Linux doesn't have an equivalent, so process tracking would need to be done differently. Finally, Linux has the getdents64() syscall, rather than getdirentries64(), which uses a different struct and is called differently.
I'm sure an LLM could make all those changes, but it's a pretty large codebase, so it would probably make some mistakes or miss things.
I'd be doing the same kind of thing if I had more free time.
Example: spend time looking at health/nutrition. I assure you that in 5 years you will get more satisfaction and returns than the assembly code you wrote.
One important caveat - the subject of health/nutrition is SIGNIFICANTLY more complicated than assembly code, and not may sources out there know what they are talking about. Computers are child's play compared to biology.