Hacker Newsnew | past | comments | ask | show | jobs | submit | kachnuv_ocasek's commentslogin

Do you truly believe most of that goes towards wages?


Well, some will go on corporation tax, some on business rates, some on rent of the land the storage is on (which itself has to pay corporation tax, I suppose).


Yes. Competitive forces would push the cost toward the most expensive input which is likely people. That would be somewhat muted if the supplier was sole source but even then outright purchases would put downward pressure on the rental price.


Given that you’re forced to rent the cap and gown, I think it’s safe to say that competitive forces are entirely absent in this scenario.


What competitive forces? It's not like people have a choice in choosing whether they want a particular cap or gown and the people who contract the rental agreement (i.e. the university admin) are not the ones bearing the cost.


What exactly do you mean by “make state explicit”?


Minimizing side effects (e.g. functional programming) is a good habit in general. But when we're talking at the scale of a company's entire software solution state is the enemy of everything that is good.

You never want to work on a platform with 500k lines of code any of which could mutate variable state at will and the more you can isolate or simplify state usage the better your life will be.


It's also the enemy of evil things your company does.


Depends on the language I'd say, but overall, try to keep state in as few places as possible, and make it more obvious when it's being used. Modern example would be Rust defaulting to immutability for variables, and makes it very clear when you should expect that this variable actually carries state rather than just a value, by prefixing it with `mut `. Other languages might make it the other way around, making constants/read-only variables stick out, and defaulting to "hiding that they have state" basically.


The behavior of every valid state should be defined and obvious to anyone making changes. Invalid states should be impossible to represent.

All software is actually a state machine and almost all complexity comes from unmanaged state transitions. Especially if you have errors, concurrency, async actions, and distributed systems.

The most important task any software architect has is defining how you know what is true about the system.

Consider a few examples:

await sendEmail(); await saveUser();

That's obvious right? Well what happens when saveUser fails and some retry sends a duplicate email?

---

If you're relying on a webhook to let system A know when system B has changed things, what happens when that failed and now the two systems are out of sync? This is why event-driven architectures often work well: they externalize state transitions.

---

A classic React problem, you define state like this:

``` const [loading, setLoading] = ... const [error, setError] = ... const [data, setData] = ... const [isRefreshing, setRefreshing] = ... ```

Now there's all sorts of invalid states you can be in. Like "loading true, data true, error true".

**

You should strongly prefer: state machines, lifecycle enums, event logs, immutable events, append-only histories, strict versioning, idempotency keys, and explicit workflow stages.

You should avoid like the plauge: hidden globals, timing assumptions, inferred behavior, synchronization, side effects, boolean explosion, mulitple sources of truth.

Event sourcing, CQRS, Redux, Kafka, workflow engines, finite state machines, transactional outboxes, CRDTs, database normalization they all do the same thing _control where the state lives_.


What would be the product they're marketing by this campaign?


You don't market products, you market lifestyles/interests. Sell the sizzle, not the steak etc.

For Anthropic it's "we own the big scary models, the AI security space, but it's ok we're responsible"

For the partners it's "we're the Big Boys here and will look after your enterprise needs"

None of it needs any more than anecdata and some nice, pre-approved, quotes.

Every organisation does it.


The product they launched?


This product is explicitly not being released for usage


just because _we_ don't have access does not mean anthropic's not getting paid


The product is being provided to some of the most influential companies. That can definitely serve to Anthropic's advantage. (Regardless, I suspect the hype is real.)


Imagine you were making purchasing decisions about which LLM-based coding tool to use.

If one of the possible vendors convinces you that that they have a next gen model that is so powerful it found 20+ year old bugs in a hardened operating system, that would undoubtedly have an influence on your decision even if you are only buying the current model.


Perfect for hedging the emotional damage on my daily commute in monetary units.


Composition, lighting and creativity are no more than tools either.


This is not in any way specific to the government or public institution. Many (perhaps most) private companies work the same way.


Yeah, anyone who says 'the government should be ran like a company' has likely never worked in a large corporation. It's full of meaningless work, bullshit jobs and red tape.


One could argue share buybacks are more tax-efficient.


How does Spotify defend people who actually make art? There's virtually no difference between pirating and steaming through Spotify for the vast majority of artists.


Personally as an artist I'd rather give it to people directly for free but I'll meet the audience where they are. The "compensation" does not factor into it at all.

Interestingly, I'm seeing more and more small bands stepping off of Spotify, mainly because of AI clones and botted stream scams. Apparently they've decided losing that reach is acceptable. (anecdotal ofc. but even on local scale it's an interesting choice)


Same argument applies. You, as the developer, always know in what context the text appears. Whether it's "dwa zdjęcia przesłane" or "dodano tagi do dwóch zdjęć".


> You, as the developer, always know

Definetely not "always".


Lean has much better UX to be frank. Rocq is fine, but if I were to start formalising today, I'd pick Lean.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: