mpartel

Huge spikes over a short period of time are hard to deal with for anyone, and payment processors have their own infra whose scalability Steam can't necessarily control.

Some LLM APIs let you give a schema or regex for the answer. I think it works because LLMs give a probability for every possible next token, and you can filter that list by what the schema/regex allows next.

The design of generics in this one seems rather well balanced in simplicity vs power.

The part about interface-typed values [1] is interesting. They do dynamic dispatch as a fallback when the function is too polymorphic to be be specialized.

In Rust terms it's as if it picks between `dyn` and `impl` automatically. It looks convenient, but also a bit of a non-obvious performance pitfall.

[1] https://shader-slang.com/slang/user-guide/interfaces-generic...

I agree in the sense that answering "what really are qualia" may be as impossible as answering "what really are quantum fields". At some point we may be forced to accept "it just is", but that doesn't mean we can't make meaningful progress first, just like in physics.

For instance, either new physics is involved or it isn't. Finding solid evidence for or against it does not seem impossible, and it would definitely constitute meaningful progress, at the very least by ruling some theories out.

> Even after mapping the entire visual cortex to all visual features, it just doesn't get us any closer to understanding that raw experience of "sight" that happens when you look at something. It's not the same thing.

Seems plausible that a detailed enough mapping of correlates one day uncovers a single thing/feature/location/architecure/pattern/whatever that is present only when qualia are, and absent in all other processes. That would at least point us in a concrete direction.

I agree. It's just quite a lot of verbose-looking XML. "I have to write that much XML" is probably not the first impression you want to give. I did scroll down and see that you don't actually have to write such XML by hand, but many will not.

The rather prominent XML on the front page might scare folks off.

To clarify, dependencies significantly affect incremental builds too. Seems loading information about compiled dependencies into the compiler and/or resolving stuff about them can take significant time.

Compilation times depend very heavily on the amount/size/complexity of dependencies.

The linked github page has a link to a paper.

Excellent work, again! Your intros somehow elicit the best out of HN too: the comments are always full of interesting angles and variations.

Wanna do quaternions next? :) Many have tried..

Does it / will it support retractions?

A fanless case would be real nice, and seems theoretically doable.

Several languages have or have had this behaviour. C# made a similar change to its 'foreach' loops a long time ago (but not 'for' loops for some reason).

I suppose it's the natural way to do it when implementing a language and not thinking about it too much. It makes a for-loop equivalent to a simple while loop with the loop vvariable initialized outside of the loop.

https://neon.tech/docs/cloud/compatibility/ says "During technical preview Neon has restrictions on user ability to install PostgreSQL extensions. Following PostgreSQL extensions come pre-installed: [..]"

This is a dynamically typed language. Null makes sense there.

It also makes sense in a statically typed language with union types, think `string | undefined` in TypeScript. The extra layer added by Some/None is not fundamentally necessary for safety.

System76 has done good work on Linux support for (seemingly) similar hardware: https://tech-docs.system76.com/models/lemp10/README.html - some of that might be reusable.

Some examples of high-level decisions: - which web framework? - which database? which ORM? which transaction isolation level by default? - will this game/UI be multiplayer? - what's our testing discipline?

You can't loosely couple around questions like these most of the time, at last not without excessive abstraction.

For "how do I structure this reasonably isolated 0-1kLOC component", I agree, easy to fix later if needed.

This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less.

The more code your design decision will affect, the more up-front planning it deserves.

A good chunk of evidence has been summarized here: https://ledger.humanetech.com/

If enough people find it interesting enough to follow, why not?

Many similarly depressing results: https://ledger.humanetech.com/