shafte

> 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.

I'm curious: what's sorts of things were bad about libtorch? What did you see in this release that you thought was an improvment?

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.

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.

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!

[1] https://eternalterminal.dev/

Watch David's talk coming up (https://www.facebook.com/pytorch/), it will contain some answers :)

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.

[0] https://www.sqlite.org/whentouse.html

[1] https://www.sqlite.org/testing.html

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.

Not really related, but a quick plug for the work that Mercurial is doing to port substantial portions of its main binary to Rust: https://www.mercurial-scm.org/wiki/OxidationPlan

My understanding is that they want to get it fully ported before Python 2 EOL.

This is so awesome. Makes me really excited for the future of PyTorch—being able to define symbolic deriviatives in a python subset is super cool

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.

Sometimes you just get unlucky!

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.

Breaking changes are highlighted here: https://github.com/pytorch/pytorch/releases#breaking-changes

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.

[1] https://pytorch.org/docs/master/jit.html?highlight=torchscri...

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.

> Why use the term "kvetching"? I'm curious.

Huh? I guess it's the term my mother would use.

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.

I actually like the new website. I think the primary barrier to Rust adoption now is something along the lines of "my organization doesn't use it"—this website is clearly geared toward persuading CTOs or administrators.

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.

This is cool. I especially appreciate the disclaimer at the end:

>> 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.

A REPL is an incredibly useful tool for all sorts of development, "real" or not. But I share the author's frustration with intros to functional programming that take advantage of a REPL to provide small, context-less examples. It makes it hard to see how I could use the language in for a complex project with significant side effects (e.g. file/network IO).

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.

[1] http://book.realworldhaskell.org/read/

For explaining personal technology to the masses, it has to be Walt Mossberg. The guy basically invented the commentary + review format that most mainstream publications use today.

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.

I think people tend to focus on specific symptoms of bad code (duplication, in this case) without thinking about what makes good code.

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 I said: UTC is a reasonable choice, except for the fact that most of your employees do not live in UTC and doing mental translation is annoying.

To be fair, you are not including more advanced operators, like positive/negative lookahead/behind (which is the specific example the article uses), capturing and non-capturing groups, greedy vs non-greedy kleene stars, etc.

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.

This is fairly common for large tech companies that started in that timezone. The decisionmaking process goes something like this:

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.