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

301–307 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#301

Post by darksaints »

didibus wrote: post #287
saosebastiao wrote: post #67

Earlier quoted context omitted.

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

ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.

No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11".

The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously been json numbers. Since there was no exception produced, it silently corrupted data for a couple weeks before it was caught.

Re: Clojure at Netflix (2013) [slides]

#302

Post by didibus »

darksaints wrote: post #301
didibus wrote: post #287

Earlier quoted context omitted.

ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.

No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously bee…

Woa, you're right. I had never realized they were compiler warnings and not JS errors. Thanks for the tip.

Re: Clojure at Netflix (2013) [slides]

#303

Post by ajss »

darksaints wrote: post #301
didibus wrote: post #287

Earlier quoted context omitted.

ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.

No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously bee…

People were running a real money service that consumed JSON from another service and it didn't validate the incoming JSON? Wow.

Re: Clojure at Netflix (2013) [slides]

#304

Post by yogthos »

cutler wrote: post #270
yogthos wrote: post #267

Earlier quoted context omitted.

There is macchiato-sql [1] which is modeled on HugSQL. I've used it for a couple of projects, but YMMV. I tend to use sequelizejs since it works with most databases and it's well documented. [1] https://github.com/macchiato-framework/macchiato-sql

Bejesus, Sequelize.js is a LOT more work than HugSQL. I keep looking at Macchiato but without a Clojurescript database layer I can't see it being useful.

I mean if you're on Node, it's not going to be any better with plain Js either. Stuff like this is precisely why I prefer the JVM ecosystem myself.

Re: Clojure at Netflix (2013) [slides]

#305

Post by saosebastiao »

ajss wrote: post #303
darksaints wrote: post #301

Earlier quoted context omitted.

No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously bee…

People were running a real money service that consumed JSON from another service and it didn't validate the incoming JSON? Wow.

The problem comes from the fact that clojure and clojurescript are two different type disciplines, but people approach them with the same expectations. That exact problem would have errored out if they were running clojure, and a thrown exception is good enough validation for many developers. But because they were duped into a false safety net by thinking clojure == clojurescript, it slipped right underneath their radar.

Re: Clojure at Netflix (2013) [slides]

#306

Post by justinhj »

jwhitlark wrote: post #238
justinhj wrote: post #171

Earlier quoted context omitted.

Scala is sometimes referred to as the Haskellator, in that once you get far enough down the pure functional programming road, you may find yourself wanting to switch to Haskell. Scala doesn't enforce pure functional programming as much as Haskell. On the other hand I believe that Scala is much more widespread in industry because it's easy to sneak it in the door as an OOP/imperative language that just happens to have…

After my time with Scala, I think that if I need a heavy type system, I'd look to Haskell. And there are certainly classes of problems that I would choose a type system, but the general case isn't nearly as strong as I though it was before seeing them used in anger. So, in the following, I'm not ranting at you, but I am saying I see lots of arguments for types that jump to QED without nearly enough evidence, with the…

Just like your response, my evidence is the anecdata of my own experience. I’ve built a large system that 9 engineers use, all of different experience levels. Functional programming gives more understandability not less, you can always understand the input and our output of a function from the types. I really can’t see how anyone can argue about types and refactoring ... even without any tools you can just change the function signature and get everything compiling again. You know you didn’t miss any callers. Even better one knows when you can change a data structure or effect type from one to another because the compiler will tell you. If you use scala correctly you can eliminate whole classes of runtime errors and i’ve experienced that too both in a good way and a bad way when we let nulls creep in.

Whats even better is higher kinded types let you assert semantics to engineers that are hard to do in Clojure.. this type must be appendable or foldable, this type must handle async, this type maybe missing and this list cannot be empty.

All these things are a joy not a burden once they start working for you

Re: Clojure at Netflix (2013) [slides]

#307

Post by didibus »

darksaints wrote: post #301
didibus wrote: post #287

Earlier quoted context omitted.

ClojureScript is strongly typed. I'm curious to know the specific case they ran into? I suspect it might have been interop with JavaScript, because you shouldn't have weak types in ClojureScript.

No, it's not. Try `(+ 1 "1")` in clojure and clojurescript. In clojure, it produces a runtime exception. In clojurescript it silently errs, resulting in a "11". The compiler correctly infers and warns of the problem, but that is of no use if your inputs change types on you. In the case of the service I'm referring to, an external service started serving up json strings for large numbers, whereas it had previously bee…

I asked about this here: https://clojureverse.org/t/clojurescript-is-weakly-typed/311...

And documented to what extent types are automatically coerced.

Also got the rational behind this: performance.

And that every new release of the compiler performs smarter and smarter type inference and can warn about more of these cases. Though it still misses some as of now.

Post reply on HN