I hold out forlorn hope that someday my modern workstation will achieve the responsiveness and fast boot times of my Commodore 128. Not joking in the least.
(a) issued an async read
(b) did some computation
(c) used the buffer filled in by that async read
... without actually seeing if the read completed. Hilarity ensued when the CPU got faster. This was in stuff that shipped to hundreds of thousands of customers.
If you're having a good day, you can definitely address that problem by reading device drivers for a few hours.
Macs today sleep like Windows machines a decade ago
I guess when manufacturers want to do something well they really can integrate everything.
When I was younger and my family had our first internet connection my dad said "One day internet webpages will load like changing channels on the TV - click click click. instant page loads"
Today TV soo much slower and webpage are... well... you know.
Do you think I should consider making it a priority to code in a fairly low-level programming language (e.g. Rust) without overhead, and count cycles so that most tasks are done within a single screen refresh?
I can't make the rest of users' systems more responsive but I could make my own software as fast and efficient as possible.
The other alternatives are Python, which would make it easier to ship large features but would come with a large overhead (full interpreter) since it's an interpreted language.
Sometimes not though, like startup times, but there is not so many use cases that this counts, like 1password starts slower with each release.
EDIT Not many hackers on hackernews apparently.
Holding your own code to a high standard is great, but wouldn’t it be nicer if you could offload more of that into the tooling and spend more time on the problem or making the code even cleaner?
Also as a side note: I always find it funny that a flag that represents all warnings doesn’t actually turn on all warnings.
C also has the advantage that there are many, many different compilers targeting many, many, /many/ different architectures. My own favourite is VBCC, which is lightweight enough that I was able to write my own backend for my own toy CPU project, and even build the entire toolchain - assembler, linker and compiler - under AmigaOS.
For the remotely hosted dependency thing, I think it’s pretty easy to vendor dependencies in most realistic C contenders, and a really simple litmus test is just yanking your network cable and doing a fresh build.
The ecosystem thing can be a bigger deal, but again it really depends on the problem domain. There are lots of high quality, non-C libraries for C to always be a clear winner. I think it’s more important to take a step back and make sure whatever language you pick is well suited to the task, rather than assuming any individual one will always be. Knowing multiple languages is handy for this, since that’s more ecosystems that you can pick from, rather than just tying yourself to a single one.
Yes, absolutely - and of course C isn't immune to ecosystem problems, either. I remember the pain of working with GNU autotools back in the mid 2000s - in fact it's probably that experience (plus trying to use bleeding-edge tools written in Python!) that left me so cautious about external dependencies today.
VBCC's backend interface is well documented, which helps a lot - and there's a skeleton "generic RISC" backend which is trivial to copy and use as a starting point - I found it very useful to be able to tweak a working backend and observe how the generated code changes, while I was getting a feel for how it all hangs together.
VBCC does have an unusual license, however - commercial usage requires permission from the author.
Some languages (e.g. Haskell) make it easy to write code that does more computation than intended. If you use one of these languages, make sure you know what you’re doing.
If you use a language with a truly horrible GC, you might experience excessively long pauses. Similarly, if you produce too much garbage, you might have issues.
If you use a language that can’t multithread properly (sigh, Python), moving tasks off thread is a mess.
Otherwise, one can write perfectly responsive software in just about any language.
Maybe. Premature optimization is said to be the root of all evil...
But at the same time - the assumption that everything will be easier and faster in Python rather than Rust or C++ is often invalid. Sure, for smaller scripts it almost always is like that, but once your app grows, this may stop being the case.
Start with a language that's convenient for you and with which you can release an initial version. Then get an understanding how it behaves in terms of performance, and draw your conclusions.
> as fast and efficient as possible.
Responsiveness is not the same as speed or efficiency. Of course it's important to be fast and efficient, but it is even more important to not just start crunching numbers and ignore the user and the rest of the system.
Do your hard lifting asynchronously and have a thread attending to user input and your UI (or even different threads for these two tasks). And this is easier said than done!
Also remember you'll have to try and work around delays and slowdowns due to other apps and the (non-realtime) OS. Specifically, you might have to play with thread scheduling and I/O priority (although - that's usually the user's rather than the app's job).
Additional notes:
* Also consider C++; it has some advantages and disadvantages relative to Rust (which I obviously will not get into), but it has seen a whole lot of progress in recent years, in particular w.r.t. the ease of doing many things which used to be painful.
* If you think of Rust as low-level, then your head must be in the clouds... :-P
The full quote, because it always gets butchered to "premature optimization is the root of all evil":
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
In the 70s you might've needed a reason like optimisation to commit evil. These days apathy and cargo culting do it perfectly fine without optimisation even coming into the picture.
Most folks want web, email, images, and even a bit of security from their computer today. Could always be faster, but I think the days of "bam!" ready are past due to those requirements. Unless the computer is only sleeping, like an iphone for example.
Now with windows 10 on a much faster pc, clicking apps like Firefox, the start menu, word take seconds to load.
I recently fired up my windows 7 VM to mod an old game console and it was exactly how I remembered. You click something and it's instantly opened.
Sure, but a modern computer also has orders of magnitude more processing power than devices that only ran a command line. There is no reason that we cant have both, except incompetence and/or bad economic incentives.
For example, properly displaying text now requires having a copy of at least the most important parts of the Unicode standard in memory. Things like knowing if a character occupies one, two, or many character cells are very important for even a simple text terminal. Word splitting, kerning, shaping, bi–directional text display, the number of possible refinements grows without bound and all of them need metadata about each and every character. Your average web browser has megabytes of the stuff just sitting around in memory so that it is ready as soon as a character has to go up on the screen. Older computer just didn’t have that kind of memory to spare.
If you want the old–school experience you can still boot straight into the Linux Console, which still thinks that there are only 256 characters. It seems to be reasonably snappy.
I suppose you could put a ton of OS and libraries in a (modern equiv of EEP)ROM for immediate access. The original Macintosh was kinda like that. But things went the other way when disk storage dropped in price a lot faster than chip storage.
Maybe we're back to a point where the former is economically viable, but there would be a lot of historic baggage to overcome.
Reading a tape? That took several minutes.
It just dumped you into a prompt though, and loading any program was really quite painfully slow.
A modern bios goes through more cycles during the boot phase of a typical machine than a C64 would see in its entire lifetime.