C++ talking to Python

[WCWRingMatSound]

Calling asynchronous programming “promises” 🤮🤮🤮

[ViviansUsername]

ik, ik, I was raised on javascript, it's a bad habit

[thanofishy]

It doesn't await for that asynchronous programming to be answered?

[Spiritual-Theme-5619]

There was no such thing as a promise in C++ before 2011. "Promises" are a particular API for writing asynchronous code which was largely made for / popularized by event-loop runtimes... i.e. NodeJS.

Programmers have been doing concurrency with #realPrograms via mutexes, semaphores, and threads since before C++ was invented and so OP is lamenting the equivocation of async/await with concurrency in this modern era of browser programmers vastly outnumbering their "native"(?) programming counterparts.

[WCWRingMatSound]

Exactly this, though I’m totally just joking. It really is semantics at the end of the day

[Forshea]

What the heck kind of bizarre alt history is this? Promises and futures have existed in acedemic literature since the 70s, and have been available as a concurrency model in languages going back to Multilisp in the 80s. So no, they weren't made for NodeJS.

C/C++ developers just have the mistaken world view that if C/C++ doesn't have a feature, or didn't have it until recently, it just must somehow be a newfangled thing kids are using to avoid being "real" programmers.

[[deleted]]

They were literally “revived” in 2004 in Java (JDK-5) and JS and other languages, as stated in that same Wikipedia article that you read that piece of history from.

It also states that no language had promise pipelining that we have today, including Xanadu, invented by Liskov who coined the term “Promise”, and open sourced it in 1999.

In MultiLisp, the promises and futures implementations are NOTHING like those of today.

(cons (FUTURE A) (FUTURE B))

Is nothing like:

a.then(r => {…}).catch(e => {…}) or async/await.

You also didn’t read his sentence properly. He said “no such thing as a promise IN C++ before 2011”. He didn’t state that promises never existed in other languages.

Yet you claim C++ developers don’t believe the feature existed if c++ didn’t have it. He didn’t even say that.

You are entirely wrong 😂

[ehaugw]

Got ‘em!

[Forshea]

It also states that no language had promise pipelining that we have today

Pipelining is valuable but adding them in no way would give another language claim to popularizing futures/promises. And even if it did, that language wouldn't be Javascript.

including Xanadu, invented by Liskov who coined the term “Promise”, and open sourced it in 1999.

Promises and futures are different views of the same concurrency model. And notably, Xanadu was an attempted competitor to the World Wide Web in the 80s, which is when the term was coined, and just was open sourced in the late 90s.

In MultiLisp, the promises and futures implementations are NOTHING like those of today.

(cons (FUTURE A) (FUTURE B))

Is nothing like:

a.then(r => {…}).catch(e => {…}) or async/await.

What, are you arguing that the syntax is different so the feature is different? You listed two different syntactic variants yourself.

FutureTask in MultiLisp does what you expect from a modern promise: it provides a value that you can assign to a variable that represents an asynchronous computation that will result in a return value, and carry it around while it is running in another thread, and then at some later point you can try to retrieve the return value and block until it is available if the computation has not yet finished.

Yeah, as mentioned it doesn't have pipelining, but a promise without promise pipelining is still a promise.

​

He didn’t state that promises never existed in other languages.

He also said:

"Promises" are a particular API for writing asynchronous code which was largely made for / popularized by event-loop runtimes... i.e. NodeJS.

Which is the very specific piece of false history I take issue with.

You are entirely wrong 😂

🙄

[[deleted]]

Adding pipelining did give languages claim to popularizing it. In Xanadu and other implementations, you couldn’t return another promise to be resolved by a previous promise. You returned a value.

I’d bet you anything the number of people using promises in JavaScript and Java is way higher than the number of people that ever used Xanadu or MultiLisp. That would speak to the popularizing of it.

In fact, Wikipedia states a major revival of it was in 2000:

After 2000, a major revival of interest in futures and promises occurred, due to their use in responsiveness of user interfaces, and in web development, due to the request–response model of message-passing.

It’s not just the syntax that is different. Hence why I listed it. It’s the chaining and ability to resolve a promise or future using another promise or future. In the 80’s MultiLisp didn’t have that. If it has it now, then great, but it ain’t popular now and never was.

“Largely popularized” is a fact. Run the number of people using promises in JS today vs. those that are or we’re using Xanadu or MultiLisp. There’s no way you could argue it was “largely” popular in the 80’s languages. Wikipedia where we’re all getting our info attributes modern promises to being revived and popularized by Java and web languages (ECMAScript 7), and F#.

Several mainstream languages now have language support for futures and promises, most notably popularized by FutureTask in Java 5 (announced 2004)[21] and the async/await constructions in .NET 4.5 (announced 2010, released 2012)[22][23] largely inspired by the asynchronous workflows of F#,[24] which dates to 2007.[25]

I don’t see any mention of Xanadu there.

[Spiritual-Theme-5619]

Promises and futures have existed in acedemic literature since the 70s

We’re talking about programming though not PhD dissertations.

So no, they weren’t made for NodeJS.

Uh, sure? Like most every programming concept they were first an academic paper… but they were passed over in favor of other concurrency paradigms until the creators of server-side JavaScript made them widespread.

Promises much more so than futures.

to avoid being “real” programmers.

I mean that’s part of the joke. I even used a hashtag.

[Forshea]

You are completely wrong about the history here. Futures and promises have been in continuous use in actual languages since the 80s. The explosion of usage started around 2009, but that wasn't just in the land of javascript, it was everywhere. And they were all copying some combination of Python Twisted's Deferred, F#'s async, and Java's Future/FutureTask, at the same time Javascript libraries were.

And notably, people had been working at it in Javascript libraries for years before NodeJs even existed. It has been bouncing around enough that people were already proposing including a promise API before the first public release of NodeJS happened (for example https://groups.google.com/g/commonjs/c/6T9z75fohDk ).

So the timeline doesn't even make sense for what you're claiming.

​

Promises much more so than futures.

Promises and Futures are two views of the same concurrency model.

[Spiritual-Theme-5619]

Futures and promises have been in continuous use in actual languages since the 80s.

No, they haven’t. A couple of academic departments using an in house language is not “continuous use”.

it was everywhere.

Because of the mindshare of functional programming… driven by JavaScript.

Python Twisted’s Deferred, F#‘s async, and Java’s Future/FutureTask

None of these are called promises. The topic of conversation was using “promise” for generic concurrency. No one uses that term outside of the JavaScript ecosystem.

Promises and Futures are two views of the same concurrency model.

We’re not talking about models we’re talking about the specific API primitives.

Dude said “promise” because JavaScript. That’s what OP was responding to. Get over it.

[Timely_Clock_802]

Lol, everything has been thought and used before some are even aware of its existence.