Live data from Hacker News

The Future of Clojure

thoughtworks.com

251–260 of 309 posts

Re: The Future of Clojure

#251
post #6

Earlier quoted context omitted.

Nubank (a Brazilian based startup-style fintech company) does everything with clojure (on AWS). They bought Plataformatec makers of the Elxir lang.

Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.

Why this obvious bait?

Re: The Future of Clojure

#252
post #129

Earlier quoted context omitted.

Clojure has no null safety. You may encounter it less because of the foundational building blocks you use in the language, but NPEs are most certainly there.

Same for Kotlin, really. Can only do so much to stabilize things when you're building your home in a marecage.

There are certainly limits, but null safety doesn't need to be one of them. Typescript does a great job of handling null safety on top of JavaScript.

I don't see any technical reason why Kotlin couldn't have done the same.

Re: The Future of Clojure

#253
One thing that I would like to mention as a Clojure newbie is the community. I am super impressed by how much friendly they are. I mainly use /r/clojure on Reddit and the Clojurians on Slack.

Re: The Future of Clojure

#254
post #247
post #235

Earlier quoted context omitted.

We've switched from Java to Kotlin with Arrow for all our back end work. We couldn't be happier, and we're not impressed with Java's attempts at playing catch-up. "final var" anyone? Non-monadic, non-applicative "Optional"? No? Ok.

I can go fetch similar comments from online archives from every guest language on the JVM, CLR, WebBrowser. The guest languages require additional tooling, duplicated libraries (because just using the platform libs isn't idiomatic, whatever), and then as the platform moves on the seamless FFI stops being so seamless, specially when the guest language decides being a guest language in just one platform isn't enough fo…

Historically, I agree. But this time really is different. No other JVM language has backing or buy-in even remotely comparable to Kotlin, and it's more seamless than any other JVM language I've experienced.

For what it's worth, in case I come off as a die-hard Kotlin fan, I'm really not. I strongly disagree with many choices the designers make with Kotlin - there's too many to list, but the common theme is basically, as good as Kotlin is at discouraging the worst of Java, it still caters far too much to nonsensical Java practices IMO.

Re: The Future of Clojure

#255

Earlier quoted context omitted.

> This is why we see the highest paid practitioners programming exclusively in functional languages Well I don't know how accurate this is, but in 2019 Stackoverflow survey, Clojure practitioners averaged the highest pay of any languages. (in 2020 they removed Clojure from the options so the data is missing). > I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language I…

> Well I don't know how accurate this is, but in 2019 Stackoverflow survey, Clojure practitioners averaged the highest pay of any languages. Well I didn't believe it, but wow: https://insights.stackoverflow.com/survey/2019#top-paying-te... I'm not sure if I should conclude that I'm incredibly ignorant of the engineering market, or that Stack Overflow's survey is not representative. It makes me suspicious that Clojure…

It's interesting too that of the top 5, only Go is a non-functional language, the others all are: Clojure, F#, Scala, Elixir.

Right now my guess is that, if you also look at one of the other questions, it turns out Clojure has one of the highest ratio of senior to junior, like Clojure devs average a higher amount of experience as well. I haven't checked the others like F#, but my guess is that most dev using functional programming languages actively and professionally tend to be more senior and thus command a higher salary mostly. That means there isn't as many junior or mid-levels to skew the average salary down, where as my guess is other languages might have an even bigger number of new devs using them like JavaScript for example, which would skew the salary average towards their pay levels.

Re: The Future of Clojure

#256
post #27

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need…

Hot take: Lisp (including Clojure) is for shitty programmers. Great programmers can be great in any language, including C, COBOL, or BANCStar. Their brainpower alone can compensate for the language's lack of abstractive power. Lisp is a mind prosthesis for the programmer; it extends the programmer's reach. Unless you are working in a complicated, abstruse line of work, you stand most to benefit from this if you are b…

This might be the best advertisement for me picking up Clojure (or Lisp/Scheme) that I've seen so far.

Re: The Future of Clojure

#257

Clojure is a great language for small creative teams to achieve great(relatively) things. It's difficult to understand that from a startup mindset of hacker news where money is no problem and peace of mind is an after thought. If you are a budget constrained individual living in a third world country with nothing to invest but your intellect and time, Clojure is a very good language. It lets you to - 1. Create relati…

How did you get started in Clojure contracting work?

Re: The Future of Clojure

#258
post #178

Earlier quoted context omitted.

Rich Hickey has a bunch of good talks about simplicity, functional programming, and immutability which sort of lays out the ethos behind Clojure, and how it differs from other (primarily object oriented languages), but for me, one of the main appeals is the interactive nature of developing with Clojure. That, combined with the fact that everything is generally made up of simple data structures (lists, vectors, maps,…

> how it differs from other (primarily object oriented languages That includes every major Lisp dialect.

The interactive development is definitely Lisp heritage, but not "simplicity, functional programming, and immutability".

Re: The Future of Clojure

#259
post #53

Earlier quoted context omitted.

Millions of LOC of Clojure project is unheard of; from the article: Nubank has "2.7 million lines of Clojure code [encompassing] several hundred microservices written in Clojure" – the 2.7M is across the entire enterprise . I have an enterprise client right now sitting on 1.5M java 1M SQL 1.5M XML for a single government system that mostly does not function at all , it just gets passed from contractor to contractor,…

A fintech that I am aware of chose Elixir and is a complete shitshow, they're trying to move away from it after being established with it. Can't hire for it, can't refactor the code at scale, etc. Be careful with what you read, newer languages are usually trying to sell themselves where established languages have happy people not trying to sell it, or, resume driven developers trying to sell it as bad.

New languages have green field projects by its very nature feeding the hype.

Re: The Future of Clojure

#260
post #77

Reading the comments I get the impression that Clojure is competing with Java, and it seems that it cannot win against Java, for various reasons, and I am saddened by that. What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)?

> What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)?

I think this sentiment ("Clojure is dying") has kind of become a Hacker News meme at this point.

Clojure basically came out of nowhere and pretty much displaced all other Lisps in about a decade. It is definitely not dying, it's just an opinionated, fairly niche language - it's not Go or TypeScript. It solves certain problems well and has some uses where it really shines. It's not a silver bullet, though, and it definitely requires serious learning/unlearning to get really good at it if all you know is the mainstream imperative/OOP style.

Clojure works well for those who buy its rationale: https://clojure.org/about/rationale

Post reply on HN