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

I totally agree with your framing of the value of async/await, but could you elaborate more on why you think that this behavior (which I would call "cooperative concurrency") is important for (ocap?) RPC systems? It seems to me that preemptive concurrency also suffices to make RPC viable. Unless you just feel that preemptive concurrency is too hard, and therefore not workable for RPC systems?


Almost all ocap systems seem to use event loops -- and many of the biggest ocap nerds I know are also the biggest event loop nerds I know. I'm not actually sure if this is a coincidence or if there's something inherent that makes it necessary to pair them.

But one thing I can't figure out: What would be the syntax for promise pipelining, if you aren't using promises to start with?


>What would be the syntax for promise pipelining, if you aren't using promises to start with?

Oh, great point! That does seem really hard, maybe even intractable. That's definitely a reason to like cooperative concurrency, huh...

Just to tangent even further, but some ideas:

- Do it the ugly way: add an artificial layer of promises in an otherwise pre-emptive, direct-style language. That's just, unfortunately, quite ugly...

- Use a lazy language. Then everything's a promise! Some Haskell optimizations feel kind of like promise pipelining. But I don't really like laziness...

- Use iterator APIs; that's a slightly less artificial way to add layers of promises on top of things, but still weird...

- Punt to the language: build an RPC protocol into the language, and promise pipelining as a guaranteed optimization. Pretty inflexible, and E already tried this...

- Something with choreographic programming and modal-types-for-mobile-code? Such languages explicitly track the "location" of values, and that might be the most natural way to represent ocap promises: a promise is a remote value at some specific location. Unfortunately these languages are all still research projects...


Rationalists and EAs spend far more time praising the Catholic Church and other religious groups than criticizing them - since they spend essentially no time criticizing them, and do occasionally praise them.


>If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind.

You're going to be surprised when you learn that futexes are an abstraction too, ultimately relying on this thing called "cache coherence".

And you'll be really surprised when you learn how cache coherence is implemented.


Emacs 30 has a native graphical port to Android, maybe you can just use that on any Android device.


Well, that's not fundamental. There are plenty of projects that support generating typed bindings for libraries in one language for use by programs in another language. You could do the same thing here.


Fundamentally you go against the grain by generating an IDL from source code. I've never seen this done properly such that it is an improvement over just authoring the IDL in the first place and generating from that.

If your IDL isn't a first-class citizen then what do you expect the derivatives to be?


Is stackfulness required for what the grandparent describes? It seems possible to do this stacklessly: all functions implicitly compile down to a state machine, but futures are never visible.


You need stackful coroutines or continuations (which become really just a kind of growable stack) if you want recursive functions. This is a limitation of Rust’s design.


What do you suggest as an alternative way to express these concepts?

Colloquially, "library" and "service" have 95% of the correct connotations.


Ultimately, it can't. Proprietary software has fundamental limitations that force proprietary software developers to choose technically inferior designs. It's why in the long run proprietary software is doomed.


Do you have better suggestions for what words/phrases to use to refer to these two categories?


I guess service is actually fine. Calling everything a user can run a library is what messed me up. I don't know what a better term might be.


If you predictably do that then the pilots won't speak truthfully in therapy in the first place.

The only way to get the lesser benefit of therapy is to precommit to not report suicidal thoughts.

The greater benefit of "pilots honestly report their suicidal thoughts and then they are stopped from flying" is simply impossible to achieve, and if you foolishly try to get it anyway then you won't even get the lesser benefit.


You're not wrong. But for this to work, the therapists' notes must be forever sealed regardless of circumstance. The first time a pilot darts their plane into a mountainside, and the investigation reveals that they told their therapist about their suicidal thoughts, this precommitment policy will vanish. The therapist will be blamed for 174 deaths. The FAA will apologize for allowing pilots who express ideation to keep flying. Etc.

It's similar to telling your doctor about illicit drug use. Don't do it unless you really trust your doctor to (a) not take adverse implications from the disclosure and (b) not write it down anywhere. Chances of both (a) and (b) are tiny. So, just lie about illegal drugs when asked. Do your own work on making sure to avoid interactions between prescribed drugs and recreational ones.


Welcome to society since, well, forever.

you didn’t think that strong silent man stereotype came from nowhere, did you?


Aren't therapists supposed to make an exception to the doctor/patient confidentiality when the patient is taking about wanting to kill himself and take a plane full of people with him?


> If you predictably do that then the pilots won't speak truthfully in therapy in the first place.

Why do you think anonymous therapy isn't a thing? There has to be a reason, I wonder what it is...


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

Search: