reddit.

they switched to python for various reasons.

They’re switching to golang now for other various reasons

Any links to stories about them switching to golang I can follow?

so as far as i can tell it's not like a full switch per se but reddit has services written in both python and go.

r2 (old reddit, the reddit API, some parts of new reddit, some of their ML stuff), their monolith, is still written in python.

some services they have in go include some real time services (like the reddit talk stuff seems to be primarily written in go)

reddit kinda seems to have a SOA (not microservices). while there are some codepaths that go through r2 (and indeed this seems to be the case in a lot of cases with regards to old reddit), a lot of newer code uses services.

(note: their engineering blog (/r/RedditEng) calls a lot of their stuff microservices and indeed they may be using that for some things but a lot of their stuff have been described as using more of a SOA vs a microservices.)

someone like /u/ketralnis may have more information as well?

As a counterexample, Clojure is pretty popular in some niches.

I have received offers this year to join well-funded startups using Clojure.

Datomic is great for some usecases. Clojure often leads the Stack Overflow survey in terms of salary.

   Clojure often leads the Stack Overflow survey in terms of salary.

wouldn't that also imply the classic demand and supply thingy ? the one that is alluded too in pg's articles...

My impression is that the high salary is because Clojure it is primarily used for small-ish, fairly senior, highly technical teams writing high impact standalone services e.g. it's my understanding that a Walmart's route planning teams writes their service in Clojure.

This actually meshes well with what you'd expect from a lisp being used well. Lisp's power and its downfall is that it lets you express abstraction at whatever skill level you're at with no built-in mechanisms to keep style consistent across large teams. This works really well for small teams of high powered developers.

> This works really well for small teams of high powered developers.

this is exactly right. i guess, a large part of the puzzle is to build one, and then leave them be...

Lisp as a great tool for learning FP paradigms for application in other languages. IMO, in practice, the metaprogramming that Lisp encourages isn't very good good for the understandability of a codebase, which is IMO one of if not the most important factors for building an applications in a company.

The objective test for whether Lisp metaprogramming contributes to or detracts from the readability of a codebase is to take a sample of the code base and expand the macros, to see whether that is more or less readable.

+1 These complaints about Lisp metaprogramming hurting code readability is a meme that never seems to die on HN. I doubt people who propagate this meme even use Lisp in the first place. Maybe they have only seen the type of macros you can find in C or Ruby or another non-homoiconic language and think what they have observed in those languages is true for Lisp as well.

Macros provide abstractions that often make programs easier to understand. I myself have dozens of the usepackage macro in my Emacs configuration, they hide and standardize the boilerplate that I could use instead. Nevertheless, I have serious reservations about macros in programming.

Taking a code base and expanding the macros to see whether that is more or less readable is a bit like expanding a C++ class hierarchy into assembly language and concluding that this program’s object oriented design is great because it is more readable than the resulting assembly language.

The real question is whether or not there are better alternatives than macros or metaprogramming in the first place. Functions, especially as found in modern languages[1], have proven to be very useful abstraction mechanisms and can often mitigate the lack of fancy macros.

I don’t want macros banned from Lisp, but I don’t miss them in other programming languages. Over exuberant use of fancy macros in Knuth’s brilliant TeX, in my opinion, contributes to the glacial pace of LaTeX development.

[1] By this I mean functions with circumscribed access to non local variables, provisions for choices of ownership of parameters, static scoping, first class functions, closures, and recursion.

Agreed. Metaprogramming does have it's place in languages like Lisp where it removes boilerplate or hides details that other programmers likely don't need/want to think about. However it's easy to go too far, which is really what I'm talking about. I think as long as you have first-class and variadic functions you can probably live without macros for like 98% of cases without compromising on readability (as is the case with Python). Alternatively, if you have an easy way to, at develop/compile time, identify exactly what a macro/metaprogram is doing I think it's ok, but that is subject to tooling.

Python acquires new macros in its parser. For instance, it now has pattern-matching macros which weren't there before. A few years ago it got a f'...' reader macro which wasn't there before.

Sure, but Python doesn't let users write their own macros

So if you're on an older Python, you can't backport the new syntax; you're forced to upgrade if you have some code which depends on it. In Lisp, if some code we would like to use depends on some newer macros offered by the Lisp dialect we are using, but we cannot move to a newer installation yet, we may be able to backport just the macros into our program.

You're stuck with the ill-designed crap that Python puts out. For instance, I don't agree with pattern matching that assigns to existing variables; from where I'm sitting, it looks like an incompetent clusterfuck. If someone did that in one Lisp program, the entire language would be blamed for allowing that sort of "curse".

* * *