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

271–280 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#271

Post by cutler »

yogthos wrote: post #269
cutler wrote: post #265

Earlier quoted context omitted.

The survey opens with: "Welcome to the largest survey ever of Java developers ... The survey was conducted by publishing its availability to the Java community at large (via social media primarily), to Java User Groups around the world, including the Virtual JUG, and to subscribers of Java Magazine, the Java bimonthly publication from Oracle Corp." So the sample is heavily biased and doesn't include the population of…

That's very likely the case, but presumably you'd get an even sampling from the users of other languages. It would be interesting to see some more surveys focusing on the larger JVM ecosystem though.

As far as jobs go let's face it - Clojure has never seen anywhere near the adoption of Scala.

Re: Clojure at Netflix (2013) [slides]

#272

Post by narwally »

lemming wrote: post #205
choot wrote: post #125

One strategy which i learnt from a tech company executive is that if you want to hire best of best at low cost, develop products in interesting new programming languages as the most curious programmers who are very serious about programming care less about money and more about work in a particular language of their interest. No wonder the company had successful projects in every asoteric languages. Now, I come from e…

...if you want to hire best of best at low cost, develop products in interesting new programming languages as the most curious programmers who are very serious about programming care less about money and more about work in a particular language of their interest. The problem is that the particular language of their interest probably changes every 6 months.

>The problem is that the particular language of their interest probably changes every 6 months.

As a language nerd, one of the nice things about Lisp is that the language is easily extended into other paradigms. I've stuck with Clojure for a long time because of this. It had Go style CSP-concurrency as the core.async library within a few years of release. I can use types by just loading core.typed, or I can play around with logic programming with core.logic. Whenever I find a cool feature in another language, I usually find out that it's already available in Clojure as a library.

Re: Clojure at Netflix (2013) [slides]

#273

Post by CMCDragonkai »

matt-noonan wrote: post #229
lgessler wrote: post #179

Earlier quoted context omitted.

Think of it this way: spec gives you an easy way to ensure that your data conforms to arbitrary predicate functions. Suppose you have an XML format, that has books and authors[1]. The elements look something like this: , . Obviously, you want to make sure that book's author-id attribute will always refer to an author that actually exists. This is something a (Java-style) static type system can't do: it doesn't know a…

