Hacker News Reader

Comment by dominotw | Hacker News Reader

I switched to clojure for a new job from doing scala for 5 years. I just feel a weight has been lifted off of my head. Weight of syntax, slow compilation, weight of implicits ( some of them are so bad even editors like idea couldn't figure out what is going on). And most importantly the weight of the constant feeling of not being able to fully understand the meaning of endless math terms thrown at me casually like monads, freemonads, applicatives , categories, Kleisli ect.

I spent so much time learning what all these math concepts apply in programming but now I don't remember what any of these mean anymore and I am still shipping production applications ( in clojure). Sigh, what a waste of my life doing scala :( .

View on HN

This touches on a difference between the Go and Scala communities and courses from my very brief experience learning scala for work the past couple months.

The older I get the more I want things that are explicit and easy to understand. Tons of sites and videos and blogs exist that break down the features of Go without a ton of math lingo. I never see Scala materials free of that. Even when I agree that I need to understand the terms of art I haven’t been in a math class in 16 years and it’s slow going. With Go I was productive in two days and proficient in less than two weeks. Yes I still shoot myself in the foot with channels and race conditions when I’m rushing but at least it’s a super fast compile cycle to iterate and my IDE doesn’t require over 2gb ram like scala / idea does.

Yup being easy to understand without lacking functionality is definitely superior to supporting every insane programming concept. It builds stronger communities and better software

Big ol’ “Citation Needed” on this one.

The flip-side here is that a language that doesn’t support basic programming language theory concepts dooms its users to repeat the mistakes of those who discovered them.

I also would personally disagree that any statically types language without generic types and without non-nullability (e.g. `Option`/`Maybe` and `Result`/`Either`) is severely lacking in the ability to express programs that are easy to understand.

proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the time to get each piece right and I'm glad for it.

Another commenter points out that Go has Google backing it, which is a significant confounding factor in terms of figuring out how good it is on its own merits.

I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineers where necessary.

My issue with pointing to this and calling it “practical” and “easy to understand” is twofold:

(1) Go implicitly makes its ease of understanding dependent on an having existing background knowledge of concepts that the HN crowd is likely to have, themselves, which biases people but isn’t particularly easy to learn on its own merits (versus, say, Python)

(2) Most companies cannot afford to solve engineering problems by throwing more bodies at it, but with Go your option is either that or leveraging external code generation

As far as “taking the time to get each piece right”, this stuff isn’t cutting edge technology development! Go isn’t doing dependent typing or borrow checking or scoped effects!

Everything that people lambast the language over not having is old hat, it’s like defending a car manufacturer who chose to use carburetors over fuel injection by saying that they’re trying to figure out how to do it right.

Practically everything you mentioned is already done better by Java or C#. Not to mention them having advantages that golang isn't even close to solving.

Sorry those just aren't legitimate analogies. As I mention before every feature has a cost, Go is highly concerned with how those costs impact the community. In doing so they have created a language thats highly maintainable and efficient. Even at small companies there is turnover and you being 'really smart' with some abstraction has an impact, I've seen this plenty first hand.

Counterpoint, regarding community: the Rust programming language has a much more vocal, cohesive, and engaged community than Go does in my experience, even though it has a fraction of the corporate backing.

Counterpoint, regarding “reducing the cost of features”: Go is spreading a simplified understanding of what garbage collection performance means to a generation of programmers by providing almost no configuration over their GC settings. I’ve had people say that Go’s GC is obviously the best, without any point of reference with which to compare it.

What Go has done here is pick a reasonable set of trade-offs to make in their garbage collector, hard-code most of these settings into the runtime system, and package that into the philosophy of “configuration is bad”.

Rust has a pretty great community, and I don't think you need corporate backing for a community. I'm just stressing it's one of the most (if not the most) important aspects of a language.

I will say Rust it isn't nearly as easy to enter as Go, that should be somewhat expected by their desired feature set. Likewise, they aren't as concerned with the cost of features as Go is.

I would somewhat agree with the GC stuff, I think having a couple more levers there with sensible defaults is probably ideal.

Adoption isn't everything and google has incredible marketing sway.

Tensorflow almost won the ML framework wars despite being clearly outclassed by Torch and it took until recently for Torch to overcome the Google brand name

Marketing and they understand how to build communities, this is actually the most important thing. TF isn't a great product so thats showing through now, Go and K8s are and you don't see the backtick there.

Go is one of the worst things to happen to the programming community in recent times, truly a 20 year step back that ignores practically everything we have learned about programming.

> Go is taking the time to get each piece right and I'm glad for it.

Have you ever taken a look at the error handling in Go standard libraries? Rob Pike is constantly badly reinventing monadic error handling patterns and doing it wrong; He even admitted to this himself.

O here we go with more canned Go insults. It's actually written by a bunch of old guys that have seen the evolution of programming and made the design for very specific reasons that you apparently can't understand.

Error handling is an active topic of consideration, but I kinda like how it is now.

Have you ever maintained production Scala code? I have and it was an absolute nightmare compared to Go.

A while back i was happily writing clojure, but after a while its dynamic typing got problematic and that's when I learned scala. I really liked it, I think functional but statically typed is the way to go.

Although I still think that it is a lot of fun to write clojure, it's a breeze with its focus on stateless, functional code.

I tried to get into writing a GraphQL API in scala once, and the library made excessive use of the implicit parameters. That was too much for me, there was always something missing and it wasn't immediately apparent where things are taken from or why something doesn't work in one place but does in another.

Does clojure interface well with Java libs?

Yes. Very well. https://www.clojure.org/reference/java_interop

Interested but how much as good as with kotlin? Being compatible is one thing, being as idiomatic is another.

Define idiomatic. As an example, I find myself using the java.time package quite frequently. An example:

    (ns dev.scratch.time-ex
      (:import
        (java.time Duration)
        (java.util Date)))

    (let [from (Date.)
          until (-> from (.toInstant) (.plus (Duration/ofHours 12)) (Date/from))]
      [from until])

Returns a 2-element vector containing two java.util.Date objects, the second twelve hours in the future of the first. Here I'm using Date, Instant, and Duration classes. It's consistent with Clojure syntax (methods being first items in a list), and remembering to use . or / (roughly for instance or static methods) for calling Java methods. Using something like the thread-first macro (->) is idiomatic Clojure, and it's not my goal to convince you that Clojure syntax and style is better, just that Java is immediately and idiomatically available (from a Clojure point of view).

I find very little friction in using Java directly from Clojure code. I can't speak to comparisons with Kotlin as I have no experience using it.

Not sure what you mean. It is idiomatic to not rebuild things Java offers in Clojure and to instead just use interop with Java.

Using Java from Clojure I'd say is as good as Kotlin. Using Clojure from Java isn't as good as Kotlin, but it is still pretty good. Only certain things get messy, like in frameworks where you need to extend a class and override methods to set some behavior. Or frameworks that make heavy use of annotations. Since Clojure isn't OO, doing those are a bit trickier.

> being as idiomatic

yea kotlin prbly is a better choice if you mainly want to use java's libraries and write idiomatic java.

Clojure is not 'better java' like kotlin, its a completely different paradigm.

Nowhere near as good or as seamless as Kotlin interop, Kotlin made interop a priority/first class feature.

When using a Java library in Clojure, many times its just better to just write some Java for your Clojure program specifically for the purpose of calling it from Clojure.

That hasn't been my experience. I've always been able to make use of Java libraries directly from Clojure in a straightforward way. In fact, sometimes I joke it's easier to do Java in Clojure than in Java

Can you describe the kind of situations that you faced issues in?

P.S.: Also, Clojure has first class interop... It's a part of its fudamental design.

In what sort of situations have you needed to write more Java to use a Java library from Clojure? I've never felt the need to do this. It's sometimes helpful to write a Clojure wrapper for a Java library on order to use it in a more Clojure-y way.

From Cursive's author

https://old.reddit.com/r/Clojure/comments/5twabp/new_clojuri...

> When using a Java library in Clojure, many times its just better to just write some Java for your Clojure program specifically for the purpose of calling it from Clojure.

What? Calling Java from Clojure couldn't be any easier. The same as calling JavasScript from ClojureScript

From Cursive's author

https://old.reddit.com/r/Clojure/comments/5twabp/new_clojuri...

Ok, that's fair enough, though one could argue this is about writing new java like code not accessing existing java code.

Reply on news.ycombinator.com