cwp

He lost me at "our particular moment of dystopian late capitalism."

This article is drivel. If a supplier writes down the value of a contract with Tesla, they're saying Tesla is buying fewer batteries, or will in the near future. That is, there is a lack of demand for the batteries. If you're determined to take this as bad news for Tesla, rather than bad news for L&F, you could maybe speculate about lack of demand for Cybertrucks, but spinning it as "supply chain collapse" is just silly.

The code example is very similar to Ray.

Monarch:

  class Example(Actor):
     @endpoint
     def say_hello(self, txt):
         return f"hello {txt}"

  procs = this_host().spawn_procs({"gpus": 8})
  actors = procs.spawn("actors", Example)
  hello_future = actors.say_hello.call("world")
  hello_future.get()

  @ray.remote(num_gpus=1)
  class Example:
      def say_hello(self, txt):
          return f"hello {txt}"

  actors = [Example.remote() for _ in range(8)]
  hello_object_refs = [a.say_hello.remote("world") for a in actors]
  ray.get(hello_object_refs)

Nice. Another aspect of the ternary operator is conditional evaluation. Beyond parenthesis, in a?b:c, only one of b and c get evaluated.

Agreed. I was skeptical at first, but I've worked at several companies with unlimited PTO and they all specifically encouraged people to take time off. One place was explicit that the reason they switched to unlimited was to get people to take vacations: "PTO is not meant to be a bonus when you leave the company. We want you to rest and recharge."

My current company recently made a rule that you have to apply for time off through the HR software. Not make it harder to take PTO—all requests are auto-approved-just so HR can track it. At the next all-hands the CEO said something like "You guys work really hard... we're, uh, worried." My manager has been bugging me to take a proper vacation instead of my usual day off here and there.

There are certainly awful, exploitative workplaces out there. But there are also great companies run by good people.

Sure. Everyone, including government employees, should be allowed to discuss anything with AI. The problem is actually doing illegal things, which is... already illegal.

Reading a comment is exactly the same thing as scraping the internet, you just stop sooner.

If I read your comment, then write a reply, is it a derivative work?

I got a ZSA Voyager split keyboard and then spent weeks exploring custom layouts. The first question was QWERTY vs something better. Then there was layers and layer navigation. And should I swap out the key switches? And Keyboard Maestro.

Now I'm trying to abandon 30 years of muscle memory and typing at 4 wpm while I learn Colemak-DH. Maybe what I should really do is build a custom 34-key board...

Sure. There are undoubtedly a lot of config formats that are overly complex.

But sometimes the complexity is irreducible. Kubernetes is one such case. The model is very well thought out, and just about as simple as it could get without removing functionality. It has sensible defaults, built-in versioning, well-defined schema etc. But if you want to describe a complete installation of a distributed system with many heterogenous processes, spread across many hosts, communicating in specific ways, with specific permissions, persistence, isolation, automatic scaling, resilience, etc, there are a lot of details. I've worked with systems that have thousands of lines of configuration, and honestly that's not extraordinary. Many people on this site will rightly scoff and say, "psshh, that's nothing."

Configuration languages are a really important area of research in the tech industry right now, and every time someone posts one on here, there are a huge number of dismissive comments. Fine. Not everyone has this problem, but it's a real problem, and solving it represents a real advance in the state of the art.

/me sighs

The board has not been consistently candid in its communications with... anyone.

Yeah. This is how Squeak changed the license from SqueakL to Apache and MIT. That code has a lot of history, so it was a pretty big effort, but worth it in the end.

The FSF disagrees with you on that.

Also, potentially bad outcomes if a nuclear aircraft is shot down.

Not the GP, but:

Imagine you're sampling successful traces at, say, 1%, but sending all error traces. If your error rate is low, maybe also 1%, your trace volume will be about 2% of your overall request volume.

Then you push an update that introduces a bug and now all requests fail with an error, and all those traces get sampled. Your trace volume just increased 50x, and your infrastructure may not be prepared for that.

It's subtle and so difficult to see the differences at smaller scales. If you're going to provision a handful of EC2 instances, all the tools work fine.

I think HCL is an under appreciated aspect of Terraform. It was kinda awful for a while, but it's gotten a lot better and much easier to work with. It hits a sweet spot between data languages like JSON and YAML and fully-general programming languages like Python.

Take CloudFormation. The "native" language is JSON, and they've added YAML support for better ergonomics. But JSON is just not expressive enough. You end up with "pseudoparameters" and "function calls" layered on top. Attribute names doubling as type declarations, deeply nested layers of structure and incredible amounts of repetitious complexity just to be able to express all the details need to handle even moderate amounts of infrastructure.

So, ok, AWS recognizes this and they provide CDK so you can wring out all the repetion using a real programming language - pick your favourite one, a bunch are supported. That helps some, but now you've got the worst of both worlds. It's not "just JSON" anymore. You need a full programming environment. The CDK, let's say the Python version, has to run on the right interpreter. It has a lot of package dependencies, and you'll probably want to run it in a virtualenv, or maybe a container. And it's got the full power of Python, so you might have sources of non-determinism that give you subtle errors and bugs. Maybe it's daylight saving gotchas or hidden dependencies on data that it pulls in from the net. This can sound paranoid, but these things do start to bite if you have enough scale and enough time.

And then, all that Python code is just a front end to the JSON, so you get some insulation from it, but sometimes you're going to have to reason about the JSON it's producing.

