HN user
Knoppix was the first Linux distro I ever tried back in the early 2000s. IIRC it was only a few hundred megs.
At the time it didn't have the overlayfs feature which often felt limiting since most directories were read only. Slax felt like a serious upgrade since you could install more packages after booting the CD.
I think Knoppix was the original live CD distro though?
Cool, I'll have to try it in the next 18 months before they turn it down.
"... the equivalent of a broadcast TV channel that only showed 7 minutes of actual TV content per hour, devoting the other 53 minutes to paid commercials and promotions ... Almost no one would watch such a channel."
QVC exists. That channel is ONLY ads.
Not to detract from the point, which seems to be "yes what this other guy said."
Thanks for the post!
Question: While you would want any official arch built natively, maybe an interim stage of emulated vm builds for wip/development/unsupported architectures would still be preferable in this case?
Comparing the tradeoffs: * Packages disabled and not built because of long build times. * Packages built and automated tests run on inaccurately emulated vms (NOT cross compiled). Users can test. It might be broken.
It's an experimental arch, maybe the build cluster could be experimental too?
I don't know the reason TextFormat was invented, but in practice it's way easier to work with TextFormat than JSON in the context of Protos.
Consider numeric types -
JSON: number aka 64-bit IEEE 754 floating point
Proto: signed and unsigned int 8, 16, 32, 64-bit, float, double
I can only imagine the carnage saved by not accidentally chopping of the top 10 bits (or something similar) of every int64 identifier when it happens to get processed by a perfectly normal, standards compliant JSON processor.
It's true that most int64 fields could be just fine with int54. It's also true that some fields actually use those bits in practice.
Also, the JSPB format references tag numbers rather than field names. It's not really readable. For TextProto it might be a log output, or a config file, or a test, which are all have ways of catching field name discrepancies (or it doesn't matter). For the primary transport layer to the browser, the field name isn't a forward compatible/safe way to reference the schema.
So oddly the engineers complaining about the multiple text formats are also saved from a fair number of bugs by being forced to use tools more suited to their specific situation.
This looks really nice! I'm excited to see it and am left with questions from perusing the site. Let me know if I missed it.
It's simple and also has an excellent choice of where to invest in powerful features. It looks like an elegant, minimal selection of things existing languages already do well, while cutting out a lot of cruft.
The site also mentions two differentiating and less established features that make it sound like more than yet another fp remix: type-based ownership and algebraic effects.
While ownership stuff is well explored by Rust and a less explicit variation by Mojo, this sounds like a meaningful innovation and deserves a good write-up! Ownership is an execution-centric idea, where fp usually tries to stay evaluation-centric (Turing v Church). It's hard to make these ideas work will together, and real progress is exciting.
I'm less familiar with algebraic effects, but it seems like a somewhat newer (in the broader consciousness) idea with a lot of variation. How does Loon approach it?
These seem like the killer features, and I'd love to see more details.
(The one technical choice I just can't agree with is multi-arity definitions. They make writing code easier and reading it harder, which is rarely or never the better choice. Teams discourage function overloading all the time for this reason.)
Thanks for sharing!
Of course, we've been told to never accept a counter offer at your job.
Do you have a example article? I haven't encountered the advice, but I'm curious if the reasoning matches my guess.
Who reaches for a tool they forgot about?
Few organizations invest in solutions only understood by one or two individuals on their team. This is actually what prevents undergraduate cs knowledge from having an impact. It makes me sad.
Undergraduate CS isn't about the things you do most of the time. It's about enabling the occasions where the alternative is to give up and shrug, or perhaps speculate instead of evaluate.
Undergrads, read this before taking a theory of computation class: https://swtch.com/~rsc/regexp/regexp1.html
I was about to mention this too.
Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework".
I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not?
I guess components are supposed to standardize modularity, so you can easily import some random widget?
The West Wing has such a good clip about this:
It's always a matter of chasing the bottleneck. It's fair to say that network isn't the bottleneck for most applications. Heuristically, if you're willing to take on the performance impacts of a GC'd language you're probably already not the target audience.
Zero copy is the important part for applications that need to saturate the NIC. For example Netflix integrated encryption into the FreeBSD kernel so they could use sendfile for zero-copy transfers from SSD (in the case of very popular titles) to a TLS stream. Otherwise they would have had two extra copies of every block of video just to encrypt it.
Note however that their actual streaming stack is very different from the application stack. The constraint isn't strictly technical: ISP colocation space is expensive, so they need to have the most juiced machines they can possibly fit in the rack to control costs.
There's an obvious appeal to accomplishing zero-copy by pushing network functionality into user space instead of application functionality into kernel space, so the DPDK evolution is natural.