Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure at Netflix (2013) [slides]

speakerdeck.com

Post reply on HN
Print view View original

81–90 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#81

Post by udfalkso »

projectileboy wrote: post #53

This is a bit tangential to the post, but I've seen a couple comments in this thread that amount to "Clojure is hard to read", but I think that's a really unfair comparison, because people are unwittingly comparing apples and oranges. It seems to me the reason people think Clojure is hard to read is that the language is so powerful and expressive, that when you're reading Clojure code, you're typically trying to unde…

I just inherited a Clojure project, one which I'm quite well acquainted with the business logic, and I find it extremely hard to read. It's very different from the many other languages that I'm comfortable with already. I'm sure with sufficient learning I can get comfortable parsing what's going on, but it is a problem.

Re: Clojure at Netflix (2013) [slides]

#82

Post by harperlee »

sdegutis wrote: post #40
jb1991 wrote: post #30

Earlier quoted context omitted.

The cancellation of a few major Clojure conferances hasn’t helped. I’m guessing it speaks to demand. I used Clojure for a long time, professionally. Not much any more. Main issue is that the language is not very readable (a pain point mentioned in these slides) and very hard to find people to work in it. Also more than any other language Clojure is very sensitive to typos in your code. A misspelled keyword results in…

Also the Clojure language had a huge growth period around 1.1-1.5 which sparked a lot of excitement and spurred a lot of community growth. But since then, most of the exciting features have been adapted to other mainstream languages either as features or libraries, and most senior developers I know prefer to take the path of least resistance, which includes avoiding less-mainstream languages and frameworks. So instea…

Re. your edit, which erased "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API": I’m pretty sure that the coment you mention referred to reagent (which builds on top of React as much as om).

Re: Clojure at Netflix (2013) [slides]

#83

Post by smoe »

shady-lady wrote: post #35
Dirlewanger wrote: post #29

Earlier quoted context omitted.

CircleCI uses ClojureScript last I read.

think they stopped: https://www.reddit.com/r/Clojure/comments/9ho97m/is_circleci...

That link only refers to the frontend where they used to have ClojureScript.

Judging from their backend job postings they seem to use Clojure and Go. .

Re: Clojure at Netflix (2013) [slides]

#84

Post by lgas »

akmiller wrote: post #64
gregwebs wrote: post #57

Earlier quoted context omitted.

You can't refactor Clojure without fear like in Haskell. It is actually possible in Haskell now to defer type errors to runtime, but I haven't heard of a practice of using that, even to aid in refactoring. See this comment: https://news.ycombinator.com/item?id=18345672

I'd disagree with this. Primarily been developing with Clojure for 5 years now with some pretty large codebases. It does depend on how you write your code but favoring pure functions, pushing immutability to the edges of your programs allows you to refactor without fear. Clojure also has many things to aid in this such as pre/post conditions, clojure.spec (which allows you to build complex type definitions), and of c…

Having spent the last two years working professionally in Haskell after having spent the previous two years working professionally in Clojure, I'd disagree with this. Haskell is roughly infinitely better than Clojure for meaningful refactoring. Clojure gives you (great) tools for using your own brain to make sure the refactor goes well. Haskell replaces your brain almost entirely in the process and just gives you a precise list of the things have to fix. The difference in experience is night and day. When you're done with a Haskell refactoring (even a major one) and it compiles again you will be completely done 99% of the time. With Clojure there's not even a "compiles again" moment to look for, and even when you think you're done you're refactoring there's a good chance that there's something that will pop up at runtime (and some point arbitrarily far in the future) and tell you otherwise.

Re: Clojure at Netflix (2013) [slides]

#85

Post by nerdponx »

KingMob wrote: post #56
z3t4 wrote: post #20

Earlier quoted context omitted.

It's interesting that in the current state of software development, a programming language that have been stable for not even a year might be considered obsolete.

A perennial problem in Clojure is libraries that reach a mostly "done" state tend to look inactive to outsiders, because the language is so stable there's almost no maintenance work. So inevitably, someone will ask "Is lib foo still being used? The last commit was over 8 months ago" and then people have to chime in, "yes, it's still in heavy use".

Several languages have this problem, e.g. Common Lisp. It would be nice if developers of libraries like this at least updated their copyright annually, as an indicator that they and the project are still alive.

Re: Clojure at Netflix (2013) [slides]

#86

Post by kachnuv_ocasek »

m12k wrote: post #55

I'd like to learn a modern production-ready functional language (I have some academic experience with SML), since they seem like a good way to grow as a programmer. Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) - but the fact that Clojure is dynamically typed is a bit of a turn off for me. My experience with dynamic vs static typing is that as a system grows in size and…

Some implementations of SML are definitely production-ready.

Re: Clojure at Netflix (2013) [slides]

#87

Post by joseakle »

nerdponx wrote: post #3

What happened to Clojure? Was it just a fad, or are people still using it in their day jobs? Are people still hiring Clojure devs? If you write Clojure at work, are you happy with it?

We use Clojure at Nubank.

We’re actively hiring Clojure devs or we can teach those who don’t know it yet.

https://nubank.workable.com

We’re very happy with it.

Re: Clojure at Netflix (2013) [slides]

#88

Post by udfalkso »

m12k wrote: post #55

I'd like to learn a modern production-ready functional language (I have some academic experience with SML), since they seem like a good way to grow as a programmer. Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) - but the fact that Clojure is dynamically typed is a bit of a turn off for me. My experience with dynamic vs static typing is that as a system grows in size and…

Another option worth considering is Elixir. It's also dynamically typed, but the pattern matching helps mitigate dynamic type issues if used correctly. It's a pleasure to work with.

Re: Clojure at Netflix (2013) [slides]

#89

Post by jhall1468 »

jatins wrote: post #79
saosebastiao wrote: post #75

Earlier quoted context omitted.

I noticed a lot of clojure codebases at amazon in 2013 (I was looking because I was learning clojure at the time). It took a look about three years later and most of them were either ported to java or scala, or dead. There were a few still running, but it looked like they were not actively developed or maintained. In my experience at amazon that likely meant they were zombie services (running but nobody used them and…

> running but nobody used them and nobody thought to take them down Experienced the same, and these services just kept hoping through the teams. And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it.

> And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it.

Don't collect any usage statistics works. In our org we're switching a lot of smaller services to lambda and using fewer and fewer EC2 instances to do our work. But then, we actually track usage on every service so there's that.

Re: Clojure at Netflix (2013) [slides]

#90

Post by jb3689 »

projectileboy wrote: post #53

This is a bit tangential to the post, but I've seen a couple comments in this thread that amount to "Clojure is hard to read", but I think that's a really unfair comparison, because people are unwittingly comparing apples and oranges. It seems to me the reason people think Clojure is hard to read is that the language is so powerful and expressive, that when you're reading Clojure code, you're typically trying to unde…

I think my issue with Clojure is that it's hard to learn how to write good Clojure. There is very clearly a way that it should be written (to keep the code clean, readable, and concise) but unless you are very familiar with working with Lisps then it's easy to create a giant mess

You could say that for a lot of other languages too, but you usually have some familiar base to work off of. That's less true with Lisps as they are so syntactically different than more mainstream languages

Post reply on HN