Clojure at Netflix (2013) [slides] • Hacker News Board

Re: Clojure at Netflix (2013) [slides]

#71

Post by darksaints » Wed, Oct 31, 2018, 2:45 PM UTC

gregwebs wrote: post #57

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…

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

Clojure isn't nearly as bad as most would have you believe. I still prefer static strong typing, but since Clojure is strongly typed usually you'll find most of your errors within a few rounds of execution. And they have an excellent implementation gradual typing if that's your thing. If you value dynamic types, this is about as good as you can get.

Re: Clojure at Netflix (2013) [slides]

#72

Post by smneiswrngonthi » Wed, Oct 31, 2018, 2:46 PM UTC

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…

"And 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."

Om solves a different problem than js + react. Om uses react. You are comparing apples and oranges. Do you know what you are talking about?

I'm guessing you have never used react or clojurescript or OM.

What you said makes no sense.

Re: Clojure at Netflix (2013) [slides]

#73

Post by hellofunk » Wed, Oct 31, 2018, 2:46 PM UTC

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…

Um, Om is React. React came first and Om interfaced with it.

Re: Clojure at Netflix (2013) [slides]

#74

Post by kamaal » Wed, Oct 31, 2018, 2:48 PM UTC

tome wrote: post #65

kamaal wrote: post #49

Earlier quoted context omitted.

I'm not sure, but if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names, write functions hundreds of lines long, can't modularize code, write 3 nested for loops, or write nested if's where '&&' suffices. Then you are having far bigger problems related to project management, hiring and overall direction in which you are running your team/comp…

> if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names Those are the kind of things that the computer is best suited to. It's better if the programmer's brain is left to other, more challenging tasks.

One wonders what kind of challenging tasks a programmer who can't even indent code, can solve.

By the way indenting code happens to be the most basic of code review checks.

Re: Clojure at Netflix (2013) [slides]

#75

Post by saosebastiao » Wed, Oct 31, 2018, 2:52 PM UTC

codetrotter wrote: post #6

Would be interested to hear their experiences with Clojure at Netflix for the 5 years that have followed since then. Did they keep writing more Clojure? If so, how much of their code is now in Clojure compared to Java? How much more did they rewrite from Java to Clojure? Do they use Clojure rather than Java for new code? What other languages do they use? Python? Erlang? Rust? How much, in terms of functionality, is w…

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 nobody thought to take them down), which is surprisingly prevalent at amazon. But I guess it could also mean that they were running and were so amazingly stable that they didn't need maintenance, which would be a good thing.

Re: Clojure at Netflix (2013) [slides]

#76

Post by KingMob » Wed, Oct 31, 2018, 2:52 PM UTC

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…

What are you referring to by "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"?

Om uses React, it didn't predate it or anything. Many of the things Om tried are more relevant to things like Redux, not React proper, so I'm not sure what your comment is referring to.

And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.

Re: Clojure at Netflix (2013) [slides]

#77

Post by vbuwivbiu » Wed, Oct 31, 2018, 2:55 PM UTC

amazed to see there are people who find

myObject.myMethod(x, y, z);

easier to read than

(my-function x y z)

- that's 2 delimiters in Clojure vs 6 in your C-style language

Re: Clojure at Netflix (2013) [slides]

#78

Post by tome » Wed, Oct 31, 2018, 2:58 PM UTC

kamaal wrote: post #74

tome wrote: post #65

Earlier quoted context omitted.

> if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names Those are the kind of things that the computer is best suited to. It's better if the programmer's brain is left to other, more challenging tasks.

One wonders what kind of challenging tasks a programmer who can't even indent code, can solve. By the way indenting code happens to be the most basic of code review checks.

Why waste human time on what can be done by a machine?

Re: Clojure at Netflix (2013) [slides]

#79

Post by jatins » Wed, Oct 31, 2018, 2:58 PM UTC

saosebastiao wrote: post #75

codetrotter wrote: post #6

Would be interested to hear their experiences with Clojure at Netflix for the 5 years that have followed since then. Did they keep writing more Clojure? If so, how much of their code is now in Clojure compared to Java? How much more did they rewrite from Java to Clojure? Do they use Clojure rather than Java for new code? What other languages do they use? Python? Erlang? Rust? How much, in terms of functionality, is w…

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.

Re: Clojure at Netflix (2013) [slides]

#80

Post by ronnier » Wed, Oct 31, 2018, 3:03 PM UTC

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 worked in a large company where clojure was used. After the original developers moved on from that project (they always move on), it was a giant struggle to get people who could work in the code base. They ended up rewriting it in something more standard. Whatever benifit clojure provided was outweighed by the high cost of maintaining the code base and the inability to find devs who wanted to work on it.

That’s my only data point with clojure.