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.

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

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 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.

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

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.

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.

We use gRPC web, so backend is a bunch of RPC endpoints. Front end is regular SPA.

This has worked great for us because it reduces backend to "shipping objects" instead of all the bs you normally have to deal with in HTTP.

With gRPC there's no use for rails, or any HTTP server framework. As far as I can tell, this is the future of web endpoints, so rails will die out.

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.

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

Not saying it's bad, I've done it. Chips are a great substitute for bread crumbs.

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

For long distance travel were going to be using fossil fuel for a long time, at least until batteries double or so in density.