August Lilleaas

> Do you have any info on this? There have been some studies, and while all methodologies have tradeoff's go and clojure sit near the bottom of this list in bugs/committ: https://arxiv.org/pdf/1901.10220.pdf Which is fascinating because they are very different languages whose unifying theme is simplicity. But this actually fits well if you know another important fact: bugs occur along organizational lines. https://augustl.com/blog/2019/best_bug_predictor_is_organizational_com… If you've been around long enough, you realize a lot, if not most bugs, come from not understanding someone else's code. Type systems arn't going to help you, when you don't understand what the code they are "protecting" is doing. > The parent poster wasn't saying no one uses go, but that people use go despite its systematic problems, and tbh your comment mostly doesn't argue against that thesis, just arguing that it's successful But if go has so many problems why do people use it? Javascript, bash, and go have a unifying trait. They are useful, they solve a problem. But unlike javascript and bash, go wasn't and isn't integrated anywhere. No ecosystem forced people into go. They choose it, writ large. Why? Well because languages are more than there type systems.

Congratulations on the funding, I've been following the project for a while (your tech blog is great) and am especially fond of the spin-off project Badger[1]. I'd like to ask a few questions and make a few "content requests" for the tech blog if I may, since I see @campoy is here and @mrjn will probably stop by later =) Some things I'd love to read about on your blog 1 - I'd love to read more on the local information retrieval strategies you use for Badger, especially if you have use cases that are comparable to sequential reads (something that Kafka does, but with a structure optimized for magnetic drives) or ISAM style indexation (traditional SQL databases), and how you leverage the metadata byte to speed things up (this has been touched on only superficially on the blog afaik) along with other specialized features/operations Badger supports; 2 - Some insights on how Dgraph's data model influenced the design of Badger, and what parts you decided to explicitly generalize for other use cases, and what use case constraints have you purposefully decided on (aside from the obvious ones like SSD optimized, etc); 3 - Any progress you might have made regarding why some queries in Badger take longer than in RocksDB. That so far has been the biggest cliffhanger in the tech blog, I've been waiting for the sequel to that one for some time now :) It's difficult to find good resources where people go in depth on these database engineering topics, but your blog is a very good one…

First famo.us employee here, want to give people some food for thought to consider as you gripe about things like zoom and and the scrollbar (rightfully so). Some of the more controversial points, especially those regarding accessibility and progressive enhancement, made below are my own. I think I'm the only person at the company that browses the web with JavaScript disabled, so I know how broken the original world wide web from when I first went online in 1994 is. I also remember using text-only browsers like lynx, and demonstrate it to co-workers on occasion. Lastly, I've been doing the web app development schtick for several years now and seen the good and the bad. With all that in mind, the push towards progressive enhancement starting in 2003 when AJAX was just starting to become popular has proven to be a false prophet. IMHO, no idea has done more to make the web less accessible while also holding it back in terms of interactivity. You simply cannot use the same abstraction for both documents and applications and expect decent results for either. What we should have done instead is allowed the two to diverge long ago and especially after 2007 when mobile computing took off and that change in screen size afforded us the opportunity to return to screens not all that dissimilar from those I remember using in '94. The first iPhone had a effective resolution of 320×480. You can effectively show as much on an iPhone as a 1994 computer monitor and have it be readable on…