nadavwr

I'm a fan of Rob Pike, but not of Go. Rob Pike contributed a lot of thought to editor tooling through the years, albeit not in the direction the industry seems to be going -- for example, Sam and Acme are two editors he developed. Acme UI design is inspired by Oberon and is based on tiling, but 3rd party tooling integration is entirely different and leverages Plan9 concepts to enable a whole lot of extensibility with practically zero complexity overhead due to integration -- without any true plugin architecture. There are limits to what can be accomplished this way, but it is surprisingly powerful and I can see why a community might gravitate to his views. Unfortunately he takes this minimalist approach too far when it comes to languages IMO -- a language with no coproducts in 2025 is either a niche language or unnecessarily underpowered (how they do error handling is atrocious). Over the last decade Go went from the former to the latter.

I wonder if this offers one explanation for nail biting

PHP and JavaScript are dynamic. Here you'll be able to pass distances as feet or meters, but if you try to pass in pounds you'll get a compile time error -- can't do that in dynamic languages :)

Running bytecode instructions in hardware essentially means a hardware-based interpreter. It likely would have been the best performing interpreter for the hardware, but JIT-compilation to native code still would run circles around it.

During years when this instruction set was relevant (though apparently unutilized), Oracle still had very limited ARM support for Java SE, so having a fast interpreter could have been desirable -- but it makes no sense on beefier ARM systems that are able to support decent JIT or AOT support available nowadays.

I also sampled his scalabook domain on wayback machine, and for the life of me I couldn't find any scala book ever having been hosted there -- not within the last few years anyway. My impression is that these sites have always been more SEO than content, and that even now OP might just be hawking his merchandise.

The "better Java" niche was hot during Java's stagnation era (starting 2006 and lasting for almost a decade). The JVM was considered a great runtime, with a stagnant language, and lots of newer languages competed in that niche.

Scala and Clojure, and later Kotlin and others benefited greatly from that niche. The problem for the "better Java" niche was that Java never had to be the best JVM language in order to beat its JVM-based competition in the market. When Java started moving again (Java 8 introduced anonymous functions) and when the release cadence accelerated to every 6 months on 2017, the "Java is stagnant" justification for using other JVM languages lost a lot of traction.

Clojure was never really a "better Java" -- it's a JVM-based Lisp with good Java interop. Scala never leaned too much on the "better Java" niche, and the community is increasingly consolidated around FP. Kotlin still has some "better Java" ambitions, but they also have the Android community at their back. Without Android you would have seen Kotlin trying harder to differentiate itself from Java (EDIT: Google and Kotlin tied the knot in 2017, when Java moved to 6-month release cycle; probably not a coincidence).

Fairly young languages can still see rapid growth -- see Go (1.0 in 2012) and Rust (1.0 in 2015). But you are much less likely to see new languages trying to go head-to-head with Java on the JVM these days.

A quick google search brought up a statistic from Pittsburgh 2008 where roughly 1/5 of perpetrators were the legal owners of the gun used in a crime.

Gun crimes are so much more prevalent in the US vs practically any other developed country. Usually by leaps and bounds. Australia used to have around 20% of US gun death rate for years. In 1996 they introduced strict gun control laws. Decline in gun deaths was gradual, but over some 15 years they went down by some 70%.

Gun control can work.

What makes you think they'd think even once?

From what little I know, in the US you can only file patents for "method and apparatus". I could be wrong but I think this is a very common restriction in patent systems around the world.

Suppose they file this patent for an ebook reader ("apparatus") with this specific feature implemented in a similar way ("method"). You would be in clear violation of the patent if you were to build and distribute a competing ebook reader with a substantially similar feature. But protection drops off rapidly the further you go from replicating both method and apparatus. I.e. if you only work on a piece of software (absent the ebook reader apparatus) I think you should be fine (but IANAL).

Now suppose you were to publish an Android ebook reader app with this feature, and publish it via Google Play. Supposedly this would result in a combined software and apparatus in violation of the patent. I'm not clear on how this is usually regarded (you'd have to at least worry about patent trolls I assume) but I doubt the patent owner has a legal leg to stand on (which won't necessarily stop them from trying).

This makes about as much sense as "Is Putin's end game to stop global warming by forcing Europe to move to green energy?" No sense at all.

I seriously doubt that, and besides -- it is up to judges whether evidence are admitted, not public opinion.

This could be relevant for UAV's, but this system would defend against missiles that are purely ballistic -- no electronics to fry.

I assume that even if you don't burn through a descending missile, merely deforming the nose cone can still cause it to go off course.