Live data from Hacker News

Clojure at Netflix (2013) [slides]

speakerdeck.com

211–220 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#211
post #76

Earlier quoted context omitted.

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…

> What are you referring to by Apparently I was remembering Pedestal. See my other comment. > Many of the things Om tried are more relevant to things like Redux > 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. These are great evidence for my point, that Clojure has worked as a testing…

I don't think I was clear enough. Yes, React (and others) has adopted things from Clojure/script, but to me, that's a sign you're using inferior tools that are several years behind.

E.g., I used to do a lot of PHP, and my last PHP project was in Laravel, which is heavily influenced by Rails, and PHP 7. Many people touted "Modern PHP is just as good as Python/Ruby/Js!" but missed the point that they'd been using tools with inferior capabilities for years.

Re: Clojure at Netflix (2013) [slides]

#212
post #59

Earlier quoted context omitted.

> I know of at least one organization looking into moving away from Clojure for the purpose of having a more attractive portfolio of assets to potential outside investors. Out of curiosity, without naming the organization, can you elaborate on this? I don't understand what kind of portfolio you're talking about here, the codebase? Why would investors care whether it's done in $LANG? I thought they cared more about th…

> Why would investors care whether it's done in $LANG? I thought they cared more about the business and business-related concerns. I think the concern is around how hard long term sustainability of the codebase. If it's built in a relatively minor tool, there's merit to the belief that it'll be hard to find people that know it well. (And this is discounting the possibility that a dynamically typed language might be l…

Thanks for the answer. What you say makes a lot of sense to me. I prefer functional but statically typed languages for many of the same reasons.

I just find it surprising that investors care about this :)

Re: Clojure at Netflix (2013) [slides]

#213

I love Lisp, so I thought Clojure would be a great productivity booster. And it is, if you are a one-man or one-woman shop. But try to build a team around a Clojure project and it's another story. The language basically begs you to make "magic" happen with domain-specific constructs. That might make you feel powerful as a programmer, but it's also a nightmare for new team members to get up to speed on. And then, as o…

"Most programmers are turned off by the syntax and/or immutability." Programmers who don't see the value of immutability or can't understand it are not programmers you really want to work with.

I know plenty of productive programmers who aren't even computer science majors, and just work in Javascript and Python.

And I also know people who code in Rust and Haskell, and can never meet a deadline.

Theoretical chops doesn't make a good programmer. Knowing that immutability is a good thing and abandoning the imperative style, or even being comfortable with a functional style, isn't a prerequisite to being productive in most organizations.

Re: Clojure at Netflix (2013) [slides]

#214

Earlier quoted context omitted.

>They just don't come and post about it to hackernews and make PLC projects in github Same logic applies to clojure. I think that's the point he's making. Everyone and their 12 year old nephew rockstar developer has questions about java. I also find that clojure questions nowadays are mainly asked in the clojurians slack organization. Immediate feedback is more attractive than waiting around hoping for an answer in s…

Personally I prefer StackOverflow. SO is a wiki and it's likely my question and others' comments and answers will help someone else in the future. With any chat interface, it feels like your question may be lost if it's not immediately answered and it's often hard to follow discussions with multiple people chatting. With SO I will spend time to try and formulate a clear question. In general with slack or any other ch…

While Slack is the most popular forum, there's also Clojureverse.org, which aims to be a more threaded and permanent repository of Clojure discussions and knowledge.

Re: Clojure at Netflix (2013) [slides]

#215
post #161
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…

> Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) How about plain old OCaml? Jane Street seems to find some success with it.

Reason and OCaml are the same language

Re: Clojure at Netflix (2013) [slides]

#216
post #208

Earlier quoted context omitted.

To be fair, I wasn't comparing the two. I've never used Haskell (for more than just learning/tutorials). I would suggest that if you have runtime bugs popping up in Clojure programs then that would suggest the inputs to functions (since they should be primarily pure) are not being validated which can easily be accomplished. I would imagine this needs to be done in Haskell as well since just verifying types does not i…

