The language currently knows nothing of coroutines. So, as you say, you chain Futures together, which is basically a monad. You submit that futures chain to an executor, like Tokio, and it basically moves the chain's stack to the heap, and then executes it. So, in some sense, Tokio is a stack-ful co-routine. It just so happens we know the stack's exact size at compile time, which has some nice properties compared to other stack-ful implementations.
Additionally, we have, in nightly, "generators." These are stack-less coroutines. On top of that, we have accepted (and there's a PR open in the compiler to implement) async/await. Async/await de-sugars to the whole Futures-chain shenanigans, but does it via generators. You then take that chain, and submit it to something like Tokio, making it stack-ful. Writing code with async/await is significantly more ergonomic than chaining futures together by hand, and feels more like goroutines, though suspension points are explicit rather than implicit.
Generators are likely to eventually be stable as well, so you can also write your own stack-less stuff if you want. But for now, they're an implementation detail of async/await, which has much less of a design surface area, and is what most people will want to do with this stuff, and so has priority.
I disagree. For the use case of single thread concurrency, async/await is easier to reason about, since you don't have the added abstraction of a separate execution thread (that isn't even actually a different thread). With coroutines comes the added work of deciding when to "fork", and the added work of stringing everything together with channels and mutuxes.
I myself learned to program on node.js 6 years ago, when everything required piles of callbacks (the least ergonomic form of async/await style concurrency). It's strange to see a bunch of experienced programmers saying that nobody could possibly use this style, as it is too hard, while millions of beginning programmers master it easily. In fact I remember that the people who usually had a problem with callbacks were those who had prior experience with synchronous languages.
Async/await reveals the beauty of this pattern of async, by getting rid of the syntactical cruft of promises and callbacks. It's already awesome in C# and JS, and will be landing in Rust this year.
IMO using "thread" patterns should only be done when you actually have something to gain, with real multi core parallelism. The big advantage of coroutines is that they scale seamlessly across cores. By putting the bad ergonomics of threads everywhere, you make your code ready to scale onto actual threads.
I don't read your parent as saying that async/await is bad compared to futures, but that futures code right now is tough to write. This is why so many people are psyched about async/await in Rust!
One area in which async/await significantly improves over manual futures is borrows between individual futures in the chain. In languages with a GC, this isn't an issue, but it comes up in Rust a bunch.
The user specifically asked about stackfull coroutines, which is not the direction we're going. But I think the pain point the user talked about (futures right now are difficult to deal with) will be resolved by our stackless coroutine approach, and more in line with Rust's values around "zero cost abstractions."
That's fair. This space is quite complex, with so so many options. I guess we'll know if and when the OP elaborates with more :) I very well could be wrong.
You are both right. I was specifically asking about "stackfull coroutines" as tatterdemalion says, but I stackless coroutines with await/async would be as good for code readability.
The difference between stackful and stackless is whether you can yield execution across a function that doesn't know about async/await.
The problem with stackless concerns code reuseability. With stackless you have to duplicate all your intermediate functions: once for code that calls functions or methods which can yield, and again for code that takes functions or methods which won't yield. Or you simply don't reuse code at all, bifurcating the entire ecosystem.
The stackful vs stackless effectively refers to whether the implementation uses the same stack discipline for calls that can yield vs those that cannot. In either case you're always going to have to construct some kind of stack to support nested function invocation, the question is whether you're going to duplicate all that infrastructure.
Also, it helps if you don't conflate asynchronous I/O with coroutines. Coroutines are a meta abstraction over functions (an abstraction over call chains) that can be used to create ergonomic async I/O, but have other uses, like inverting producer/consumer caller/callee relationships (e.g. converting a push parser into a pull parser with a couple of lines of wrapper code). Stackful coroutines reuse the normal call stack discipline; stackless coroutines require function annotations and compiler rewriting and lead to the code reuse problems mentioned above.
Stackful coroutines are actually a perfect fit for Rust's ownership model, and would simplify much of the work, or obviate it altogether. But for other reasons--C compatibility, poor OS constructs for minimizing memory use, and an unfortunate early conflation of coroutines with async I/O--Rust has chosen the path of stackless coroutines a la async/await as the official model.
>I myself learned to program on node.js 6 years ago, when everything required piles of callbacks (the least ergonomic form of async/await style concurrency). It's strange to see a bunch of experienced programmers saying that nobody could possibly use this style, as it is too hard, while millions of beginning programmers master it easily.
It's easy for beginners in the way GOTO spaghetti comes easy to beginners. That's all they know, after all. It however leads to bad designs and complex program flow.
let line = io::read_until(reader, b'\n', Vec::new());
let line = line.and_then(|(reader, vec)| {
if vec.len() == 0 {
Err(Error::new(ErrorKind::BrokenPipe, "broken pipe"))
} else {
Ok((reader, vec))
}
});
// Convert the bytes we read into a string, and then send that
// string to all other connected clients.
let line = line.map(|(reader, vec)| {
(reader, String::from_utf8(vec))
});
...
With monads we end up with much boilerplate that has nothing to do with the actual "business" logic.
Maybe you prefer that, but I prefer the code to describe just the business logic.
> People created dynamic languages for the exact reason of not having to define types.
Not having to define types is not the biggest merit of dynamic languages.
The biggest benefit is to be able to do things that you couldn’t do if you had a type system. You can do some crazy stuff with Ruby’s meta programming.
Another sample of one: I pay for a personal account, although I don’t really have any projects that couldn’t be public, and my company pays for company account.
> I think it’s worthwile question to everyone who is lamenting here about the future fate of GitHub if they put their money where their mouth is?
I imagine most HN readers are paying customers either directly or indirectly(their company/startup).
As a private customer, I wouldn’t object to an increase in the price if that meant they stay independent. If they get acquired by MS I am definitely stopping my subscription.
> But then again “the SV hipster development ecosystem”. Who is that exactly?
That was a reference made by user tomato.
But if you prefer my point of view, those that fill up SV coffees or live in other parts of the globe trying to replicate the SV culture and are naive to the point to give Apple and Google human attributes, while believing they are any different from a profit oriented corporation.
> Why is that? Why should people forget how evil MS was and still is?
I'm not asking for that, but making wild baseless predictions of how the service will go to shitter or how suddenly all private code will be ripped off and "I'm going to gitlab now, because Microsoft sucks!" is not part of a healthy discussion.
I do have some privacy concerns but they're no less than when Github was not owned by an enterprise software company; If anything I'd be more concerned about privacy if it were Google or Facebook making this acquisition.
People base their expectations on past performance. And for MS it hasn’t been stellar. But there is no need for speculation; we will wait and see.
The problem is deeper than that though. Unless you were developing an Editor or a Git hosting service, you were not in direct competition with GitHub. Suddenly a lot of startups will find their private code hosted by a direct competitor. I wouldn’t feel comfortable if I was them.
Exactly. GitHub Enterprise under MS rule would be an epic conflict of interest for many customers who currently use it because MS could/would compete with them.
While it's not a complete 1-1 mapping, I keep thinking of Stac Electronics disk compression lawsuit against MS when it comes to handling source code:
Gnome is open source though so Microsoft wouldn't need to buy the hosting provider to read it's source.
To be honest, even with regards to private repos, I can't see Microsoft reading the source code because that would be a massive law case waiting to happen. What I'm more concerned about is Microsoft trying to integrate more of their own suite into Github. I'm also concerned about the future of Atom; which I specifically chose over VSC because it wasn't managed by Microsoft.
I already self-host personal projects but that is only part of the story since I cannot (and should not) dictate what solutions other people use. A pretty significant proportion of open source projects I have contributed to have been Github hosted so even if I don't use it for personal projects I still will need to use it if I want to continue to contribute to those other projects.
The same people also host their deployment with some of these corporations, who doesn't use either of AWS, GCP or Azure? Do you also have the same concern that a direct competitor possibly has access to your deployed code, API keys and is also in direct control of your production environment?
Not that because it happens, it is nice; but at-least at this point the source code access concern is more of a conspiracy theory if anything.
Yes, major corporations have moved off of AWS for precisely this reason. (edit to clarify: They moved out of concern about a competitor hosting & having too much knowledge about their business.)
OK I'll avoid iterating the ludicrously long list of Microsoft acquisitions that immediately did go to shit. Often intentionally, like AutoRoute straight after purchase from Nextbase.
How long before they get bored of github then? Codeplex wasn't as good or popular as github, but did seem to have many valid reasons for existence if you were Windows focused. So they killed it.
Codeplex died because GitHub won. There was little point in keeping Codeplex around especially after MS decided to move their open source stuff to where the developers were, i.e. GitHub.
> I'm not asking for that, but making wild baseless predictions of how the service will go to shitter or how suddenly all private code will be ripped off and "I'm going to gitlab now, because Microsoft sucks!" is not part of a healthy discussion.
But they're not baseless predictions, they're based on past information and it tells us it would be prudent to minimize reliance of Github sooner rather than later.
I'm not really interested in being part of a "healthy discussion" with Microsoft. There are enough people telling Microsoft about all the things it is doing to make people dislike it.
It knows what these things are. If it wants to stop doing them, then I'm happy to use some of its products. Until then, I'm going to gitlab now, because Microsoft sucks!
If the company that ships OS with preinstalled, hidden keyloggers (using that as a pars pro toto) acquires the platform I host my code on, that's not a basis on which to be concerned?
Are you referring to the issue where the crappily written driver had a keylogger to detect keyboard volume keys, etc, or something else?
If it's the first, that's not exactly Microsoft's fault, in the same way it's not exactly Mocrosoft's fault that if you buy a Dell it might come with McAfee preinstalled.
Although, it could be argued that if the driver was verified, perhaps they should extend their verified driver program to cover that instead of just crash protection. Then again, since the arguments here are centered around not trusting Microsoft with your source code, I can see why they may not require that...
No, I am talking about a literal keylogger actively installed on the OS. To their credit, after it surfaced they now provide a privacy option to "turn it off", but they still pretty much admit to spy on you every chance they get.
Minecraft was going in the toilet slowly far before Microsoft acquired them, but the changes they made have not been for the better in my opinion. Xamarin was plainly bad before acquisition, and as far as I've been able to discern this hasn't changed.
No. Software developers, doctors, post delivery personell, whatever, is supposed to do the best in their own field, and just because there are other sectors which are considerably worse doesn't mean that we should let ours ever fall to that level too. It's not difficult to see a dystopiant future in which software might help create the most horrible of all societies, and its reach could also be global.
Because Microsoft was never that evil and they aren't evil today. It took me seeing the stuff Apple got away with the iPhone to see what a non-issue Microsoft 90s desktop hegemony was. The fear was overblown.
They were convicted of anti-competitive behavior, and that was after at least a decade of unprovable rumors and industry open-secret of anti-competitive behavior. How much more clear-cut of a case do you need?
All large global corporations are constantly involved in legal battles, because that's how conflicts are resolved in our society. Sometimes they win. Sometimes they lose and are convicted. Quite often they settle before they are convicted. That's not the difference between good and evil.
Microsoft took the view that they could bundle IE with Windows and that they could license Windows to PC manufacturers on an exclusive basis. A US court decided that given their market share they were not allowed to do that.
Google is in a similar bundling conflict now with the European Union. So far Google has lost and they may or may not ultimately lose before the European Court of Justice. Or they may settle before it comes to that.
In 2015 Apple, Google, Intel and Adobe were caught trying to keep wages down by agreeing not to poach each others' employees. They paid $415 million to settle that case.
Please look up [Company Name] litigation on Wikipedia and you will find countless cases of large companies being convicted for something or settling this or that case.
Is any of this evil? That is a question everyone has to answer for themselves in each particular case, because "evil" is a moral term. The simple fact of losing a legal battle does not qualify as evil according to my moral compass.
Unsavory and untrustworthy then, if the E word is too strong.
I'm not interested in doing business with any company that has the track record of acquiring and killing as many products as they have. I've personally lost useful tools to them on multiple occasions and I don't use MS software for anything more than I'm forced to on provided hw for my employment.
My one Win10 laptop experience was enough to tell me that MS is still untrustworthy when it comes to forcing behavior on users.
If my work situation ever shifts enough to allow a Linux machine, I'll happily never look back.
But the users from 20 years ago aren't dead yet. It's difficult to get a widespread bad reputation in business, but once it's obtained, it needs an incredible amount of repairing and good-doing to get rid of it again, and it's not that Microsoft is doing any of it with their recent pseudo-openness approach, they just realized that OS lock-in doesn't work any more and that they have to massively invest in cloud data/services lock-in and the race for AI, by giving their OS/VS away gratis, to prevent a world of Java and web developers and Apple after loosing the entire mobile sector. Looks like people will fall for that lock-in/dependency again because they don't understand digital, and Microsoft can buy their way out of their previously miserable situation. Wonder who paid for that, probably all the companies with Microsoft licenses because of lock-in and market dominance.
