A modern OS is definitely a virtual machine, where each process perceives that it is running on a single CPU with its own single contiguous bank of memory. Threads are a bit of a leaky abstraction but whatever.
What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact same functionality, with a different interface. Rather than read/write as syscalls, you have to send SATA commands to disk, or commands to a network card, or whatever. Instead of an exit system call as an interface you work with a hardware interface that powers down the physical machine.
Containerization is actually a logical next step from this. Why virtualize a REAL hardware interface only to virtualize a fake one on top of it? The only reason to do that is if you want multiple fake interfaces, eg Linux and Windows. When virtualizing a bunch of Linux machines, mostly you really just want isolation of your processes. Virtualizing real hardware is a hack because Linux was not capable of isolating processes on its own, so you had to run multiple copies of Linux! Now with cgroups and other resource namespacing in the kernel, it can isolate resources by itself.
>If the profession ever wants to produce anything reliable in C++
This has already been done, so you are obviously wrong.
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.
Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.
The different examples are all pretty much just different ways of writing the same thing. And then another different way of writing the same thing is presented, with "db:" prepended. Huh.
The only thing that is substantially different between any of these is the engine/protocol/adapter/whatever section. Perhaps that field should always refer to the protocol type and not the driver, but I consider that problem pretty negligible.
Because it's more than that. It wasn't originally to speed up run time, but compile time. That history is wildly fascinating to me. We tend to take compile time for granted, unless we are bitching about Scala, or compiling C++ at Google.
The author also addresses the importance of history. Voodoo knowledge _does_ pervade modern computer science, and I for one am happy to see something different.
If you ask the average 1st world human being "What are Macs good at?" They usually say something about ease of use and multimedia stuff. It's just what people think.
Now, on my Mac, I do exactly zero multimedia related things. So I agree that the multimedia thing isn't necessarily true, but that's what I hear about Macs from not-technicals.
"Poe's law, named after its author Nathan Poe, is an Internet adage reflecting the idea that without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism."
I agree on some level, but you also can't say that this is a great thing. All these extreme opinions...
Can't we all just agree that Google is pretty great, but going through an annoying phase right now? Google _is_ taking advantage of the fact that most users won't leave, and I don't appreciate that. But at the same time, we are all slowly losing our patience, and in the long run this behaviour could hurt Google. I hope for everyone's sakes that this all settles down.
I also have this question. There are technical reasons that PostgreSQL is better than MySQL, especially when it comes to features, but none are mentioned here.
> From the development perspective Postgres was a necessity. Not a slam dunk but objectively a better tool for our use case.
In what way?
> And if we have countless reasons, all good, but they’re nuanced and technical and tricky to impart to a non-technical audience, where does that leave us?
HN would be interested in those reasons, I know I am.
> The vast majority of the company probably still doesn’t get why we went through this painful contortion at the expense of doing, well, a lot of other things.
Neither do I, since none are given.
Though I also understand that the point of the post was about trust. It's great that there is that trust within SparkFun, I would love such an environment.
I'm tempted to say: "unless mongoDB gets a lot better, this is not going to be true." However, a minute fraction of the rails community is large sites, so it doesn't matter.
I also think a lot of people like rails because they find ruby extraordinarily beautiful. As much as I like JS, beautiful syntax is not its strong suit.
They do, it's just a complex and involved process. I don't recall exactly but I believe it might also need an upfront investment as a music publisher or something? I too am lazy.
Again, I think one with deep understanding would know that leaving it unset would result in zero, but also know that initializing it declares intent of the original author, and is thus useful.
Arguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do.
A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example from the slides, the virtual destructor: making that class virtual when it shouldn't is a waste of CPU cycles _and_ bad documentation for future developers.
What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact same functionality, with a different interface. Rather than read/write as syscalls, you have to send SATA commands to disk, or commands to a network card, or whatever. Instead of an exit system call as an interface you work with a hardware interface that powers down the physical machine.
Containerization is actually a logical next step from this. Why virtualize a REAL hardware interface only to virtualize a fake one on top of it? The only reason to do that is if you want multiple fake interfaces, eg Linux and Windows. When virtualizing a bunch of Linux machines, mostly you really just want isolation of your processes. Virtualizing real hardware is a hack because Linux was not capable of isolating processes on its own, so you had to run multiple copies of Linux! Now with cgroups and other resource namespacing in the kernel, it can isolate resources by itself.