nullwasamistake

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

Just get a boring webapp job in CRUD world :)

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.

This was a PR stunt from the beginning.

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.

Java

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 I guess I meant "traditional" web MVC where HTML template for the whole page is pre-rendered on the server.

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.

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

This... Is a prison recipe :). Fish, chip coating, cook in the chip bag in microwave.

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

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

They are environmentally efficient, see the link I posted. They're one of the most fuel efficient means of transport

It can locally, but not economically in a huge country like the US. Electrified rail is a lot more maintinence.

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

This source from US govt shows that planes are very efficient in MPG https://afdc.energy.gov/data/mobile/10311

Cabron density of kerosine vs gasoline isn't that different.

Maybe the carbon footprint website doesn't consider average occupancy? Cars and busses usually cruise around at far less than their passenger capacity, not so for planes

This doesn't change flying being a more efficient means of travel. Despite many incentives to carpool and take public transportation, planes are still more efficient because the high travel speed makes being packed like sadines worth it

An SUV with 8 people can get 200 mpg/person. The link considers average occupancy. Planes are highly efficient because they're usually full

2% is from Quasar, a Java fiber library. Some simple benchmark compared it to async code.

Now that rust has async, couldn't they make fibers an opt-in replacement for threads? Your libraries use async, but you can handle those calls with fibers. Fiber support is compiled into your code but not the libraries

Fuel is a huge airline expense so people are packed into an aluminum can at maximum density. It's public transit, except the seats are nearly full at every stop.

Fuel economy is about 75 mpg per passenger. This is nearly twice the average mileage as busses, and better than nearly any other realistic form of travel https://afdc.energy.gov/data/mobile/10311

(Other sources give 75mpg for airline average but this may be for a full plane)

It's a huge misconception that flying is a wasteful means of travel. It's practically the most efficient means there is

Fibers are way better than async. Go has them and Java is working on it with project loom. It's a slight performance disadvantage (maybe 2%) but light-years easier to work with.

Languages with fibers figure ou execution suspend points and physical core assignment for you and abstract it all away. So physically they're doing the same thing as async, just without all the cruft.

Rust decided not to go with fibers to avoid having a runtime. I still disagree with this because they already do reference counting, not every worthwhile abstraction is zero cost.

I predict that long, slow, possibly "eco" trips will become fashionable as a new way to signal wealth (much in the way that travel to far-flung corners of the Earth used to).

This is very much still a thing. Personal hunting trips in Africa, sailing through the artic, flying your private plane to islands regular jets can't reach, cruising your yacht across the Atlantic.

The best way is to buy your own island. That way nobody else can go there, the ultimate exclusive travel destination

IMO this is an elitist point of view. Taxing will only serve to make travel a luxury for the elite, as it once was.

The only reason tourism has increased so much is because it's become affordable to the middle class.

The economy will adapt. There will be more tourist destinations to cancel out the increased crowds, with time.

Flying is a great way to travel in an environmentally friendly way. It's far less wasteful per mile than driving.

Tinfoily, but perhaps US anti missile systems are more effective than were lead to believe.

Adding to that, there's special regulations for almost anything. Hotels, work sites, warehouses. The national fire code is quite a tome, and usually local rules are added on top