387 karma · joined March 1, 2017
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 said, the code is also reasonably well commented as well, for example: https://github.com/facebook/folly/blob/master/folly/Singleto.... So "read the code" is not terrible advice in this case either.
>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.
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.
My understanding is that they want to get it fully ported before Python 2 EOL.
Sometimes you just get unlucky!
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.
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.
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.
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.
[1] https://pytorch.org/docs/master/jit.html?highlight=torchscri...
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.
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.
> Why use the term "kvetching"? I'm curious.
Huh? I guess it's the term my mother would use.
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.
It's a sign of the strength of the Rust community that they feel they no longer need to persuade developers. It implies that many developers have already heard about and are interested in Rust, but need higher-ups to approve using it.
>> We can’t stress enough how important it is to measure your applications and the tools used to measure those applications.
In general, hardware-oriented data-structure design is really appropriate for organizations with:
1. Large server workloads that exercise the data structure frequently.
2. Fine-grained control of what hardware they're using.
3. Very very good continuous profiling and monitoring of the production workload.
I often see #3 missing when people propose writing their own hash table or whatever, but it's an essential prerequisite. These days, serious wins tend to come from making large assumptions (X instructions will get vectorized, Y access pattern dominates) and specializing your implementation to them.
Real World Haskell[1] is a great example of an introduction that provides small examples AND situates them in the context of programs that I could see myself actually using.
For how much people in the industry wince when they heard she was rooting around, probably Kara Swisher. I can’t think of any reporters who struck as much a gut-level fear in the investors and executives I know.
Jessica Lessin has been doing interesting things lately with The Information’s business model, and has broken a lot of news lately.
Ideally, we'd like our code to be:
- Mutable (i.e. easy to modify
- Understandable
- Good at doing what it's supposed to do.
- Other stuff that I'm forgetting.
The general recommendation against duplicate code is intended to promote mutability (by avoiding multiple implementations that need to be changed). If you apply it blindly without keeping mutability in mind, you can get situations like the one the authors describes.
I see some of the same myopia when people talk about testing. Testing is there to ensure that your code is correct, and that it's easy to make changes without affecting correctness. As soon as you find yourself writing tests that aren't for those two reasons, consider whether it's worth the effort.
As you say, they are implementation specific, but that's part of the problem: the basic regular expression syntax is insufficient for many tasks, so people take to extending it in complicated and syntactically opaque ways. That's the sign of a bad DSL, not a good one.
1. You MUST use a single, consistent timezone. Using the local timezone is a mess: is it the user's local? The host's local? What about server logs, which are typically text files where the timezone can't be displayed dynamically? What if you aggregate server logs across timezones? What if you ssh into a machine in a different timezone?
2. The logical timezone to use is the one in which the vast majority of your employees work, since having people subtracting 7/8 all the time is annoying.
You could argue that for customer-facing status updates like this, Google should use a dynamic timezone. That's fair, but I'm sure Google internally uses that status dashboard, so it could be very confusing and complicate coordination to mitigate the problem. I'd argue that customers would prefer that the problem get fixed slightly sooner over having to do a once-a-year-ish timezone conversion.
Having worked at some of the FANGs, I can say that this effect of these perks on work/life decisions is very very small. Most people enjoy the perks and do what they were going to do anyway. Most of my teammates won't stay for free dinner because they'd rather spend time with their friends and families. Most people work from home all the ~once/week.
When work/life balance is bad, it's because of a desire to perform or managerial pressure; not because you get free food and an on-site dentist. Generally the perks are conveniences and genuinely nice to have, and if they are part of a sinister plot to exploit workers, they are pretty bad at it.
I'm applying the following standard: if someone told me that their friend had 3 kids, would I infer something about their social status? At least for me, not really? Like you said, the poor and rich both have >3 children. ymmv of course