> Those people/use-cases don't care about the GIL.
This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.
That doesn't seem very fair. They link a docs folder and an overview document, neither of which require that the user read code to get a good idea of the library's contents.
Perhaps you missed the "What's in it" section while skimming the readme? :)
>Because of folly's fairly flat structure, the best way to see what's in it is to look at the headers in top level folly/ directory. You can also check the docs folder for documentation, starting with the overview.
EternalTerminal[1] was mentioned in a comment below. It supports port forwarding, and other goodies like native scrollback, at the cost of latency on laggy connections (because it doesn't do full terminal emulation). If that tradeoff sounds good to you, try it!
Aside from its merits as a database, SQLite is also a great example of good documentation[0], thorough testing[1], and focused development. It's something that all library maintainers should study and try to learn from.
I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit.
For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.
The best explanation is coincidence, I think. I have direct knowledge of two of the incidents in the past few weeks, and they have completely unrelated causes.
I think it's cool to see projects like this! It's sort of like an "alternate history" for a C++ programming model. I agree that it doesn't seem immediately useful for most projects, but that's okay :)
I hope the author publishes more explaining some of the architecture and design choices and how they diverge from what the rest of the community has come up with. At the very least it will be an interesting comparison.
Glad to see the team really embrace the nitty-gritty of keeping the open-source community healthy. React Native is a project with a lot of potential that's taken a few high-profile lumps this past year. Being an OSS maintainer can be difficult and thankless sometimes, but it's good to see teams that recommit to open source instead of withdrawing and focusing solely on internal needs.
I'm not second-guessing the technical that the Times made here (I'm sure it made sense given their constraints), but I do wonder if these kinds of in-house general-purpose languages will die out eventually. Some of the comments indicating that this sort of project is a "red flag" seem to miss that 20 years ago the language landscape was a lot more proprietary/closed.
But these days, a big open source/community ecosystem is a really really strong reasons to invest in an existing language (or at least open-source your in-house language, a la Hack or Go). It's hard for in-house general-purpose languages to compete.
This is a great piece of software development history! Very interesting to see what things the industry seems to have improved on (somewhat) and what things we still struggle with.
Things we have improved:
- Developers are generally expected to be responsible for testing (and now operating) code.
- Code reviews and ownership are common practice.
- Distinctions between prototype/development/bugfixing stages are no longer strictly enforced.
Things that we still struggle with:
- Overspecialization/knowledge "siloing", and low bus factors generally.
- Navigating the tradeoffs between re-using existing solutions vs. building your own.
I'd be interested in a direct comparison with similar efforts undertaken by existing frameworks; for example Torch Script[1], which aims to produce a language which shares a syntactic frontend with Python while getting all the goodies that ahead-of-time compilation gives you (symbolic diff, operator fusion, etc).
Seems to me that the primary challenge for any "next-generation" framework or language is getting people to actually use the thing. Sharing a front-end with Python and a backend with PyTorch seems like a good way to bootstrap that.
I'm so glad this this article (unlike so many other representations of Jeff and Sanjay's work) does not overlook Sanjay's contributions.
I don't know what it is; maybe Sanjay is a weird (read: non-English) name, maybe it's that computing culture's obsession with lone hackers leaves no room for a partnership like Jeff and Sanjay's. Anyway, kudos to the New Yorker for not falling into that trap.
> What model of human cognition are you claiming is "incorrect"? And is it the one presented by Marcus, or are you strawmanning?
The model of human cognition I'm referring to is the hybrid connectionist-symbolic one that Marcus is well known for advocating (are YOU strawmanning? lol). I'm criticizing it for being more a theoretical model than one grounded in the physical realities of the brain, which of course no one really understands. Proposing a research program on that basis requires a high burden of proof.
> Are you claiming Marcus has produced no interesting research results?
Yes I am claiming that, if the benchmark for "interesting" is deep learning.
There are indeed areas where deep learning is limited, and hybrid approaches could be superior. I would argue that there is not even close to enough evidence that a hybrid approach has improved generalizable power.
I seem to have missed the Twitter spat that precipitated this essay, but I don't quite buy the larger argument he's making. We should judge approaches to AI based on their results, not on their conformance to a (vague, incorrect, untested) model of human cognition.
Symbolic AI fell out of favor primarily because it was not delivering results in impactful problem areas. Deep learning is currently popular because we are nowhere near the limit of what results it can produce.
Can this change? Of course! The history of deep learning itself proves as much. But if you want to genuinely influence the direction of the field, you have to lead by example and produce novel/interesting research results, not by kvetching in The New Yorker that your favorite approach is not getting enough attention.
This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.