divs1210

Hi, Alex!

Happy you find it cool!

I will update the Clojure and core.async versions to latest.

You're right I forgot to mention the JVM version in the benchmarks.

I'll be running fresh benchmarks once the current task I'm working on is done.

I will have to look into io-thread, not familiar with it.

Although my aim with the benchmarks is to have nearly identical code for all platforms without any platform-specific optimizations - I'm not sure yet how io-thread plays into that.

Will definitely add the JVM version and update Clojure dependencies and let you know when I have fresh benchmarks.

Libgoc is a Go-style CSP concurrency runtime for C: threadpools, stackful coroutines, channels, select, async I/O, and garbage collection in one coherent API.

I have a feeling that Half Life 3 will have groundbreaking AI NPCs.

Half Life is my favorite game franchise of all time.

Played all the canon games and SO MANY mods.

Still obsessed with it.

Neat project!

By the way, to see a great example of how a modern game can be made using the classic Half Life engine, look at the fan made game Half Life: Echoes [1].

It actually looks pretty decent, and the gameplay is top notch.

[1] https://www.youtube.com/watch?v=fBQKi6vGX8U

Same as dynamically typed vs statically typed languages.

Easy to write bugs in unsafe languages like C / C++.

Rust makes memory management explicit, hence eliminating those bugs. But it also shows how hard memory management actually is.

Systems programming languages like this should be used sparingly, only for stuff like device drivers, OSs and VMs.

Any general purpose programming language should be garbage collected.

Pinewood Derby vibes

A person of culture, I see.

Electric Monks were made for a reason.

Surprisingly pertinent to the current discussion.

This discussion is seriously lacking in references to Koka language[0].

Koka is memory safe without using traditional GC, has effects, and is pretty cool over all.

[0] https://koka-lang.github.io/koka/doc/index.html

Particle spin explained:

Imagine a ball that’s rotating,

Except it’s not a ball, and

It’s not rotating.

(popular particle physics meme)

From what I understand of QFT, the Universe is made of fields of different types, and a “fundamental particle” is just an excitation (wave) in the corresponding field.

For example, a photon is a wave in the universal electromagnetic field, A charm quark is a wave in the universal charm quark field, etc.

I’m not a trained physicist, so I might be wildly wrong.

Thanks for the explanation.

That quote is extremely terse and would have taken a considerable amount of time to understand.

Yes! I have played with Shen before.

IIRC the type checker is literally a Prolog.

commenting for future reference.

that's a great quote.

The SEC chief is Gary Gensler who used to teach a Cryptocurrency course at Harvard...

what about linux?

Luminus has a successor called Kit.

Are you complaining he used a word you weren't familiar with?

> merely shining a light on the object would give it a nudge

so you're saying you would change the outcome by measuring the system?

Hao Wu is an immunologist.

I hope he isn't connected to Stanford's Nolan.

LK-99 is weirdly connected to UFO lore, so I'd want to be cautious.

What balderdash.

I didn't know Java had a `function` keyword.

That is TS, not Java. Not sure why the gp is calling it Java.

Good point!

Maybe a future AI could generate machine code that could be "disasssembled" into higher level languages.

Not sure if that would be better.

> No shared mutability. This is an unrealistic constraint;

Hard disagree.

It is impossible to safely use shared mutable state b/w parallel processes.

See how DB isolation levels work - serializable is the only safe way to go if your processes do anything conditional on the current state. To parallelize, you have to partition the DB which is kind of a cheap way to split one physical DB into separate logical DBs.

So even DBs - the largest shared mutable states we have - are also not really shared mutable states. They need to be broken down into unshared mutable states to be useful.

Shared mutable state is a smell both at the code level and system level.

Without those lightweight processes that process messages sequentially from their inbox these behaviors won't give the same concurrency guarantees.

I don't know why the author is turning this into a competition of whether processes are more important or behaviors - they both are parts of a well designed system that work well together.

GenServers etc can't be written equivalently in Go/Java since goroutines and Java threads (even the new virtual threads) are not pre-emptive, whereas Erlang processes are truly independent.

Interesting.

Why do you say so?