eximius

Private channels in public servers exist. I'm almost entirely on private servers.

This probably needs a bigger callout. A user who isn't familiar with ATProto doesn't even know to ask this question and the design space from its contemporaries (e.g., discord, slack, etc) suggests that chats are nominally private if folks aren't a member of the channel.

It's a very cool product but you have to let people know their messages aren't private.

If open models on local hardware were more cost effective and competitive, it would be obvious that this is such a superficial approach. (I mean, it still is obvious but what are ya gunna do?)

We would be doing the same general loop, but fine tuning the model overnight.

I still think the current LLM architecture(s) is a very useful local maximum, but ultimately a dead end for AI.

To be more clear, I want sum types with exhaustive matching - which Go does not support.

I get by without it Go enums are an inferior representation of the same logical concepts. Sure, I can have (kind, value) and cast things for a hacky sum type for some kind enum. But Go lacks closed enums/exhaustive matching.

You can at least validate the match arms with things like type switches and marker interfaces, but they're still not exhaustive and they're terribly verbose.

And, again, I can get by without them! But I miss them because Rust-style enum representation comes up _so often_, even if you don't like the rest of Rust.

Lack of enums are the main point for me.

The error story is not ideal but less bad than that most of the time, as you can downcast to access extra error data. Still, harder than it needs to be.

Overall, I've grown to like using the language even despite its warts.

Detecting an effect is present is separate from effect power and mechanism. Showing an effect is present is usually the first step before the other two.

These strategies only really work for stream processing. You also want idempotent APIs which won't really work with these. You'd probably go for the strategy they pass over which is having it be an arbitrary string key and just writing it down with some TTL.

More of a data structure than an algorithm, if we're being pedantic.

How many trillions of dollars have we spent on these things?

Would we not expect similar levels of progress in other industries given such massive investment?

> Rather than defining a single interface and mock on the producer side that can be reused by all these packages

This is the answer. The domain that exports the API should also provide a high fidelity test double that is a fake/in memory implementation (not a mock!) that all internal downstream consumers can use.

New method on the interface (or behavioral change to existing methods)? Update the fake in the same change (you have to, otherwise the fake won't meet the interface and uses won't compile!), and your build system can run all tests that use it.

I was not thinking of the agent case specifically. But yes, you have to make the APIs idempotent, either with these step checkpoints or by wrapping the underlying API. It's not hard to make a postgres-transaction-based idempotency layer wrapper, then you can have a much longer idempotency TTL.

> so for long running workflows you need to capture the state output anyways.

That would be a _very_ long running workflow. Probably worth breaking up into different subtasks or, I guess as Absurd does it, step checkpoints.

This is pretty great! The main thing you need for durable execution is 1) retries (absurd does this) 2) idempotency (absurd does this via steps - but would be better handled with the APIs themselves being idempotent, then not using steps. Though absurd would certainly _help_ mitigate some APIs not being idempotent, but not completely).

Por que no los dos? They are not mutually exclusive, really. Perhaps the first skews the initial population and the second exacerbates it.

It's mostly happy for people who don't have to deal with it.

If you are an "end user" who just wants to run your damn code without caring about your dev environment, then `bazel run|build|test //thing/to/run:target` is about as good as you can get! _If bazel is already set up_, I don't have to worry about my environment! It just works.

If your environment has a lot of churn and there isn't a team who makes sure bazel is actually configured correctly, then, yea, it is massive overkill for a lot of things and if you try to do things how you normally would and not the bazel way, you'll have a bad time.

There are other benefits - sometimes you want public APIs so it _can_ be used, but you want visibility rules to limit _who_ can use it. It is great for it's cacheability and dependency tracking - if you need advanced build tooling, it has what you need!

But there is a very real chance you don't need any of these things and so the cost is not worth it.

(I, personally, hate dev environment churn, so just having the CLI tooling uniformity is enough for me.)

Why does this 1 hour old post have comments from 29 days ago?

But they do reflect ones ability to learn to get to the heights of education where you can be trusted to wield the new tools wisely.

There is (some) truth to this but it fundamentally _does not_ replace foundational learning.

Visibility systems are great!

> If a change module A has a problem, you must roll back the entire monolith, preventing a good change in module B from reaching users.

eh. In these setups you really want to be fixing forward for the reason you describe - so you revert the commit for feature A or turn off the feature flag for it or something. You don't really want to be reverting deployments. If you have to, well, then it's probably worth the small cost of feature B being delayed. But there are good solutions to shipping multiple features at the same time without conflicting.

I mean, yes, but it's so far down the list of bad things for society we're facing right now.

I'd rather we tackle the root problems leading to these. Increase education rather than reduce liberties.

I'm not, like, strongly opposed to reducing this particular liberty, but man it's not my first priority.

Staff Software IC / Senior EM

Currently at Opendoor which is executing an RTO strategy I am not interested in. I can operate in whatever mode is needed (scrappy, builder, "mature-er", leader, etc) and I'm interested in a variety of fields.

Location: USA

Remote: primarily

Willing to relocate: no

Technologies: Data Engineering (spark, python, SQL, etc), Backend applications (Modular Monoliths, Go/Java/Python/etc, gRPC/REST/etc, API design), Databases (primarily postgres, redis, spanner), Event/notification based systems/workflows, Frontends (React, Svelte, etc) - not comprehensive - if I haven't used it, it's because I haven't needed to not because I can't learn it

Resume: https://github.com/logannc/resume/blob/main/logan_collins_re...

Email: logan.neal.collins@gmail.com

This doesn't sound right. If A depends on B and C - B and C can each bring their own versions of D, I thought?

_Your_ transaction wasn't about regulation.

What is the breakdown of transaction volumes?

Bluesky is not decentralized. The AT protocol is - albeit with few large integrators besides Bluesky, but it isn't susceptible to like 51% attacks or anything so that's mostly okay.

Oh I don't need this, I'm well aware of how stressed I am.

AI is just a one more tool that increasing wealth inequality and over monetization/unregulated capitalism are exploiting that makes everything it touches worse. It's not the first tool, it won't be the last.

Zero sodium also kills you because you need electrolytes to live. Like almost literally every complex system, there is a zone of moderation/goodness/health.

`case Circle(r) => 3 * (r * r)`

I, uh, think your math might need some checking :)

And better yet, follow the tangential advice and use high fidelity fakes (I usually don't quite go all the way to verified fakes/contract tests, but they're a good idea if you have the time).

Real object where practical, fakes otherwise, mocks only as required for exceptional circumstances.

Works great in interconnected monorepos where you can provide high fidelity fakes of your services for other integrating teams to use in their tests. Often our service fakes are literally just the real service wrapped with an injected fake DB/store.

And what do you do when your opponent is engaging in bad faith or lacks a coherent position for them to agree with any characterization?

I don't believe you're engaging in good faith either.

And they were also dumb. What's your point?