Bryan Cantrill

Are you writing code that gets reviewed by other people? Were code reviews hard in the past? Do your coworkers care about "code quality" (I mean this in scare quotes because that means different things to different people).

Are you working more on operational stuff or on "long-running product" stuff?

My personal headcanon: this tooling works well when built on simple patterns, and can handle complex work. This tooling has also been not great at coming up with new patterns, and if left unsupervised will totally make up new patterns that are going to go south very quickly. With that lens, I find myself just rewriting what Claude gives me in a good number of cases.

I sometimes race the robot and beat the robot at doing a change. I am "cheating" I guess cuz I know what I want already in many cases and it has to find things first but... I think the futzing fraction[0] is underestimated for some people.

And like in the "perils of laziness lost"[1] essay... I think that sometimes the machine trying too hard just offends my sensibilities. Why are you doing 3 things instead of just doing the one thing!

One might say "but it fixes it after it's corrected"... but I already go through this annoying "no don't do A,B, C just do A, yes just that it's fine" flow when working with coworkers, and it's annoying there too!

"Claude writes thorough tests" is also its own micro-mess here, because while guided test creation works very well for me, giving it any leeway in creativity leads to…

> The more I hear about how Zig implements it, the more it is exactly like exceptions.

It's exactly like exceptions aside from all the problematic bits of exceptions:

* it is very explicit

* it is much easier to interact with

* it can be abstracted over (since a "result" is a reified value of a known type)

* it supports but is not over-optimised for happy path or split-path scenarios

* it doesn't require separate allocations or RTTI

* it has a much more uniform cost model

That doesn't necessarily mean it's the right system for what you usually work with, but it's a really nice way to do error handling.

For an expansion of this, Brian Cantrill has a paean to this error handling style in his "falling in love with rust"[0], I can't direct-link the section but it's "1. Rust’s error handling is beautiful".

[0] http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/

It seems to me that the workloads on Digital Ocean are not fully utilizing the block device. FIO shows about 50% util for DO, and 81% for Linode on the queue depth=1 test, and 70%/82%, respectively, on the queue depth=8 test. Which seems to indicate a bottle neck somewhere else (at least on DO), and that seems to align with OP's statement at the end, where it seems DO is being capped. Also as it was pointed out, the sizes of these VPS are not even mentioned, and most likely the working set size of 128MB, might be either too small or too big for any of these VPS, making even harder to see the value of these results.

Brendan Gregg has excellent info on these topics,

http://www.joyent.com/blog/benchmarking-the-cloud
http://dtrace.org/blogs/brendan/2011/05/11/file-system-latency-part-1/
http://dtrace.org/blogs/brendan/2012/10/23/active-benchmarking/

Not to mention the numerous times where TM casually asks to wipe your backup history because the integrity test didn't pass without errors. Usually this can be fixed with a few commands copied off a blogpost that must be getting thousands of hits every day.

It seems obvious to me that TM was intended to run on a snapshotting filesystem such as ZFS* and when this didn't materialize the engineers tried their best to make it work using the tools available to them. Unfortunately thsoe were sparsebundles and hardlinks.
I would hope that TM will get updated to use APFS snapshots sooner rather than later, assuming the feature is proven and stable. iOS makes use of APFS snapshots for rolling back failed updates, so one would assume it is.

* http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/ and https://arstechnica.com/staff/2006/08/4995/

Thanks for the praise!

As far as pricing goes, you're charged for the wall clock time spent running inside the zone, so if your task queues up because the system is jammed, you're not paying for that. Task runtime can be affected on busy systems, but this has been in the noise for the jobs we've looked at. We're also looking to see how the system gets used in order to understand whether it would be useful to have other pricing options (e.g., tiers of service with guaranteed resources).

As for performance: we're using the system internally every day, and we've found the performance very good. Of course, the best way to find out is to evaluate it on your own workload. :)

Finally, you'll probably be interested to read Keith's summary of our hardware choices here:
http://dtrace.org/blogs/wesolows/2013/06/25/manta-what-lies-beneath/

Bryan Cantrill:

http://dtrace.org/blogs/bmc/2004/08/28/the-economics-of-software/#comment-746

>> software does not wear out. That isn’t to say that software never breaks (or isn’t broken to begin with), but software that works can work in perpetuity. A favorite example of mine is troff. The source for troff is some of the nastiest stuff ever written — but it works. It hasn’t been touched in years, and probably will never be: it’s written in a portable language (C) and relies only on the most basic OS facilities. troff will work indefinitely — it will never wear out.

>> (The tragic footnote to troff is that its author, Joseph Ossanna, died tragically in 1977; the very fact that his software is humming along perfectly more than a quarter of a [century] after his death is a testament to software’s unique imperviousness to wear.)