millstone

Fixed URL: https://kotaku.com/stadia-developers-cant-fix-the-bugs-in-th...

I'm not sure that answers my question; C++ also uses a state machine.

Most of the post is concerned with the compiler<->library interface - where Rust uses Generator, GeneratorState, Pin, etc. Is there something fundamentally different about the design here?

Can you say more on this? What is Rust doing differently here that simplifies things?

This is a Go idiom, one of the "slice tricks" that you are expected to just know. In fairness every language has its non-obvious idioms.

It may or may not copy.

In Go it may or may not allocate a new array; it depends on the array's capacity. This means that the resulting slice may or may not alias the original slice.

See this playground for an illustration: https://play.golang.org/p/mOpuGVj2ypG

That uses append to delete, and then modifies element 0 in the result. In the first call, only the new slice is modified. But in the second call, both slices are modified, since they share the same backing array.

I consider this to be one of the worst mistakes of Go, to design a highly multithreaded language in which variable aliasing is a dynamic property. I am convinced that many Go programs have latent races and bugs, invisible to the race detector, and they have not yet been tripped because they have been (un)lucky with the runtime's capacity decisions.

Your code removes by index. This can be done in one line in Go:

    list = append(list[:i], list[i+1:]...)

but to remove by value you need a loop.

Does D have an ABI spec? I imagine the garbage collector complicates it considerably.

Does Zig really solve this problem? For example, if I add a field to a Zig struct, can existing code still use the struct without needing to be recompiled?

Rust is certainly made simpler by not sweating ABI stability. But the main advantage of dynamic linking is to enable yesterday's app to run on tomorrow's OS (and vice-versa). It's why your apps keep working when you update your phone.

Without a dynamic linking story, Rust is just not viable for writing UIKit, Android's frameworks, etc. Which is OK, it's a reasonable choice, but it limits Rust's scope.

Note Gankra is “she” not “he”

You should consider leaving Gmail instead. I have been migrated most of my stuff away from Gmail to Fastmail. What I like about Fastmail is that its custom domain and IMAP support is first-class instead of an afterthought, it doesn't mine my email for purchases/trips/other, its web UI really is better, and I don't worry about my account being cancelled with no recourse. (No association, just a happily paying customer).

You're talking about how the app looks, but GP was talking about how the app feels.

Slack looks nice but feels quite broken. For example, its non native context menus are beautiful, but do not dismiss properly, do not support single-click selection, do not support spacebar to pick, do not support type-select...

When I use Slack I am constantly frustrated that things don't work the way my other Mac apps work.

I don't think Chrome does any of those things on desktop.

Shapiro is right-wing mainstream conservative, not alt-right.

Excess electricity can be a real problem, and is getting worse with renewables. But surplus energy would be better used to desalinate seawater, or produce hydrogen through electrolysis, or storage.

Yeah, and eventually we reach the best-effort bedrock. Maybe the file is on a NFS mount, you call write(), it goes over the wire, who knows what happens!

I hope to make the modest point that, if you package your data in a SQLite file or a zip file, then you have both packaging and data problems.

MyCoolSQLApp may read and write a SQLite file with its own schema, but it can't handle an arbitrary SQLite file. Likewise MyCoolZipApp can't handle an arbitrary zip file.

> Are you sure?

No, and anyone who says yes is lying. (Lockless NFS exists and is no fun.)

> Well, fundamentally it’s very hard to get it exactly right, and I imagine that’s why the implementation is a little involved

SQLite has set itself the horrible task of updating files in-place. I know of two reliable, simpler alternatives:

1. Appending to files through O_APPEND

2. Rewriting files through rename()

If SQLite has different magic syscalls then I would very much like to learn.

My understanding is that SQLite doesn't impose any format either?

This sounds like your issue is avoiding data corruption: then atomic writes are sufficient, you don't need a SQL parser or query optimizer or etc.

Good reply, thank you.

Yes 200k SLOC is huge (modern development practices notwithstanding). SQLite creates temporary files at whim - nine different kinds! https://sqlite.org/tempfiles.html

I know how to atomically write a JSON file. But when I read, for example:

"The temporary files associated with transaction control, namely the rollback journal, super-journal, write-ahead log (WAL) files, and shared-memory files, are always written to disk. But the other kinds of temporary files might be stored in memory only and never written to disk. Whether or not temporary files other than the rollback, super, and statement journals are written to disk or stored only in memory depends on the SQLITE_TEMP_STORE compile-time parameter, the temp_store pragma, and on the size of the temporary file..."

My eyes have completely glazed over. If I add this to my app, what will it actually do? How can I even know?

ZIP files are not a database: they are more like a directory hierarchy. But maybe all I need is named blobs: no query language parser, optimizer, indexing, etc.

SQLite positions itself as an improvement over ZIP for application file formats: https://www.sqlite.org/appfileformat.html . But minzip is so much smaller, easier to understand, debug and ship. So why use SQLite for an app if ZIP suffices?

Good observations from a MySQL perspective. Any thoughts from the other end, where the alternatives are JSON or XML or ZIP? SQLite tries hard to convince you to use it as an application file format, but it looks like a giant black box of overkill: why incorporate its 200k SLOC when the alternatives are a fraction of the size?

Not GP but since you asked, here it is: https://www.researchgate.net/publication/325462944_Planck%27...

The argument is: Planck's relation says that a photon's energy is in proportion to its frequency. But a higher-frequency photon oscillates more times per second. If you look at the energy of a single oscillation, you get a constant, regardless of frequency. This is remarkable and so we should reframe Planck's constant as the fundamental "energy per cycle."

The problem is that "energy of a single cycle" cannot be related to other measures of energy, e.g. the binding energy of an electron in the photoelectric effect. Basically it seems like unit sophistry.

We should distinguish between quantization, and "discrete particles with distinct properties." For example, the photoelectric effect demonstrates that light is quantized, but individual photons have no distinct identity whatsoever.

"Number of particles" is an observable like position, momentum, spin, etc. It is a quantum property which may or may not commute with other properties, and occupies the same conceptual space.

Many functional languages do not model effects in the type system, like the ML family. Many do not have static types at all, like Clojure/LISP.

How does this work with e.g. a text editor? It doesn't seem practical to have your UI be a pure function of an input which is 100+ MBs of text and formatting.

It seems like the monoid-thinking just obscures. Positive integers under addition are not a monoid (no identity) but you can still map-reduce their sum of squares. All that you really need is associativity, and associative operations are associative.

random() is just a function name that could do anything. We can't answer the question if we don't know what random() means.

Is this referring to anything in particular, like POSIX random()? Or does it mean all non-CS PRNGs?

If it's POSIX random() what is the proposed alternative?