Smash Company

Granted this is speculation, but I've done my homework:

1) Extreme concurrency due to Erlang underneath, which means not only being able to handle lots of connections at once, but very good DDoS resistance. See WhatsApp's blog post about it: http://blog.whatsapp.com/196/1-million-is-so-2011 An Elixir (or Erlang) process can fire up a million new nodes in a second on commodity hardware. No joke. The out-of-the-box concurrency in Elixir replaces many tools in Ruby that are normally separate gems: http://www.smashcompany.com/technology/ruby-concurrency-needs-microservices-but-not-elixir

2) Near-100% uptime possible. (Google "Whatsapp uptime"). Erlang was designed to run cell networks. It made them very reliable. The entire philosophy of the language is to "embrace failure, log it and try again ASAP." This ends up being a very good strategy when dealing with the uncertainty of the real world, and things like security concerns.

3) Live code upgrades without downtime. See this demo: https://youtu.be/96UzSHyp0F8

4) MUCH nicer syntax than Erlang. Especially for ex-Rubyists. It's a functional language (with all the advantages that provides) with a Ruby-flavored syntax. Best of all worlds.

5) Phoenix, the Rails-equivalent web API, has come out of the gate with a 2 to 10x performance improvement over Rails using a fraction of the CPU load: http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails/

6) Elixir provides true macros (in the Lisp sense). It…

CL has static typing and such in at least three important senses that aren't usually called out explicitly in these discussions. First, you can annotate types and some compilers (notably the popular SBCL) can warn you, at compile time, about issues around using the wrong types, undefined vars, unused vars, wrong arguments passed to function, etc. I've read somewhere that's all based on Kaplan-Ullman type inference developed in the '80s, along with an example implementation for CL: http://home.pipeline.com/~hbaker1/TInference.html This is the sense of using types to help you write more correct software. It's obviously not as rigorous as Java/Haskell/Shen and not everything can be done at compile time. On the other hand CL has very flexible type definitions, so you get possibilities like "integers 2,3,4,5" as a type rather than limited to "all integers" or custom types like "is keyword :a or :b or :c".

Second, compilers can use type information (or inlining hints, etc.) to compile efficient machine code, which you can inspect with the built-in function 'DISASSEMBLE.

Third, types are used in the CLOS system to support efficient multiple dispatch for multimethods, and the rest of the CLOS and MOP machinery that makes it a very "non-traditional" (despite CLOS being first to ANSI standardize) OOP system with a lot more power than other fashionable languages provide. I'm basically in agreement with the title of…

I've been thinking and reading about OOP and its roots recently.

Here are some interesting resources on the subject:

Alan Kay's elaboration on what he envisioned when he coined the term:

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Two papers he references:

https://www.rand.org/content/dam/rand/pubs/research_memoranda/2007/RM5290.pdf

http://repository.cmu.edu/cgi/viewcontent.cgi?article=2281&context=compsci

Cool article on failures of OOP:

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

Its long and frustrated, but most of the points he makes are true. A lot of the stuff people claim as

I think the original vision of OOP is more valuable than what we call OOP right now. I think a good balance would be writing low-level stuff in functional style and then wrapping it in objects when you need state and cross-library messaging. Also, it seems there is some overlap between the original vision for OOP and what we call "microservices" today.

Russian wikipedia https://ru.wikipedia.org/wiki/ЕС_ЭВМ#cite_note-.D0.B8.D1.81.D1.82._.D0.BE.D0.B1.D0.B7.D0.BE.D1.80-1 says that second generation soviet systems were oriented towards numerical computations and that they had a real problem with system software (no OS, even no assembler).

Now the architecture/os/system of the IBM S360 took some money to develop - here it says it was 5 billion $ (comparable in magnitude to the moon program - that was 25 billion $) http://www.smashcompany.com/business/cost-overruns-and-the-ibm-360 . So I guess that Kosygin was trying to avoid this expenditure.

Therefore a major point is that software development costs a lot, and they could just pirate that by copying the OS360.

On the other hand they could have done a similar thing as Amdahl/Siemens/Hitachi - copy the architecture while producing a hardware design of their own, so go figure.

I'm quite intrigued by his other essay, "Docker protects a programming paradigm that we should get rid of"[0], because I am very much embedded in that paradigm, and while I think I have a working understanding of modern concurrency frameworks from using clojure's core.async, I don't really see where docker fits into the protection of the old way.

[0] http://www.smashcompany.com/technology/docker-protects-a-programming-paradigm-that-we-should-get-rid-of

On the other hand, it's been clear to me almost from when I started using it that docker is great for development, but likely to cause huge headaches in production. It occasionally behaves in weird ways I can't explain, which is fine during development, but a would potentially be showstopper at scale.

> I'm just interested in pivot points where companies decided to switch from technology x to technology z, and what made them do it.

There's a lot of articles and blog posts on that topic, enough to keep you occupied for a long while. Here's one:

http://www.smashcompany.com/technology/my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system

Here's another

https://blog.asana.com/2017/08/performance-asana-app-rewrite/

> I meant, "When did people stop deciding to greenlight new projects using PHP?"

Did they, though? I haven't noticed. Do you have any source on that?

> Would you be interested in such a chart?

No.