HCL, despite its warts, avoids the problems with these extremes. It's enough of a programming language that you can just use named, typed variables to deal with configuration, instead of all the { "Fn::GetAtt" : ["ObjectName", "AttName"] } nonsense that CloudFormation will put you through. And the ability to create modules that can call each other is sooo important for wringing out all the repetition that these configurations seem to generate.

On the other hand, it's not fully general, so you don't have to deal with things like loops, recursion, and so on. This lack of power in the language enables more power in the tools. Things like the plan/apply distinction, automatically tracking dependencies between resources, targeting specific resources, move blocks etc. would be difficult or impossible with a language as powerful as Python.

HCL isn't the only language in this space - see CUE and Dhall, for example - but it's undoubtedly the most widely used. And it makes a real difference in practice.

Right. Maybe buy a stake in ESPN and get them to run 3D livestreams of games, but even that probably doesn't go forward until the MLS deal is a success.

San Francisco won't be satisfied until they've completely driven out all the tech companies and their employees.

Eh, I'm not sure about that.

Tesla started from scratch and developed large-scale manufacturing and logistics from first principles. It was hard, but it's put them in a hugely advantageous position today. It turns out old-school manufacturing for ICE vehicles doesn't translate directly to EVs. Yes, Ford (for example) can build EVs, but they're not cost competitive with Tesla, because they're optimized for something else. Tesla produces 100x as many EVs as anybody else.

Now, was Tesla surprised by the difficulty of manufacturing, because they didn't know what they didn't know? Maybe, I have no idea. But in retrospect, it wasn't a mistake to ignore the accumulated wisdom of the car industry. It turns out the old-school companies don't know what they don't know either.

No, because M&A isn't banned. I don't know how many car companies we have, but I do notice that there are a bunch of new ones recently. Just off the top of my head: Tesla, Lucid, Rivian, Cruise.

It doesn't come at the expense of the employees of the acquired business. They often get rich, or at least land a well-paying and career-enhancing gig at the acquiring company.

This is important, because it means that new companies that compete with the monopolies have many paths to success. If the only possible outcomes are "beat Amazon" and "fail hard", you won't get many attempts; it's better to get an entry-level job at Amazon and climb the ladder.

So yeah, monopolies are bad, but banning M&A only helps them.

I dig this too. It's what I loved about Quicksilver - it had simple grammar that went direct object, verb, (optionally) indirect object. That tied nicely into the plugin system, which gave it tremendous flexibility. Successors like Alfred, Google Bar and Raycast are trying to recreate the unix command line and it doesn't work nearly as well.

Yeah. Something like the federal highway system, or dams.

California has an unlimited supply of water along its western border. We ought to tap that rather than the Colorado river.

I don't know if scientists are studying this - given recent trends they ought to be. But if experience counts, then yeah, there is. I've done a lot of work remotely, in person and on teams where some people were remote and others colocated.

If you have a hard problem and you need to apply several brains to it, then you can't beat working together in person. Two or three people in a room with their laptops, a table, a whiteboard, a couch and a door that closes. It's miraculous.

In person meetings are really good for getting everybody on the same page. You develop a shared vision, build relationships, and create group cohesion that can really improve everybody's productivity. It's very good for kicking off a new company, project, cultural shift or what have you.

Once you've established that group identity, you don't need to be in-person all the time. Remote work is fine for day-to-day product development and operations. It usually allows people to concentrate better than open-plan offices. But that's not improved collaboration, it's improved individual productivity. And note that I didn't say in-person meetings are better than remote meetings in general. Typically that's not collaboration either, it's coordination.

All of which is to say that if you're precise and narrow in your definitions, yeah, there's pretty hard evidence that in-person collaboration is better. But remote is fine for most tech work, and probably an even higher portion of general white-collar work. I'm glad that people are refusing to move, because that will help us develop a better model for remote work - a true distributed organization rather than "just like the office, but on zoom". At a societal level, we really really need this to work, and I think we should be willing to accept a small, medium-term hit to productivity while we figure it out.

Actually, Apple delayed stabilizing the ABI (which would be required for rewriting low-level libraries) in order to work on other features that the community (ie, non-Apple users of Swift) needed more. If Apple had prioritized the needs of their own developers, this would have been done years ago. So kudos to Apple.

Good. We really need to find a better model than "Ok, everybody move to NY/SF/LA". Yes, getting everybody in a room together is the best way to collaborate, but the cost of it is too high in just about every other dimension.

I guess what I'm saying is that I don't think American compensation will go down much, and the to extent that it does, it's because more people can work good jobs that were only available in the top-tier cities before. That is, most people in Michigan won't get SF salaries, but they won't have SF expenses either, and overall they'll be fine. They'll pull the average down, but it won't be horrible for anyone.

Yes and no. They tried that in the 90s and it didn't work out. It turns out timezones, language and culture matter. So yes, remote work will mean that US white collar workers will have to compete with workers in other countries, but that's not impossible. We may find that yes, that drags down compensation in the US, but it also pulls up compensation in the rest of the world, and there's just a wider range, more developers available in general and more coding happens as software continues to eat the world. How AI figure into this is anybody's guess - don't believe anyone who claims to know.

Yeah, definitely early days. But they're saying all the right things: fast code off the bat, easy to vectorize and parallelize, efficient use of memory, easy to create abstractions that execute efficiently on various architectures. The demos are impressive and they have the track record to be credible. I've played with it and the stuff that's been implemented so far works well.