That blog post was a nice read, thanks! I realize this is just one example, but you might be interested to know that I've done some work making this kind of invariant enforceable via static types (though in practice, you need a combination of features that aren't found in many mainstream language besides Haskell afaik). See the README here for motivation and some examples (in Haskell, but hopefully the idea is still…

I found your explanation of the relationship between an existentially quantified type and rank 2 polymorphism to be quite illuminating. Do you have any ideas why Haskell didnt have the direct way to express existential quantification in the type signature? Is it a technical limitation or something else?

Re: Clojure at Netflix (2013) [slides]

#274

Post by CMCDragonkai »

yogthos wrote: post #255
jerf wrote: post #123

Earlier quoted context omitted.

Haskell does REPL-driven development fairly well. It's not the best REPL, but it works, especially if you take a moment to learn a few of the commands to drive it. Dynamic types are not necessary for REPL-driven development.

Haskell REPL is a completely different animal from the one in Clojure, and it's a stretch to say that you can do REPL driven development in Haskell. What people mean by REPL driven development in context of Clojure is that the REPL is running within the context of the application you're developing. The editor is connected to the REPL, and you can modify any part of the application at runtime. You can even connect the…

I do all my Haskell development in a repl driven way. It's even better than Python's repl due to the way it loads modules and allows reloading quickly and automatically checks the type signatures.

Having the entire application loaded into your repl is even more powerful. I did it once in PHP using psych and was able to make use of any controller and try parts of it out. The main thing that is necessary is the ability of the REPL to either drive change to the code, or react to changes on file (the former is temporal, the latter is more permanent) and perform the necessary incremental computation to become eventually consistent.

Re: Clojure at Netflix (2013) [slides]

#275

Post by [deleted] »

paulie_a wrote: post #210
Scarbutt wrote: post #199

Earlier quoted context omitted.

To clarify, the reason I prefer nodejs (for web apps) over clojure these days is the vast amount of libs and documentation for almost all your needs. Clojure has the java ecosystem, but it was very tedious (more cognitive load) investing lots of time doing interop instead of just focusing on the problem at hand. Interop is both a feature and a curse. Of course, as a language I find Clojure superior in almost every wa…

Honestly the vast amount of libs is the reason I don't like nodejs. It's a lot of shoddy duplicates.

[deleted]

Re: Clojure at Netflix (2013) [slides]

#276

Post by bribri »

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…

This is the number one opposition to Clojure I hear. I was strongly in the static typing camp and rejected Clojure at first, even compared to Java and C++. I tried Haskell and found it amazing, but still too complex. After knowing more about functional programming I returned to Clojure and it finally clicked. I feel writing extremely simple code quickly and reinvesting that time into writing tests was a better workflow than any typed language I've used. I've only had a good experience in the REPL using emacs, but when you set it up properly, it's amazing.

Re: Clojure at Netflix (2013) [slides]

#277

Post by bribri »

jerf wrote: post #123
xapata wrote: post #99

Earlier quoted context omitted.

Try to grok REPL-driven development before dynamic typing. You won't like the latter until you love the former.

Haskell does REPL-driven development fairly well. It's not the best REPL, but it works, especially if you take a moment to learn a few of the commands to drive it. Dynamic types are not necessary for REPL-driven development.

Building up complex types in the REPL is hard compared to using a map...

Re: Clojure at Netflix (2013) [slides]

#278

Post by fulafel »

tanin wrote: post #166
KingMob wrote: post #61

Earlier quoted context omitted.

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…

Is Spec simply a test? Or is it something more? I keep hearing about it, but it seems to be more than just a test case. Let's take a simple example. I have an object with the method named "get". But I call "fetch" in my code. When will I see this error? During compile time or run time?

It's a way to describe the shape of data, a bit like schema but focus on non-exhaustive description and composability. The practical uses can be generative tests, is-a queries, conformity tests, "describe deviations from spec" queries, etc. You can also write spec for diffs in data structures, so you can use it for state changes. It's pretty open-ended.

Re: Clojure at Netflix (2013) [slides]

#279

Post by fulafel »

kbp wrote: post #126
diab0lic wrote: post #115

Earlier quoted context omitted.

And now that I've responded to the GP, to address your points: > that means clojure is still being used for new projects, or not? This has been / will always be a professional choice of the engineer(s) starting a new project at Netflix. Clojure is great for a lot of reasons and lets you target JVM/NodeJS at the same time (our two largest backend languages) but as a LISP most people aren't going to be excited about us…

> 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…

It's a big exaggeration to say Clojure stack traces aren't useful. They have some extra noise but they do the job of pointing out the call chain and the exception value. Tooling (CIDER at least) can automatically hide the frames about the Java runtime and highlight the Clojure info & line numbers.

Re: Clojure at Netflix (2013) [slides]

#280

Post by vorg »

zmmmmm wrote: post #243
dgritsko wrote: post #10

Earlier quoted context omitted.

Barely hanging onto the top 50 at #49 according to the TIOBE index (Java is still #1). Make of that what you will. https://www.tiobe.com/tiobe-index/

I like the CloudFoundry report [1] better as a reflection of what businesses are actually using rather than search engine metrics (TIOBE) which are overly influenced by controversy and search engine methodologies than actual usage. However it's no prettier a picture, almost no functional languages in the list at all, only Scala making a significant dent (and you can debate whether that is functional or not). Other JV…

> Other JVM languages like Groovy are significantly ahead of Clojure in all rankings.

Apache Groovy fluctuates on TIOBE a lot. Six months ago it was at the same 50-ish position as Clojure, which is its usual ranking. It's shot up only in the past 6 months, which has also happened a lot in the past and is always followed by a sudden fall -- perhaps someone's gaming the search engine rankings. On Redmonk, Groovy and Clojure have ranked equal-ish for a long time. In the CloudFoundry report, Groovy is at the same very low rank as Others which would include Clojure if present.

So Groovy and Clojure are at the same ranking in all rankings I've looked at.

Post reply on HN