Live data from Hacker News

Bringing Clojure programming to Enterprise (2021)

blogit.michelin.io

131–135 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#131
post #110
post #42

Earlier quoted context omitted.

understood, i'm just pointing out that people seem to prefer the apple over the orange.

> i don't think you're wrong necessarily...but rust, golang, zig, mojo, etc are gaining popularity and imo they wouldn't be if they were JVM languages. > understood, i'm just pointing out that people seem to prefer the apple over the orange. This is kind of like saying that fewer people are drinking Coke every year and are choosing other beverages. It might be objectively true but it glosses over the fact that litera…

> Developers on HN using zig, mojo, etc. aren't really a representative sample.

Agree. A lot of manipulation and astroturfing goes on, from many different groups, that affects what appears to be popular on a particular site. The bubbles formed at a site can become self-reinforcing.

The more time one spends at a particular site, the more likely to fall for the illusion or become to believe that what is being presented, is representative of everyone or everywhere else. Kind of like if a person only watches Fox News or PBS News.

Re: Bringing Clojure programming to Enterprise (2021)

#132
post #44

Earlier quoted context omitted.

Sure that index isn't great (I think it's basically a regurgitation of Google Trends), but I don't think you're suggesting Clojure is actually a popular language are you? Which is the only point I'm trying to make (that it isn't popular).

Clojure is reasonably popular as far as programming languages go. It's not difficult to get a job as a Clojure developer, particularly in certain sectors (fintech and healthcare are the heaviest Clojure users). Of course C++, Java, C# and PHP dwarf both Clojure and Rust by several orders of magnitude.

> It's not difficult to get a job as a Clojure developer

Let's be honest and avoid painting a misleading picture. Getting a job as a software developer of any kind is genuinely difficult right now. Finding a position on a Clojure team has always been relatively harder for various reasons - and not simply because of its [in]popularity.

Clojure tends to attract older, more experienced developers. If you want a full-time Clojure role but have no prior experience with it, you'll often need to accept a junior-level salary - something many seasoned developers can't afford or simply won't do.

Junior developers have it even harder. Recruiting pipelines don't really distinguish between experience levels - everyone goes through roughly the same process, and juniors are expected to keep up with veterans, with almost no room for error.

Senior, battle-tested Clojure devs face a different kind of pressure. Interviews are frequently grueling, mentally exhausting sessions comparable to architect-level evaluations in other places. And because Clojure enables small, skilled teams to accomplish a lot, companies rarely need to hire in bulk - so competition for each opening is fierce.

This creates a frustrating situation for everyone, companies included. They want top-tier talent but offer junior salaries, while simultaneously rejecting juniors and anyone without direct Clojure experience. Supply and demand are badly out of balance.

That breeds resentment - "why bother learning it if I'll never get hired?" Honestly, there's no clean answer, and Rust seems to be in a similar spot right now. Even so, the language is worth learning. It has real practical value, even when you're not using it on a team. The future-proof choice I believe is to learn both - Rust and Clojure. Exploring both of these languages, I can honestly think things will change in their favor. Unless you want to stay sad at nearly-burnout levels for the next decade or more with TS/Python/Java/etc.

Re: Bringing Clojure programming to Enterprise (2021)

#133
post #116
post #97

Earlier quoted context omitted.

It’s not true, unless you have an unusual definition of “syntax”. Lisp basically has the most minimal syntax possible, by design. To use the right words: it’s not a syntax issue, it just looks unfamiliar to you.

minimal and simple is not the same thing as easy to use and natural/obvious. what looks easier to read: (if ( or if a to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read…

I think by the same reasoning Qwerty keyboard is better than Dvorak. People are just used to Qwerty, although they would type faster on Dvorak, or in the case of s-expressions use structural editing.

Re: Bringing Clojure programming to Enterprise (2021)

#134
post #30

Earlier quoted context omitted.

The JVM is one of the major selling points of Clojure. You can "write once, run anywhere" and benefit from Java's massive ecosystem, all without having to use a Blub language. Modern JVM implementations are also incredibly fast, often comparable in performance to C++ and Go.

i don't think you're wrong necessarily...but rust, golang, zig, mojo, etc are gaining popularity and imo they wouldn't be if they were JVM languages.

Scala and Clojure were smart to ride the JVM early on. Babashka and Jank are Clojure breaking out of the JVM.

Re: Bringing Clojure programming to Enterprise (2021)

#135
post #14
post #4

It's good to read that Clojure is getting more and more exposure. I write Clojure fpr my day job and wouldn't want to swap it for anything. The community is small but very helpfull and easy reachable. The learning curve is steap indeed, but very much worth it!

Clojure has some pretty big downsides last i looked: - syntax is hard to read unless you spend a lot time getting used to it - convention for short var names makes it even harder - function definition order makes it even harder - too dynamic for most people's taste - no type safety - the opposite of boring - no clear use case to show it clearly beating other languages - niche with small community and job market - JVM…

* Hot deploy

* Extreme thread-safety, better than all JVM languages and on par with the best.

* Macros - Other languages you have to reach for other languages to program in other paradigms, for example rules, logic programming, or writing a custom DAG. You'll probably say you don't need other paradigms whereas the truth is you just avoid it in other languages as it's too much of a hassle.

Post reply on HN