> To be fair, I wasn't comparing the two. Well, the statement you were disagreeing with from the post you responded to was: > You can't refactor Clojure without fear like in Haskell. You go on to suggest you can achieve a similar experience in Clojure by "depending on how you write your code". This simply hasn't been my experience. Just "writing your code the right way" solves almost every problem that arises in prog…

Exactly, and I was responding to the fact that I never fear refactoring my Clojure code.

Your examples of the type safety can all be mimicked with spec in Clojure. Granted spec is opt-in (but I'm guessing so is some of the more detailed type safety attributes you are talking about like NonEmpty).

Anyhow, to each their own and one persons experience isn't likely to be the same as the others so I'd encourage everyone to try out many languages. Some languages click with people more than others do so it's always worthwhile to experiment.

Re: Clojure at Netflix (2013) [slides]

#217

Earlier quoted context omitted.

To be fair, I wasn't comparing the two. I've never used Haskell (for more than just learning/tutorials). I would suggest that if you have runtime bugs popping up in Clojure programs then that would suggest the inputs to functions (since they should be primarily pure) are not being validated which can easily be accomplished. I would imagine this needs to be done in Haskell as well since just verifying types does not i…

In Haskell designs, developers tend to be quite careful about setting things up so that verifying types does indicate valid data. Coming from other languages (C++, Common Lisp, and Python in my case), it can be a little surprising just how often and how easily you can make this happen.

You can do similar things with spec for Clojure. As I stated in another response that is opt-in obviously so it requires more discipline perhaps but it is definitely available.

Re: Clojure at Netflix (2013) [slides]

#218

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…

Excellent points! From my personal experience I'd also like to add that there is a bit of preference involved. I find Lisp like languages much much easier on the eyes compared to Javascript or other C-like syntax. This is also partially due to the excellent support of s-expressions in editors with things like paredit [1], parinfer [2], or clever-parens [3]. With that functionality the syntax becomes nearly invisble a…

Damn lispy is like all of them in one !

http://oremacs.com/lispy/

Re: Clojure at Netflix (2013) [slides]

#219
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 used to be a professional clojure developer, now I write in ReasonML (syntax change of Ocaml) for work.

I would say that that the reason type errors do not hurt Clojure as much as say Javascript is because Clojure data is immutable, and all the common functions operate on collections or sequences. Basically, if you write idiomatic code, you constantly use datatypes that implement the same interface which higher order functions (map, filter, reduce, etc) expect. In contrast, in OCaml for example you have to think whether you are dealing with an Array or a List. Clojure also provides mechanisms to enforce that functions (Macros too with clojure.spec) are applied the correct data parameters (clojure.spec + pre/post conditions). Spec shines when you are integrating with "foreign" data like the results of a HTTP request.

In my experience, it is faster to make changes to a project, then test quickly with the clojure repl than it is to spend a lot of time refactoring types. This is especially true when you are experimenting with how to process data a different way... Having to have all types work out at compile time is a real time sink, when mentally you already know how you want to process data.

Re: Clojure at Netflix (2013) [slides]

#220

Earlier quoted context omitted.

Thats an interesting point that doesn’t answer any of the questions the parent asked. :) Perhaps you can answer this simpler one: Netflix has been using clojure for a long time now; has that been a positive experience broadly speaking, that means clojure is still being used for new projects, or not? Having a large successful project in clojure is lovely, but much of the community’s concern around it is that its hard…

Hey, sorry I saw that and typed a quick response just as I woke up. I'm not usually at a computer so early in the day. I'll address these now that I'm in front of a machine. :) > Did they keep writing more Clojure? Yes but it has never been the primary language at Netflix. > How much more did they rewrite from Java to Clojure? Very little, if any was rewritten from Java. > If so, how much of their code is now in Cloj…

Apparently Go as well:

https://www.reddit.com/r/golang/comments/765izv/what_cool_pr...

5M req/sec is pretty cool.

Post reply on HN