He lost me at "our particular moment of dystopian late capitalism."
4,462 karma · joined February 20, 2007
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)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.
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...
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.
The board has not been consistently candid in its communications with... anyone.
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.
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.
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.
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.
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.