521 karma · joined November 25, 2016
I've seen several examples of the compiler being brilliant until suddenly a simple change makes it not brilliant at all anymore. Compilers are just tools.
Does this also apply to the in-language build system? Given both Rust and Zig's ergonomics, it just seems so brilliantly simple (at least in hindsight) to let the build system be a library. Is it just coincidence that I've only heard of this approach for zig and Jonathan Blow's language, or is there a technical reason this is more difficult than it seems?
That said, there's a chance I just read it late enough in my career to be more ready for its content.
The really hard part is the modelling part, where you transform the problem to a mathematical statement and vice versa. It's very easy to misinterpret both the problem in terms of mathematics and the mathematical result in terms of the problem. All the wrong answers to brain teasers like the monty hall problem, the tuesday boy problem etc., are right answers to the wrong question.
Unfortunately, in education we do not seem to want to discuss the modelling part on equal terms with the theory. We seem to be okay with solving the entire problem, or solving just the theoretical part with no regards to the application, but expressing just the mathematical problem to be solved is never appreciated. In a calculus setting, this could be deriving the answer to some physical problem depends on the solution of some partial differential equation -- even if you do not have the tools to solve it outright.
My guess is that it's just easier to teach theory with clear cut answers. Modelling the real world is ambiguous and hard.
The work in TFA describes patches to make the Linux kernel communicate with the hypervisor (sharing information like used memory pages). In my book that's pretty sophisticated.
EDIT: The work appears to be available on Github https://github.com/microsoft/WSL2-Linux-Kernel/commits/linux...
The RAM issue is a clear setback, and makes it annoying trying to do large compile jobs on the Linux side, though it's been a while since I've tried it. In theory it could be possible to handle coorporation between the Linux and Windows RAM usage patterns since they're running a very heavily modified kernel. I'd be very interrested in knowing if anything is hapenning on that front.
Metaprogramming is pretty wide, ranging from primitive textual substitutions like C macros to type-aware hygienic macros ala rust, and from limited scope like C++ templates to full-on program writing like in lisp.
In C and C++ (current versions) the entire module system is built-up around the metaprogramming hack of doing #ifdef header guards. Even this is a bit error prone, but the alternative is only expressible as a compiler intrisic (#pragma once).
In languages like C, Go and early Java, the lack of generics (a type of metaprogramming) makes it impossible to write type-safe generic algorithms forcing casts to void*, interface{} and Object resp.
Implementing type checking for printf-like constructs requires compiler-intrinsics or C++17 constexpr meta-programming.
In C and C++ you must manually implement serialization and deserialization for structs and everything else that is naturally expressed and iterating over the elements of a struct. Alternatively you could use something like protobuf, which (surprise!) has compiles your protobuf file into a C++ program you can include. Using something like Rust's serde is /much/ simpler, and is only possible due to metaprogramming.
Surely that depends on the hashing function. Moreover, these passwords are usually used for authentication rather than encryption, making the speed of the GPU irrelevant.
Even for encryption, you should probably store a strong key on a hardware TPM and only using the weaker key to authenticate towards the TPM.
Having proper metaprogramming is also really great. Sure, you can definitely go overboard, but a few things are just only possible with proper metaprogramming like quickly printing the value of a struct or enum for debugging and easy serialization/deseralization (like serde does). It's just a huge boon for doing introspection.
But it's not just the particular features that are important, it's the fact that best practices are integrated into the language. There are standard solutions for most things: error handling, unit tests, build system, package management, formatting style, etc. Sure, if you have a long-running C++ project, you're gonna have answers for all that, but the consistency matters when you want to integrate libraries.
I think if you're going to use Rust, you should try to speak to its strengths rather than retrofitting existing C++ idioms onto it. There are both real advantages and very real costs to doing this, and you certainly shouldn't just switch an existing C++ codebase to rust.
In the mid 2000's the Mac really took off due to being a good-enough Linux replacement on the command line, while taking care of all the hardware integration and providing a sleek desktop experience. This really helped the Mac take off among hackers. This system wasn't as open-source as Linux, but it was good enough: Most of us don't want to mess about with the desktop stack. If the stack we care about is open-source and runs across many systems, then we still have the freedom. I find it fairly easy to work on both Mac OS X, Linux and WSL2 -- but not pre-WSL Windows.
The inclusion of a Linux kernel really seems to cause a lot of confusion. No, Microsoft is not about to remove the NT kernel. No, they're not about to supplant Linux. WSL1 did what the guys from Illumos and FreeBSD have also done: since the Linux syscall interface is quite stable, the NT kernel can simply implement these syscalls and handle them appropriately. The was that the NT kernel was still sufficiently different that the filesystem performance was quite poor and complex applications like Docker required more kernel features than was provided by just the syscall API.
Including a Linux kernel is really the nuclear option: rather than trying to fit Linux applications in Windows, they're running in their own world and providing integrations into this world. This means you can now run Docker on WSL2 for instance, but it's also complicated: Kernels really like to think that they own the world, for instance they keep memory around to use for later. WSL2 dynamically grows the amount of RAM allocated to the VM, which is quite clever, but I don't know how/if they're going to handle freeing memory again -- here the NT kernel really needs to communicate with the Linux kernel.
Anyways, the upshot is that no, Microsoft is not going to take over the world, but perhaps it will be easier to use a Windows laptop which supports all the stupid Enterprise software I need but still have a Linux shell for actual work.
[1] https://engineering.docker.com/2019/06/docker-hearts-wsl-2/
'awk' is really a very beautiful little language. It's concise enough to solve many tasks in a single line, making it easy to use interactively while still being able to grow to moderately-sized scripts. It's not supposed to replace a full-blown scripting language like Python, but for processing files line-by-line it's superb.
So far it's pretty good. Photo sync works from Phone works perfectly, and the desktop apps are decent enough. I did get bitten by a recursive folder-sync bug [2], which is certainly not of Dropbox quality but at least pull-requests are welcome.
Mathematics is most commonly described in the language of set theory, where objects are constructed from basic building blocks to create bigger blocks. This is much in the same way as algorithms are described in something concrete, say a programming language.
At some point, certain high-level constructs started to appear, where the same high-level behaviour was exhibited in otherwise completely disconnected fields. Explaining what is going on then started to become messy, for example take following quote from Hatcher's Algebraic Topology concerning covering spaces: "This is often called the Galois correspondence because of its surprising similarity to another basic correspondencein the purely algebraic subject of Galois theory". The problem is that in order to understand this, the reader has to understand two fields which are not at all connected and furthermore, the relationship looks nothing alike in the language of set theory.
Category theory was invented as a formal language which could describe such high-level behaviour. In this language this language we would could now say that there is an "contravariant equivalence of categories", which helps if you've seen it before and doesn't help at all if you haven't.
So category theory is massively useful in understanding the similarities between fields, and can be used to transfer understanding from one field to another. It it also useful for understanding more abstract fields where the intuition must be gained by analogy with something more concrete. It doesn't do much in itself, and I don't think it makes much sense to study the mathematical aspects of category theory without any good examples to apply it to.
What does that have to do with engineering? I'm not expert here, and haven't yet read the linked book, but one could hope that certain similarities could be described in terms of this new language. Then concepts which now only live on as the expert experience of working practitioners, might be written down and hence taught directly rather than indirectly. One could hope that certain problems have common solutions which can be re-used across fields.
That's not at all what ECS's are about.
While that may be obvious to you, it's not obvious to a lot of programmers (myself included) who grew up learning about object orientation, abstractions and modelling behaviour on the real world. ECS's for all their added complexity come with the breath of fresh air that is classical imperative programming where all the data is just available.
There are scant few sources for learning this, Handmade Hero being a notable exception.