somekyle

I feel similarly. I've been pure remote since COVID. I used to complain about having to come into the office just to stare at a screen quietly next to people. Being remote has been great in some ways, but I've really noticed the reduction in connection to coworkers and the major decline in informal collaboration. I've also had to dedicate a room of my house as an office (have kids, so working from any common space is fully impossible). My life just feels smaller now, when most days instead of traveling through the city on a busy train to meet up with dozens of collaborators, discuss, eat together, I start my day by sitting down in a small room by myself in front of a screen.

Work is what I do with most of my days. I'd like it to be as engaging and as socially connective as possible. I don't like commuting, but I'm planning for my next job to be in person.

This is why I like more bottom-up approaches to coding. Code broken up sorta arbitrarily, that's compressed moreso than abstracted, is hard to follow. But, when there's a reasonably small set of solid domain abstractions (even extremely complex ones in implementation), that's totally fine. This is where preferences vary; some folks have committed nuances of various helper libraries to memory, and find it easier to process a `fuse_zip` combinator or whatever than a loop, but for the readers who'd need to look that up, it's an attention land-mine.

API design, abstraction design, is a type of UX design, and like other forms of design, accessibility is a concern. Keeping the vocabulary fairly small and the abstractions well-behaved and consistent help nearly everyone, but particular ADHD folk.

Hah! I was just remembering the exact same thing. His fingerprints are all over my development as a professional Java programmer.

This seems.. expected. Anything that makes something easier is gonna annoy some people for whom the difficulty was part of the point.

An underrated factor in this conversation is implementation effort. Javascript is arguably the most widely run interpreted language in the world. Pre-Chrome, JS was uniformly rather slow, but Google was betting on webapps being good and usable, so they brought on some top-tier compilation/VM talent to build V8. As fast Javascript existed, it made it possible to do more natively in the browser, and other browser vendors joined in an arms race there. Tons of effort overall, tons of money and time from top-tier experts.

There was no equivalent competition between major organizations to make Python fast. Folks have tried, but not on the same scale. Yes, factors like language design and existing ecosystems entanglements played a role here, but if Python had the investment in performance Javascript had (financial and expert attention), it'd be dramatically faster today (though it may have required a fork or similar, depending on how tied to simplicity Guido was feeling).

To be clear, I'm not saying nobody tried to make Python faster, or that Python devs don't know what they're doing. I know very well both of those things aren't true. But, the kind of sophistication required to make Python fast in absolute terms is very hard to build and maintain, and for various reasons nobody who has found Python to be too slow has found "invest in a bunch of person-years of VM engineer attention dedicated to performance work" to be their best path.

I imagine it varies, but from most people I know, it's the very definition of "labor of love". It's certainly a big time and effort commitment and sometimes you'd rather not, but there's basically nothing in life I care about more than my kids. And they can, in a moment, give me more joy or fulfillment than I'd find in a week in my pre-kids life.

I'm someone who needs alone time, and it's really hard for me at times, but their wellbeing impacts my wellbeing more than my wellbeing does, they sorta naturally became my #1 priority in life, so anything but taking care of them to the best of my ability simply doesn't make sense to me.

I have kids, and if I count their bedtime process as chores an hour or two isn't a particularly heavy evening.

it's funny, because I believe the author has contributed to at least 4 of these directly in his day job, and has published code for a few more. But I guess you can't buy bread with substantial contributions, if ability to buy bread is our metric. But it's not a good metric.

Is the point of this that you can do large-scale data processing without the overhead of distribution if you're willing to pay for the kind of hardware that can give you fast random access to all of it?

We've found this to be basically true. Git operations that stat() a lot are dramatically, catastrophically slower on OS X, and that's part of why my employer started doing fs watching there and mostly left Linux as is. More than once I've had to update a cross-platform tool to avoid stat()ing because though cheap on Linux, it took 10s of seconds on OS X.

Oh, I'm sure it's a problem; the reason I haven't been subjected to these problems is because I mostly deploy tools to an environment that has pre-existing build system and deployment solutions for this that I don't have to maintain.

I_like_ writing CLI apps in Python, and for various reasons haven't been subjected to the packaging woes, but I think execution latency is an important thing for CLI tools, and I've had enough Python CLI tools spend most of their time (a user-perceptible amount) loading modules that I prefer less dynamic languages for tools that aren't completely trivial.

Yes, overapplying directional advice is a problem, and channels aren't always the right choice, but mutexes/cond vars/atomics have always been part of Go and they've always been listed as viable options, just not usually the best choice for high level coordination. To quote the go1 Effective Go on channel-based interaction:

  This approach can be taken too far.  Reference counts may be best done
  by putting a mutex around an integer variable, for instance.  
  But as a high-level approach, using channels to control access makes it easier
  to write clear, correct programs.

I'm sure somebody has been banging a "Go programs should never use mutexes" drum, but it hasn't ever been the position of the Go team that channels are a panacea or that mutexes _shouldn't_ be used, as far as I've ever seen.

I think an interesting question is: can you support people and wish the best for them even if they've done a bad thing?

With the exception of some particularly abhorrent things, I'm not sure I'd consider myself a friend to someone if I'm not willing to support them even if they're in the wrong. That doesn't mean lying for them or trying to pretend it wasn't bad, but I would expect myself to push back on mischaracterizations of them (positive or negative!) and help them navigate the consequences.

It's a harder problem to solve when you've moved across the country (or world) to work for years at companies that actively cultivated a world of "work and play at work"/"hang out after hours" with legitimate professional incentive to participate. There's a real sense in which Bay area tech companies invested in social infrastructure to make living in a place where you have no real personal connections sustainable, so if they stop providing that benefit, it can be a real problem to those with less social resources.