Before virtual threads, Java server would reserve a full OS thread while that code is being processed. OS threads use lots of memory and there might a limited number available. With a single incoming request or low traffic that is not a problem, but with many parallel requests the server would choke on using too much memory or OS threads.
Javascript moved on from callbacks to async/await, which colors the async functions and requires the programmer to be aware of the issues related to async/await.
For Java Project Loom takes a different approach. For example with server applications, the server would start running the code in a virtual thread and most of the code that looks like blocking will actually work like unblocking code. You get to use regular blocking code but you get async performance.
When the code needs to wait for a response, JVM can unmount the virtual thread from the OS thread and then the JVM can run another virtual thread in the OS thread. Once the response is returned and the OS thread is free, JVM can continue executing the original request.
There are some caveats to virtual threads. There is some overhead (but not a lot), some IO calls still block (but you don't get an indication about using blocking IO) and you might stumble on new kinds of bugs related to resource exhaustion (try reserving a million OS file handles).
But no more async/await, reactive programming, callbacks. Mostly just regular imperative blocking-looking code. I'm very excited about that.
This could be solved by using for..of in an asnyc function though.
It might look like surprsising behavior maybe, but putting the async keyword outside and looping without non-awaited callbacks is the only possible way to keep the semantics sound, no?
In other words, forEach would have to return a Promise too.
That's where the function coloring rightfully annoys programmers to catch their mistakes, there are if cause also lint rules for this.
AFAIK there are two active proposals that aim to provide this natively (and additonaly enable working with lazy and/or infinite iterators or generator functions):
AsyncIterator and
tc39/proposal-async-iterator-helpers
Things don’t have to be that way. You can reject the use of async/await in contexts that aren’t aware of it (delegating it to special APIs that properly handle it).
I disagree, the success story has details that reveal lots on what's going on.
> The team uses software to prototype their instruments before implementing hardware designs. With the basic software platform already functional, developing the wavestate using Compute Module 3 took a fairly modest year
From that I would assume that software is developed on regular PCs and it took a year for them to get the software running on CM3 and hook up the CM3 to the two circuit boards and various systems. Which is super fast.
> The setup has two circuit boards. The main panel board contains all of the user interface elements, including display, buttons, knobs, wheels, and other synth-specific controls, along with MCU microprocessors to support them and communicate with the CM3.
Main board has all the physical buttons, knobs wheels, displays etc and MCUs are used to communicate with CM3
> The other circuit board has subsystems for audio, MIDI, the musical keyboard, and power, plus the socket for the CM3
The 2nd circuit board has D/A converters, midi connectors, keys and power and the CM3.
The CM3 is basically responsible for all the computations on the device. It gets inputs from various sources and outputs constantly digital audio to the DAC, midi to the midi out, data to the display etc.
I guess this would be the part where details would have been nice, but there's probably lots going on. How they ensure low latency function of the synth platform, how does the development process go, how does the CM3 integrate with the various systems. Each of those would be very indepth stuff, but imo the HN relevant part how they sped up the overall development of the platform and that is covered by the article.
Anyways, the cool part is how the three devices use the same hardware, so Korg can basically recycle both hardware designs, components and software from synth to synth. This speeds up development and reduces costs. Super cool.
Comparing that to how synths were made in the 80s, where you had to have a separate board per voice and replicate all the analog components between voices and keep their power usage and heat in control.
Thomann has nice pictures of the synths. The reuse is very obvious:
Keeping the safety belt on protects other passengers too. A person weighing 80kg has surprisingly high amount of kinetic energy when the plane trashes around.
Kinetic energy is also the reason why the flight attendants try to lock as much as possible of the loose items to the overhead bins or under the chairs.
I don't know about Sweden, but in Finland the number of firebomb/grenade attacks increased a lot in the past few years. All of them due Finnish born right wing zealots trying to burn down the shelters housing the refugees.
Luckily there seems to be less attacks in the last half a year.
I think there's been more attacks, but here's a summary of some of them: http://yle.fi/uutiset/3-8517586 (Dec 2015, in finnish)
Actually with film it wasn't that straightforward:
"In the early days of color film, the color balance of the film’s processing chemicals were made with the primary consumer market in mind–which, at the time, was predominately light skinned individuals. “For many decades, chemicals that would bring out various reddish, yellow, and brown tones were largely left out,” explains the video’s narrator."
I think it's about balancing various things. Having less code is good unless there's a hidden catch you need to be aware of or it takes a few weeks to unravel what the code does.
I prefer code that is understandable right away, is consistent and doesn't have any surprises.
A good example is Go. Many have written blogposts describing how great it is that it's such a simple language because the code is easy to read. And I can't deny that. The code is simple to read.
But then I read through pages and pages of such code and all with little meaning. Here's a loop, here we check for an error condition, here's another loop, here we check check for another error condition. It makes it harder to see through all that and answer the question "what does this code try to accomplish?". At least for me, the more code there is, the harder it is to see.
> I have learned that we are standing on a burning platform.
https://www.engadget.com/2011-02-08-nokia-ceo-stephen-elop-r...