Comment by throwawaywlabs | Hacker News Reader

Comment by throwawaywlabs | Hacker News Reader

I work at Walmart Labs. Clojure is super popular[1] in Walmart Labs. Clojure is fun and importantly it is a very productive language to work with. This gain in productivity comes from less state, thus easy to debug and fix, and functional approach, so the functions do what exactly what they are supposed to and there are no hidden surprises.

Less state or immutability means concurrency is easy. Easy concurrency means we can scale[2] applications with ease. I mean ease of development. It takes less work, less mental effort to take something that works for a single thread and make it work in a multithreaded and/or distributed manner over hundreds of thousands of cores. Debugging is easy too. P1 incidents for a microservices written in Clojure takes less time to debug compared to those written in other languages. So no wonder most of our mission critical services are written in Clojure.

For a complex environment where thousands of microservices are deployed on hundreds of thousands of computes, Clojure has been super successful.[3]

[1]: https://github.com/walmartlabs?language=clojure

[2]: http://blog.cognitect.com/blog/2015/6/30/walmart-runs-clojur...

[3]: https://clojure.org/community/success_stories

I love how you mentioned that Clojure is fun!

We use Clojure at my work as well, and ya, everything else you said afterwards is true as well. Clojure is a great productive language. It can scale, is very comparable to Java in performance, simple to maintain, has a complete ecosystem, is batteries included, etc.

But most convincing! It's just so much fun!!

Being fun is an undervalued quality of a language in my opinion. That joy you get from using it actually translates in the quality of the work you do. So it's not an intractable thing, the fun is good for you and for the product!

This can't be said enough. At the end of the day programming is done by human beings, and it needs to be treated as a human endeavor. If I enjoy what I'm doing I'm going to do it better, it's really that simple. There is actual science to back up this idea as well http://neverworkintheory.org/2014/05/01/happy-sw-devs-solve-...

Fun is important, different language in my case (Kotlin) but learning it has reminded me what it was I liked about programming.

Day job is great but spending more than half of programming time modernising some of the worst PHP I've ever seen gets old after a while.

Kotlin is actually a pleasure to use so I look forwards to using it.

One big reason why running on the JVM was a success factor for Clojure was that in Java, concurrency is hard.

Concurrency is hard anyway, but in Java it's considerably easier than it could have been (I'm thinking C++) given you know that java.util.concurrent exists and have a handy reference to the relevant book. Even having 'synchronized' as a primitive keyword has its benefits... But Java wasn't born with java.util.concurrent, Clojure had the benefit of being able to follow (IMO) one of Perl's laudable principles of "easy things should be easy, and hard things should be possible" and build the language with the assumption of being on top of a rather high quality set of existing concurrency primitives.

Concurrency plus mutability is hard. And idiomatic Java works by mutating state. A language where immutability is idiomatic can be appealing even to somebody who knows that java.util.concurrent exists and has a handy reference to the relevant book.

Stealing a line from from https://github.com/l3nz/SlicedBread - "..the over 400 rich pages of 'Java concurrency in practice' show how hard it is to write and debug a good-mannered multithreaded application in standard Java."

Heh, I wasn't even thinking of that one as the relevant reference, though it's valid. I was thinking of "Concurrent Programming in Java" as it comes from the horse's mouth, but that one is also close to 400 pages.

I don't even try to think about concurrent designs too much at work and sometimes feel guilty about it. Occasionally I'll use or suggest someone use a CompleteableFuture, but there is so much code and irrelevant detail compared to Clojure's "wrap body in (future), done". On the other hand some more junior devs have expressed lack of interest in studying concurrency at all since "we don't really work on concurrent or distributed systems", at which point I have to point out that as a company we serve a giant web application with API entry points from multiple bits of hardware with clients all over making concurrent requests... The road is long.

I highly recommend java devs use the concurrent collections and avoid using the synchronized keyword.

This, using synchronized is a mistake unless you really need to use some exotic collection without an implementation in java.util.concurrent

Not every set of operations you need to synchronize can be squished into a collection operation (add, get, etc.). If all you need to do is make sure things can get and add stuff to a queue or list concurrently, well yah, that's definitely a good place to be. Can also just shove it all off on your DB

Could you speak more on the use of macros and bottom-up programming as well as REPL-driven development at Walmart Labs (if applicable)? Would be interested to know if those lisp-like attributes play as important a role as functional programming and the JVM in general.

Not OP, but at my work, they definitely play a large role. A lot of the productivity boost comes from REPL driven development and Macros.

That said, Clojure has to be seen as the sum of its parts. It's the coming together of Lisp, FP and the JVM which truly gives it its strengths.

You guys hiring?

Reply on news.ycombinator.com