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

Re: Clojure at Netflix (2013) [slides]

#61

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

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…

I use Clojure in the large, and the lack of static typing isn't something I miss. FWIW, spec allows you make similar guarantees if you use it (technically more, since you can express more than HM type systems).

I think the static/dynamic divide speaks to deep divisions in programmer personalities, but if you're open to suggestion, I would put it like this: As Haskell/OCaML are to static langs like Java, Clojure is to dynamic langs like Python/Javascript.

Clojure has a deep vein of pragmatic simplicity throughout its core libraries and community that I think does more for taming large-scale development than static typing does, but that just my $.02.

Re: Clojure at Netflix (2013) [slides]

#62

Post by nosefrog » Wed, Oct 31, 2018, 2:37 PM UTC

kamaal wrote: post #37

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…

>>A misspelled keyword results in nil accidentally flowing through your app. Some dynamic languages, worked around this issue in the 90's. Perl for example, if you use 'use strict; use warnings' will catch most of these misadventures. Having said that, only the most novice programmers make these kind of mistakes. Like the absolute beginners, in the first day or two of exposure to programming. As a rule almost any sho…

With all due respect, I think your argument is a little silly. Typos are the one mistake that programmers never stop making no matter how experienced they are, in my experience. For the same reason, you can pick up a book by an experienced, established writer and find typos in it as well.

It's useful for your tools to help you catch basic mistakes like that instead of just saying you should work with programmers who are competent enough to never write typos.

Re: Clojure at Netflix (2013) [slides]

#63

Post by diab0lic » Wed, Oct 31, 2018, 2:39 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 am very glad you asked!

I wrote and deployed (to production) some Clojure code at Netflix just yesterday. Among other things at Netflix the Mantis Query Language (MQL an SQL for streaming data) which ferries around approximately 2 trillion events every day for operational analysis (SPS alerting, quality of experience metrics, debugging production, etc) is written entirely in Clojure.

This runs in nearly every critical service, ~3000 ASGs and easily > 100k servers and Clojure allows us to also compile it for our NodeJS services as well.

Re: Clojure at Netflix (2013) [slides]

#64

Post by akmiller » Wed, Oct 31, 2018, 2:39 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

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 course test.check (property based testing).

Re: Clojure at Netflix (2013) [slides]

#65

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

kamaal wrote: post #49

StreamBright wrote: post #41

Earlier quoted context omitted.

They just disagree without explaining why. Anyways, I sometimes have typos in my Clojure code, but once I follow through with your mental model and just reproduce the problem in REPL it is easy to find these sort of bugs.

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.

Re: Clojure at Netflix (2013) [slides]

#66

Post by lvh » Wed, Oct 31, 2018, 2:42 PM UTC

Latacora has its token Clojure person: me. I write Clojure every occasion I get, we've shipped Clojure code to customers, et cetera et cetera.

Most of the stuff I'm doing in Clojure would be possible in other languages, but in a sense that's only one notch below "Turing tarpit" possible. So, in the only sense that a startup should care (would you f'ing ship it?): only possible in Clojure or a handful of close cousins.

I'm hearing less about it on HN these days? But it was a great language yesterday, remains one today, and there's constant development of tooling and community :)

Re: Clojure at Netflix (2013) [slides]

#67

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

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…

I've used all three, and at least in my opinion, Scala is the most production ready by miles.

Clojure is great if you like dynamic typing...by far the best dynamically typed functional language out there. Beware of claims that clojurescript and clojure are the same language. While both are dynamically typed, clojure's type discipline is strongly enforced (type errors will throw exceptions) while clojurescript will fail silently. I personally know of a team that experienced a million dollar bug because of this subtle distinction...you absolutely have to be prepared for it if you plan on using both. If you like gradual typing, there are some great options.

Haskell is good but the language's strictness (especially around effects) is very demanding. This can be both a good thing and a bad thing. In my experience/opinion, it's a good thing in some use cases and a bad thing in other use cases...but there's no way to opt out of it when it's a bad thing. Further, the ecosystem is far less useful than the jvm ecosystem.

Scala definitely has its faults, but its type system is extremely expressive without being extremely restrictive. I've never felt restricted by it (like I did with Haskell), but it regularly blows me away how easy it is to refactor and fix errors. The Java interop is far more intuitive than Clojure. Drawbacks: The only really useable IDE is Intellij. Some libraries tend to form an ecosystem of dependencies which don't play well with other ecosystems (ie some libraries are "Scalaz-only", some are "Cats-only", etc), which can be really annoying at times. Java interop isn't extremely straightforward in the case of collections (if that is a big concern, go with Kotlin which is phenomenal).

Re: Clojure at Netflix (2013) [slides]

#68

Post by blandflakes » Wed, Oct 31, 2018, 2:42 PM UTC

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…

There are a lot of people who claim they're more productive in Clojure, in spite of or because of its dynamic typing.

I'll just throw my anecdatum out here: I found that dynamic typing was a major pain even on my own personal projects. I also never found REPL-driven development to mesh well with my workflow.

In Scala, for example, entire classes of error that I just shouldn't be able to make don't exist. Maybe I'm just the kind of person who works better with static typing.

Clojure overall is an excellent language with really good features. It just won't get out of my way sometimes.

Re: Clojure at Netflix (2013) [slides]

#69

Post by shady-lady » Wed, Oct 31, 2018, 2:43 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…

> he Om team later praised as being the same concept they had in mind, but with a simpler and better API.

is this in public? cursory search did not return any hits.

Re: Clojure at Netflix (2013) [slides]

#70

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

nosefrog wrote: post #62

kamaal wrote: post #37

Earlier quoted context omitted.

>>A misspelled keyword results in nil accidentally flowing through your app. Some dynamic languages, worked around this issue in the 90's. Perl for example, if you use 'use strict; use warnings' will catch most of these misadventures. Having said that, only the most novice programmers make these kind of mistakes. Like the absolute beginners, in the first day or two of exposure to programming. As a rule almost any sho…

With all due respect, I think your argument is a little silly. Typos are the one mistake that programmers never stop making no matter how experienced they are, in my experience. For the same reason, you can pick up a book by an experienced, established writer and find typos in it as well. It's useful for your tools to help you catch basic mistakes like that instead of just saying you should work with programmers who…

I don't think we are talking about that kind of typos. But there is a often a big dip in quality of people, who routinely struggle to write a half decent working program without making these kind of mistakes.

Sure every once in a while its possible for any one to drop in a spelling mistake, but those are rare situations in code. Mostly because code is often not a dead piece of documentation, which is read and auto corrected in the human brain. Code works on a computer with well defined interfaces and protocols.

Think of it this way, would you hire a programmer who often makes typos, to write shell scripts that have 'rm -rf'?

If you wouldn't, how often do you trust these people to execute DROP DATABASE ?

There is a big difference between programmers who can put in typos in a sentence in a code comment, and the kind of ones we are talking about.