Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Clojure

thoughtworks.com

Post reply on HN
Print view View original

161–170 of 309 posts

Re: The Future of Clojure

#161

Post by robertfw »

oftenwrong wrote: post #138
throwaway92938 wrote: post #48

Earlier quoted context omitted.

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in…

I prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. I feel like I am continuously looking for a better alternative, but it's ha…

> the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets

This is a great feature of Clojure, being able to access all of the benefits of the Java ecosystem and the zillions of hours invested into it.

There may not always be a ready-made Clojure wrapper over libraries, but the java interop tools are excellent and writing your own interface into a library is usually quite straightforward.

Re: The Future of Clojure

#162

Post by zonotope »

oftenwrong wrote: post #138
throwaway92938 wrote: post #48

Earlier quoted context omitted.

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in…

I prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. I feel like I am continuously looking for a better alternative, but it's ha…

> I prefer functional programming, and have a background in functional programming, but I still primarily work with Java... In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets.

It sounds like Clojure is perfect for you then. You have all the upsides of Java you mention here with Clojure because it's hosted on the JVM (among other platforms). You can use Java libraries and SDKs seamlessly from Clojure, but the language itself was designed specifically for a functional style from the beginning.

Re: The Future of Clojure

#163

Post by mumblemumble »

st3fan wrote: post #132
talkingtab wrote: post #43

This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.

"each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself" Weird - what is so problematic about installing a JVM? That is literally an apt-get or install away. If you are learning Clojure then installing the JVM should be the least of your problems. Note that there are a bunch of really nice Clojure starter kits available. And now many options for editors. For learning you don't n…

I use Java professionally, and it's a factor in why I recently decided to look away from Clojure and pick a different after-hours language.

The problem for me is the JVM itself. I don't like all the excess complexity that comes from its unsurpassably enterprise-grade level of configurability. I don't like being trapped behind a distressingly awkward FFI. I don't like being required to adjust control levers for aspects of memory usage I'd rather be automatic, while simultaneously having little ability to control the aspects of memory usage that matter to me. I don't like having Java's half-baked type model hiding just under the surface no matter what language I choose, just waiting for a chance to jump scare me. et cetera.

Don't get me wrong, other platforms have their problems, too. Oftentimes they're even more of a headache. But at least they're different headaches. Yes, I like to program for fun, but that doesn't mean I don't like a change of pace on the weekends.

Re: The Future of Clojure

#164

Post by pjmlp »

mumblemumble wrote: post #116
newcrobuzon wrote: post #107

Earlier quoted context omitted.

> Sun spent like a billion dollars marketing Java I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective. It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might…

> And all that just by selling some cheap cut syntax sugar on the corner. I suppose you could dismiss a lot of what Kotlin adds as mere syntactic sugar. But it also makes some much more fundamental improvements. It provides a much cleaner, unified, object-oriented type system. It provides about as sane an approach to null safety as is possible on the JVM. (Clojure's is arguably better, but I'll concede that nil punni…

Kotlin now has a new master and needs to decide how much they want to innovate on the JVM or keep the language compatible with ART capabilities and Android libraries.

KMM can only help so much, specially when all the big Java projects are all integrated into stable releases.

Re: The Future of Clojure

#165

Post by pjmlp »

novok wrote: post #160
oftenwrong wrote: post #138

Earlier quoted context omitted.

I prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. I feel like I am continuously looking for a better alternative, but it's ha…

I think java as a language is fine, it's all the java culture around it that makes it bad. Kotlin is a big improvement and I think it will eventually become the next java in java codebases as it expands out of the android world.

Nah, it will just fade away as Java adopts all features that are relevant to most of us.

If Oracle, IBM, Microsoft, Azul, Amazon bring a KVM written in Kotlin, then I might consider it.

In the meantime it is just the language Android team is pushing to get rid of Android Java, while the offices next door are pushing ChromeOS/PWAs and Fuchsia.

Re: The Future of Clojure

#166

Post by ska »

nanomonkey wrote: post #81

It's interesting to see so many people complain that it's hard to hire Clojure engineers, when I've had the exact opposite problem...trying to find a Clojure shop to join. They are few and far between, and the few that are hiring say that they will take folks that are new to Clojure, but then are baffled when you don't know how to idiomatically solve whiteboard problems. Clojure remedies all of my problems with previ…

  > It's interesting to see so many people complain that it's hard to hire Clojure engineers, when I've had the exact opposite problem
Both can easily be true at the same time. Just because there are people looking for language X jobs, and companies looking to hire X developers, doesn't mean they are a good match. It's a bit like a liquidity problem, having more positions and more candidates in a market helps them all shuffle around to find a good "fit".

Re: The Future of Clojure

#167

Post by puredanger »

st3fan wrote: post #129
mumblemumble wrote: post #116

Earlier quoted context omitted.

> And all that just by selling some cheap cut syntax sugar on the corner. I suppose you could dismiss a lot of what Kotlin adds as mere syntactic sugar. But it also makes some much more fundamental improvements. It provides a much cleaner, unified, object-oriented type system. It provides about as sane an approach to null safety as is possible on the JVM. (Clojure's is arguably better, but I'll concede that nil punni…

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.

NPEs exist but I probably go months or even years between encountering them. Most Clojure functions are polymorphic on nil and provide safe default behavior. You primarily encounter them when invoking Java APIs via interop.

Re: The Future of Clojure

#168

Post by lgessler »

jimbokun wrote: post #152
lgessler wrote: post #79

Earlier quoted context omitted.

I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.

Which is why hospitals really shouldn't be writing software. And why, as a developer, you want to be working for a software company where your work is generating revenue, not somewhere where you are a cost to be cut.

Whether software falls short of our aesthetic sensibilities doesn't have a bearing on whether it's wise for companies to be funding it.

Re: The Future of Clojure

#169

Post by puredanger »

randompwd wrote: post #146
puredanger wrote: post #86

Earlier quoted context omitted.

I use Clojure because I am not a particularly wise programmer (I have been fortunate to work with many actually wise programmers). I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantic…

I'm still salty about Specter[0] not being ~officially recognised as a necessity when using Clojure. [0] https://github.com/redplanetlabs/specter Data driven languages need simple & powerful transformation libraries. `get-in` is repetitive and tiresome to use. Specter and it's ilk make transformations clear and simple. No amount of planning or foresight negates the need for data transformation libraries.

Well, it's not a necessity, and it exists a library that anyone can use, so I don't understand any reason to be salty.

Re: The Future of Clojure

#170

Post by lgessler »

paultopia wrote: post #38
keithasaurus wrote: post #32

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then…

Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refug…

I'm surprised to hear you had such a bad experience with mount--it's always struck me as one of the greatest exemplars of what Clojure allows you to do that would be impossible in Java. Managing fundamentally stateful components was always a nightmare for me in Java and Java-related languages: you'd never know which class was in charge of initializing what, would always be tearing your hair out trying to keep track of when you can assume certain components have been successfully initialized, etc.

With mount on the other hand, you tell it how to start and stop the component (and stores a reference to the component in the same var where you specified this), keeps a reference to the component in exactly one place, and then it automatically makes some reasonable assumptions about the order in which they need to be initialized, while allowing you to opt out as needed. Re: your example of finding a reference to the db, shouldn't it just have been in the var set up by a call to `defstate`? (Also, which web framework was it? Luminus?)

Post reply on HN