I guarantee you the bulk of traffic to SO is hitting a page and performing zero writes.

Yes it's read-heavy but there's still plenty of work done in assembling a page. It's definitely not as simple as caching at the CDN edge for every hit.

this isn't a lot. Helps that site is mostly text data.

I know of a relatively small cloud security system that transfers petabytes/month to/from a handful of customers.

4 ingest pods, 8 pipeline pods, 7 time-series db servers, 2 sql servers

Compared to other similar sites like Reddit or Quora which are far slower yet running on more hardware, it shows what proper efficient architecture and code can do.

For example, at work, our entire analytics ingest workload (HTTP) for a few hundred million users runs on 8 core VMs on GCP, written in Rust/Go, each node doing ~40k events/second.

Our RTC infra sustains >1m PPS per node on 4 core 3.9ghz 2014-2017 xeons.

To quote Rob Pike:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Go is aiming for the same niche that Python is. This has the accidental side effect of making it faster to write software in it than most of the ALGOL-derivatives. To quote Eric Raymond (sorry) on Python:

When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!

Go and Python both allow for expression about as fast as you can type, by virtue of being designed for [children in Go's case, shell scripting in Python's case].

It's not a value judgement of Rust or anything, but Rust wasn't designed with the same goals in mind.

This may be a problem of what's idiomatic in each language, as opposed to a matter of language design per se. After all, Rust development can be made at least as easy as, e.g. Swift, simply by adding enough uses of .clone() and RefCell<>. Is this suboptimal? Of course, but it will still be plenty faster than Python, and perhaps even faster than Go.

Compilation time is a separate issue which apparently OP found problematic. It's being dealt with (for non-release optimized builds) via the cranelift project, which is a Rust-specific backend much like the Go compiler, with no reliance on LLVM.

It's absolutely a matter of language design. Again, I'm not criticizing Rust, but a language explicitly designed to be trivially written by anyone, fast, is going to be easier to write in quickly by anyone. Imagine making that comment about Logo instead of Go. Of course Logo is more painless to write than Rust! It's a child's language. So is Go!

Rust development can't be made as easy as Swift (and it is very unlikely that what you described would be faster than Go). Even Graydon Hoare agrees that Rust is inadequate in comparison to Swift in terms of development ease:

https://www.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...

I'm no stranger to languages with vastly different idioms than normal (I write APL daily), but not all languages are as quick to develop in as every other, and pretending they are is silly. Rust has some innovations, and it's by no means a bad language in itself, but pretending it wins at everything under the sun (even things it's not trying to do) doesn't reflect reality or the perspective of the original author.

"Write as fast as you think" is a far better way to program than "Write much slower than you can think."

Eric Raymond has written some pretty substantial things, and he's not as clueless (on programming, at least, the rest of his views are...no) as you're implying.

The idea that intuitive languages are the only ones you should do development in is absurd. A single line of K can do what a hundred lines of C can, and you can write the line of K substantially faster than you could write the C to match. K only has something like 50 primitives. It's simple enough that you can keep it all in your head at once, and that allows you to develop much quicker than almost any ALGOL-derivative. Taking your comment at face value, everything written must be boilerplate. Looking at reality paints a different picture.

Good languages manage complexity in a way that allow you to express complex things in simple terms. That the languages you seem to be familiar with only allow you to describe simple things in simple terms isn't something that's inherent to every programming language. I'd recommend giving APL, J, or K a try.

To bring up k again, the language has already done about the maximum amount of abstraction possible. There's really no room for the programmer to make reusable abstractions; any useful ones have already been made. That allows you to do very useful things in very small amounts of code. Picking a random example, here's a complete Sudoku solver in 75 bytes:

http://nsl.com/k/sudoku/aw3.k

Rust is slow to compile so it breaks my deep work when programming, also it costs me a lot in CI/CD. Also the Rust type system make implementing some things really hard.

For example I wanted to implement json requests logging. It took me more than 1 day in Rust, less than 2 hour in go.

(SO and DailyWTF are very much into Microsofts ecosystem)

There's significant difference between ASP.NET and ASP.NET Core

https://meta.stackexchange.com/questions/316278/the-road-to-...

Looking at the specs of the machines, they are actually pretty basic as far as servers go. A server isn't barely worth the cost of it's chassis and motherboard if you put less than 64 G ram and 24 CPUs in it.

In other words, these are about the lowest specd proper servers you can get. So yeah, even their modest hardware is still overspecd for running their website.

Also, of course, the total cost per hour for 9 servers with 3 year depreciation is in cents.

Ultimately, their service is (most likely) not compute-bound.

It would rank way higher if they would be more webscale. It needs more Kubernetes, GraphQL and Golang /s