Thanks for looking Dang. I don't agree with you this time though. Hiding abuse out of the comment chain behind emails is a good way to make things disappear. What kind of community is this if you can't question the motives of someone with a penchant for only replying to policital threads of a certain flavor?
His profile is public, it's not like I made everything up. He posts on articles with "China" in the name about 90% of the time. And basically never replies to his own comment responses or posts that don't relate to China.
> Don't post accusations of astroturfing or shillage in the threads—the poison that adds to the site is much worse than whatever it's trying to combat.
I don't agree at all. If I didn't say anything about the guy's post history would you have checked? I don't think so. And even though you did, it's very clearly biased towards "China" news articles and the CCP party line.
I'm out. Leaving on my own this time. I appreciate the great work you and the moderators do. But if you can't admit the most obvious AstroTurf shill account I've ever seen is real, there's no point sticking around being a thorn in your side.
Somewhat. OP also mentions generating energy from the pavement, which I don't think will ever be reasonable.
Solar car park covers are a great idea. Easier access than roofs, don't need to be water proof. Good cooling airflow underneath. Tend to be close to cities where power is easier to transport.
Solar parking lot covers are the best ROI solar installations I can imagine.
Surprised Telsa isn't doing this with their SuperCharger stations
Solar roads and sidewalks are a PR stunt. Abrasion is no joke, nothing optically transparent survives on the ground. You can see this easily in the cellar "pavement lights" common in NYC and other old cities. Light still passes through after a century, but maybe 20% and very diffuse. Bad for solar panels.
Roads don't absorb enough energy to generate power, they're not flexible enough. They're designed to not absorb energy since it hastens breakdown. Potholes are a good example of a road surface energy absorber :) .
Solar roofs are a far better bet. Elon is onto something there, but time will tell if costs can be brought down enough. Besides the good PR, solar roofs substantially reduce heat absorbtion, important in the sunny climates solar works well in. And we have a ton of wasted roof space. Many companies would willingly allow roof panels to be put up for free if the economics for power generation were good enough.
We can't even make roads last 20 years with the most durable materials we can find. We make them out of rock and they still fall apart.
Car windshields are scratched to hell after a decade. Grocery checkout scanner windows are made of Sapphire, nearly as hard as diamond, and still need to be replaced.
Solar roads will never be a reality. Optically clear material hard and malleable enough seem a physical impossibly. Metals are the only suitable material and they cannot be made transparent due to hard physical constraints.
Is there a reason why almost every single comment you've made in the entire year history of your account on a tech news website involves China politics? In fact, almost every post you've replied to has the word "China" in the title. Almost like your replies are semi automated.
JSON sucks. Maybe half our REST bugs are directly related to JSON parsing.
Is that a long or an int? Boolean or the string "true"? Does my library include undefined properties in the JSON? How should I encode and decode this binary blob?
We tried using OpenApi specs on the server and generators to build the clients. In general, the generators are buggy as hell. We eventually gave up as about 1/4 of the endpoints generated directly from our server code didn't work. One look at a spec doc will tell you the complexity is just too high.
We are moving to gRPC. It just works, and takes all the fiddling out of HTTP. It saves us from dev slap fights over stupid cruft like whether an endpoint should be PUT or POST. And saves us a massive amount of time making all those decisions.
We have some pretty vanilla file upload code that needs async. S3 latency is fairly high. If you're uploading a few tiny files per user per second, thread usage gets out of hand real fast.
With a simulated load of ~20 users we were running over 1000 threads.
Several posts in the chain say that 20k+ threads is "fine". Not unless you have a ton of cores. The memory and context switching overhead is gigantic. Eventually your server is doing little besides switching between threads.
We had to rewrite our s3 code to use async, now we can do many thousands of concurrent uploads no problem.
Other places we've had to use async is a proxy that intercepts certain HTTP calls and user stats uploader that calls third party analytics service.
Just sayin it's not that unusual to need async code because threading overhead is too high
Amazon still runs a bunch of Perl in the back. Just because you're stuck with some design choice doesn't mean that framework has a solid future. People still write plenty of COBOL but you don't see any new applications using it
I'm convinced RPC frameworks are the future of REST. It's too crufty without them. Most of the rails stack just isn't involved in those calls, so there's not much purpose using it.
Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency.
Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,000 threads. The OS isn't going to like that.
With async you can run a single thread per core, with no concurrency limits. So you get your 500k requests without overhead. With fibers you just run 20k fibers which is a little bit of overhead but easy to do.
This is the core reason everyone is pushing async and fibers in fast languages. When you can push a ton of requests/second but each one has latency you can't control, regular threads will kneecap performance.
In "slow" languages like Python, Ruby, etc, async/fibers don't really matter because you can't handle enough requests to saturate a huge thread pool anyways.
Yeah for sure. In Java/C# I see people do this all the damn time. Use async method for REST endpoints then make a blocking DB call. Or even worse, make a non-async REST call to another service from inside an async handler.
As soon as you do that, your code isn't async anymore. And if you're using a framework like Vert.X or node that only runs one thread per core you're in big trouble.
The most reasonable answer I've seen to all this is Java's Project Loom. An attempt to make fibers transparently act like threads, so you can use regular threaded libraries as async code.
Rust is going to have the same problem Java does with async. A lot of code was written way before async was available, and it not always obvious whether something blocks.
Eh, no. The whole MVC pattern is obsolete and every web project I've worked on less than 5 years old is a SPA. It's gone the way of PHP. It will always be around in legacy stuff but hardly anyone is building new project with it.
>A similarly impairing dose of cannabis results in 0.00001 ppm
Yeah this isn't going to work. The detection threshold is so low it's gonna go off if someone is smoking weed within 500 feet. There will be so many false positives it will practically be a divining rod.
Police already abuse sniffer dogs frequently, we shouldn't allow them to use another unreliable tool to arrest people.
I understand why you didn't, but async brings a whole new opportunity to try! At least in library form.
Fibers are great because you can pretend they're threads. Everyone knows threads. Async is a legit PITA even if you're familiar with it. And the local state stored for a fake thread is often useful. When doing async I find myself frequently building hacky hashmaps to hold local variables values. websocket code is a good example of worse-case. 20k ongoing connections held by async (1 thread per core). It's a nightmare in everything except Vert.X Sync (fibers in Java) or maybe Golang and Erlang.
With fibers you get to keep all your local variables and "pretend" threads actually exist. It's a huge boon for productivity in the few languages where it's possible
It's not the same as copying the "feature", in many cases Google straight up takes your content and puts it on their homepage. The difference between a product and a feature is nothing. Every app made is just a bunch of features put together. AWS S3 is a great example, it's just like Dropbox for nerds.
A lyrics website recently put fake lyrics on their site to prove Google was copying, and sure enough the fake lyrics showed up a couple weeks later.
Google isn't just taking content from "evil" companies like Yelp, they're doing it to everybody.
Job search, shopping, song lyrics, news, and who knows what else, is all being somewhat blatantly lifted. And nobody can stop it because blocking Google is a death knell to any site
His profile is public, it's not like I made everything up. He posts on articles with "China" in the name about 90% of the time. And basically never replies to his own comment responses or posts that don't relate to China.
> Don't post accusations of astroturfing or shillage in the threads—the poison that adds to the site is much worse than whatever it's trying to combat.
I don't agree at all. If I didn't say anything about the guy's post history would you have checked? I don't think so. And even though you did, it's very clearly biased towards "China" news articles and the CCP party line.
I'm out. Leaving on my own this time. I appreciate the great work you and the moderators do. But if you can't admit the most obvious AstroTurf shill account I've ever seen is real, there's no point sticking around being a thorn in your side.