I think the usefulness is limited by the fact that they haven't explained how they gathered this data. At first glance, the data looks to have some specific quirks (44% Linux users, overwhelmingly in the Finance industry) – you'd have to wonder it that's due to how the survey was conducted.
There are a couple of resources listed in the end. So we've gathered the information from reddit surveys, stackoverflow, our own surveys (with more than 5000 respondents), job ads, various language popularity indexes like Tiobe.
> Ion thrusters have an input power spanning 1–7 kilowatts, exhaust velocity 20–50 kilometers per second, thrust 20–250 millinewtons and efficiency 60–80%.
3 orders of magnitude less thrust than for not needing to accelerate any fuel all the way into orbit? i'll tell you space companies will send trucks full of money to anyone who can make a reliable one.
Yeah, that's a terrible title. The article's conclusion is less dramatic (to the point of being almost a different topic):
> unless the Go Language moves quickly towards the Gem, npm, or pip model or starts to have a user experience similar to Vagrant’s, I feel like a large number of users might be demotivated by the high entry-level barrier.
Everybody saw the crash coming. It was clearly a bubble as the Shanghai Stock Exchange went up 250% in 12 months while every indicator (company profits, manufacturing prices, etc) were showing bad news.
Stock exchanges don't double in price year over year on bad news. That's just stupid.
I'm surprised the SSE has only fallen 30%. It still looks like it needs to lose another 30% (it's still up nearly 100% since early last year).
The only reason the entire world isn't shorting Chinese stocks is it's tricky to fight deliberate market manipulation by the Chinese government. Although I don't doubt this crash has made a few people very rich.
Came to basically say exactly this. The only people who didn't see it coming are the Chinese "aunties" who put everything in without any real knowledge of truthworthy advice. There's a lot of people who lost a lot of money in China this way. That's the danger of armchair expertise, I suppose.
Any situation where you have M userspace jobs running on N system threads, i.e. the number of tasks is different to the number of system threads.
Normally this occurs because you're running a large number of "green" threads on your own scheduler which schedules onto a thread pool underneath. This is good if all your threads are small/tiny since userspace thread creation is cheaper than creating an OS thread but if your jobs are long-lived then your userspace job scheduler is really just adding additional scheduling overhead on top of the overhead that the OS already has for thread scheduling and you would have been better with OS threads. If your M:N threading requires separate stack space for each job, there can be a sizeable overhead (this is why Rust abandoned M:N threading).
If you're crossing the FFI boundary a lot, any overhead adds up quick. For example, drawing a bunch of small objects using Skia, performing lots of OpenGL draw calls, allocating LLVM IR nodes, or calling a C memory allocator…
One of the nice things about M:N is it decouples concurrency from parallelism. That is, your application can spawn as many inexpensive green threads as the task requires without worrying about optimizing for core count or capping threads to avoid overhead, etc. With Go 1.5, underlying system thread count will default to the same as the system CPU core count.
It's noticeable to the end-user only in it's negative performance implications in certain situations, making things slower than they would be otherwise on the same hardware. It's a low-level construct, it is not directly noticeable to the user either way. The negative performance implications are largely under heavy load. The post you replied to gave some more specific situations.