Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
IMO most of the practical "research" I've seen comes in the form of best practices from Big Co. who a) hire very intelligent people and b) have extreme financial incentives to write the best code & have the best processes possible.
In a world where the dependent variable isn't something that can easily be measured in a lab, the next best we can do is either 1\ Ask experts or 2\ experiment in an environment where it's financially advisable to experiment & measure (AKA an environment where running an experiment with 100 engineers is <1% of your engineering headcount).
I.e. I don't work for Google, but I do share things like [0, 1] with new engineers who join my team.
[0] https://google.github.io/eng-practices/
There are some points in the middle, but it's rare. I worked on one of these [1]. We've been building the system for just over ten years, and are starting to see some truly killer apps being built on top of it [2, 3].
While it has some great benefits once you arrive, the upfront costs are enormous. You basically need to find a funding source (or sources) that will pay for this product while you're building it. Also, in order for the research payoff to be worth it, you need both the product itself, and subsequent innovations it enables, to be research-worthy. Not all areas of research can support this. On top of it all, even when you do this, you'll still spend years of effort in activities that are essentially not research. You're basically responsible for all of your own customer support, sales, marketing, etc.---like a startup, but without the financial upside if you succeed. Yes there is recognition and so on, but the payoffs aren't as dramatic. Most people aren't ready to commit to this path.
Keep in mind that you can't build this in 5 years either. So a single generation of PhD students can't get it done. The only reason we were successful is because the key staff on the project stuck around for 5+ years after their PhDs because we all believed in doing the work.
Given all that, I don't hold it against people at all who just want to build prototypes and then move on to the next thing. It's way less risky and higher reward relative to the costs.
[1]: https://legion.stanford.edu/
[2]: https://flexflow.ai/
[3]: https://developer.nvidia.com/cunumeric
> Despite all the research into garbage collectors nearly every new programming language I've seen uses either BoehmGC (from 1994) or simply gives up on the idea and uses reference counting.
Have you ever seen a garbage collector that uses the NSA instruction? https://github.com/jart/cosmopolitan/tree/master/tool/plinko
Good news for you: I'm well on the way to solving the problem of better code merging. Specifically, the algorithms I am developing appear to be able to do a correct merge on both [1] and [2]. They also appear capable of merging binary data.
The tradeoff is that people need to write some code to tell the VCS about the format of each binary file type or semantics of each programming language.
The biggest problem is that, like Rust, a new VCS has to be well-executed to make its innovation stick. We'll see if I succeed.
[1]: https://tahoe-lafs.org/~zooko/badmerge/simple.html
[2]: https://tahoe-lafs.org/~zooko/badmerge/concrete-bad-semantic...