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

141–150 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#141

Post by TeMPOraL »

ronnier wrote: post #80
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…

It saddens me to hear such stories as they show up from time to time. I can't help but feel that a lot of programmers just decide to stop learning at some arbitrary point in their career (my observations suggest that point is around the end of their university term or their first job). The industry too seems biased heavily in favor of using lowest-common-denominator, dumbest possible solutions they can get. And not "dumbest" in the sense of "simple therefore robust" - but in the sense of "barely suitable for the job at hand". It's like wanting to dig a pool, and hiring a lot of people with spades, even though you can get excavators for free - but what, you couldn't be bothered to find a few drivers? And the spade crew comes and is all, "no way we're going to learn to operate an excavator, that's too much, let's dig by hand".

I can't explain it any other way. Learning Clojure, or another Lisp, to the point of being comfortable around a codebase, is a matter of weeks for an experienced programmer. It's comparable to the time you need to even figure out how to rewrite an existing mid-sized codebase, and since you have to read it to understand it, why not learn the language along the way? Then suddenly the rewrite isn't needed. But it feels like a concept of learning a new language on the job isn't even considered by people.

Re: Clojure at Netflix (2013) [slides]

#142

Post by davnicwil »

vbuwivbiu wrote: post #77

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

To me the delimiters help with readability by breaking up the statement into its component parts in a visual way that I can immediately parse.

Before even reading the variable names I understand the role of each in the statement.

Re: Clojure at Netflix (2013) [slides]

#143

Post by jwhitlark »

udfalkso wrote: post #81
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.

If you can, I'd suggest use spec to improve your understanding and verify behavior. I certainly do know that Clojure can get very dense if you're not careful.

http://blog.cognitect.com/blog/2017/6/19/improving-on-types-...

Re: Clojure at Netflix (2013) [slides]

#144

Post by imhoguy »

nerdponx wrote: post #85
KingMob wrote: post #56

Earlier quoted context omitted.

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.

Damn, you have just brought me an idea for next weekend project. Copyright-year updater which submits PRs to GH projects :) In Clojure of course!

Re: Clojure at Netflix (2013) [slides]

#145

Post by michaelmrose »

diab0lic wrote: post #134
kbp wrote: post #126

Earlier quoted context omitted.

> but as a LISP most people aren't going to be excited about using it. I agree that Clojure has a lot of strong points and that s-expressions probably put a lot of people off, but as a Lisp programmer, I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk…

Oh, yes this is another excellent example of pain while building Clojure code bases. Though I'll say I only agree with half of your statement. I've found the interactive development story to be great with nrepl/fireplace/vim but the debugging is downright terrible... this is the single biggest blocker to me using it for larger systems.

Debugging seems acceptable on emacs with cider. Sayid seems interesting as well.

Re: Clojure at Netflix (2013) [slides]

#146

Post by jwhitlark »

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

I think there needs to be something like the Apache foundation for Clojure libraries, not handling major dev work, but maintaining working libraries over time.

Re: Clojure at Netflix (2013) [slides]

#147

Post by kickopotomus »

jb3689 wrote: post #90
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…

This is my experience as well. I started working pretty heavily with Clojure about 2 years ago and just now feel that I am getting the hang of it in terms of style, yet I still feel like I have a ways to go.

This has not been my experience with languages like Java, Python, Go, etc. where I feel that I can write good, clean code in a matter of weeks from reading through style guides and understanding language conventions.

Re: Clojure at Netflix (2013) [slides]

#148

Post by jimbokun »

jb3689 wrote: post #95
udfalkso wrote: post #88

Earlier quoted context omitted.

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.

I love Elixir but it's worth noting that I'd be hard-pressed to recommend it for every project because of the performance and base OS integration characteristics of the BEAM. The BEAM is a truly amazing piece of software and I do think that Erlang and Elixir are the true microservices dream we all wanted, but the BEAM uses preemptive scheduling and doing things like spinning up a new OS process can be a lot more work…

Why in the world would you spin up a new OS process in Erlang? Having its own process model is at the very core of Erlang's design, so it seems very odd to want to bypass it.

Re: Clojure at Netflix (2013) [slides]

#149

Post by arximboldi »

systems wrote: post #11
rb808 wrote: post #4

Is Clojure still a thing? It seems to have fallen off my radar. Java seems resurgent after 8, even Scala seems to have lost momentum.

to talk about something new, you need to have something new to talk about i dont think that scala or clojure have lost momentum i think both clojure and scala, stopped adding new features that are worthy of blogging about you cant just add feature, just to keep people talking about you clojure, is what it is, a nice language, a very smart leader (rick hickey), and a nice vibrant community (check #clojure on twitter)…

Interesting to hear about C++ in this context, since of my goals is to make C++ more like Clojure:

  https://www.youtube.com/watch?v=sPhpelUfu8Q
  https://www.youtube.com/watch?v=vohGJjGxtJQ
There is a lot of I could say about the relationship between C++ and Clojure, but I'll leave it at that for now :-)

Re: Clojure at Netflix (2013) [slides]

#150

Post by auganov »

This talk goes into detail how Clojure plays out in larger teams, particularly how they worked to maintain REPLability for a huge monolith: https://www.youtube.com/watch?v=BThkk5zv0DE

That said, I think a lot of the preoccupation with rewrites is just premature optimization. Just a while ago I noticed some open source Clojure code of a startup acquired by FB got rewritten in Haskell. Was very glad to see founders don't seem to be working on this new code-base. Probably moved on to do higher value things.

Post reply on HN