otabdeveloper's comments

> Doing so in a structured way, more elegant than writing more parsers and compilers in C, sounds like a good idea.

http://www.gbresearch.com/axe/

Re: your point 1 -- waiting on a mutex happens regardless of whether you're using blocking or non-blocking IO.

If your program only ever makes IO system calls and nothing else, then your point might make sense, but this isn't a realistic real-world assumption.

Re: your point 3 -- not using the complete timeslice is not a realistic assumption. If you're creating threads then you're presumably doing some little bit of CPU-intensive work and not just copying bytes from one file descriptor to another.

You're making terribly silly assumptions about what kind of work servers actually do, and ignoring the real benefit of async solutions.

The real benefit is being able to control how threads switch by yourself instead of using the kernel's builtin 'black box' scheduling algorithms. The problem with the 'black box' is that the kernel might decide to penalize your threads for inscrutable reasons of 'fairness' and then you suddenly get inexplicable latency spikes.

Of course rolling your own scheduling is an engineering boondoggle and most people just opt for a very primitive round-robin solution. (Which, incidentally, is what you want anyways if you want good latency.)

In which case you might as well create a bunch of threads and schedule them as 'real-time' (SCHED_RR in Linux) and get the same result.

(Seriously, try it -- benchmark an async server vs a SCHED_RR sync server and see for yourself.)

> Does the CPU interrupt threads running happily on cores even when there are no other threads which want to run or which have affinity that would allow them to run on that core?

Yes. Even if you are careful to ever run only one process (so: no monitoring, no logging, no VM's, no 'middleware', etc.) and limit the number of threads to strictly equal the number of processors, you still have background kernel threads that force your process to context switch.

Because the "HTTPS everywhere or you're a dinosaur and you don't deserve to live" hysteria forced everyone to put HTTPS even in places where it doesn't belong.

> In 20 years, the $100,000 attack will be a $100 attack (or perhaps a $1 attack)

No. Moore's Law has been dead for years and will never come back. The benefits we saw in recent years came from people figuring out how to compile code for SIMD processors like GPU's, not faster or cheaper silicon.

> Not saying it's easy, but now it's on the horizon.

Not really. It's not a preimage attack. They spent several hundred dollars to find two random byte strings with the same SHA1 hash. There's still no way to SHA1-collide a specific byte string instead of random junk.

> And what do you do when clang isn't an option, due to customer, target hardware, OS or even language extensions?

Then you cannot use Rust and must settle for lack of safety. (A profoundly silly question -- if modern C++ is not an option for whatever reason, then Rust is doubly so.)

> These days, I'm more likely to suggest Brave over FF, if someone really requires a Chrome alternative.

Brave is just a reskinned Chrome.

> We [web developers] owe a lot to FF, Firebug, etc, but the writings on the wall for mobile and desktop.

Where I work developers have mostly switched to Firefox over the last few years. Firefox is just a better browser (faster, less bloated) under the hood. Yes, Firefox will have a difficult time sine they don't have their own proprietary walled-garden ecosystem as a distribution channel, but the technical product is solid.

C++ occupies the same mental space that languages like Haskell, Scala or OCaml.

Compared to its real competition, C++ is very elegant and a joy to use. These languages are meant for enjoying the maximum out of compile-time type abstractions, not as an easy-to-use tool for simple enterprise apps.

No, the problem is that Python 3 sucked, and still sucks.

Twisting your user's arms even more painfully won't solve the problem, it will just accelerate users switching away to other languages or forks.

Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly.

Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.

Foxconn is far, far more than just iPhones or just Apple.

> 1994

Probably not relevant anymore.

> "code is read more than it is written"

Is that really true? An amazing amount of absolutely mission-critical infrastructure runs on code that was written once and probably never even code-reviewed.

> I think python is a good example of how to be simple.

I disagree. Python was a good example of that when it was Python 1.5.

Modern Python 3.5 is a Perl-style nightmare of special cases, weird sigils, ridiculous primitive types needed because of legacy reasons, inconsistent standard libraries and everything else that comes with being a 'serious' language.

The 'rewrite everything in Javascript' hysteria reminds me of the 'rewrite everything in Java' hysteria we saw a couple of decades ago.

I wonder if it will end the same way. Will Javascript eventually go on to die where all languages go to die -- as as enterprise backend language?

> are there non-GCed functional programming languages?

Yes, C++. For the last 18 years the C++ standard has been busy adding functional features to the language. With mixed success, but still the result is quite impressive.

Yes, but it will be forked and maintained by other people anyways.

Python 2 is forever, best get used to it.

> yet most people are capable of creating spreadsheets (and writing formulas)

Not in my experience.

A malloc benchmark that doesn't measure multithreaded performance is worse than useless.