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

Try Clojure

tryclojure.org

Post reply on HN
Print view View original

231–240 of 404 posts

Re: Try Clojure

#231

Post by puredanger »

joshlemer wrote: post #209
masspro wrote: post #40

My Clojure experience was that basic dev experience things were shockingly behind where any other moderately popular lang is at. It's been some time though so all I remember clearly is bad error output. Stack traces are hard to read unless you install $random_lib. But worse than stack traces are type errors/"Java errors": if you give the wrong args to a function, the error output is completely inscrutable, generally…

Along the same lines with the docs, I also find it frustrating that a lot of the very most core basic abstractions and interfaces are left totally undefined in terms of documentation. Take `ISeq`'s definition. Surely, a candidate for the single most core interface. https://github.com/clojure/clojure/blob/master/src/jvm/cloju... But like, where is the javadoc? What exactly is supposed to be the contract of these metho…

You don’t use the ISeq interface directly, you use them through the clojure.core API. The seq abstraction is documented at https://clojure.org/reference/sequences

Re: Try Clojure

#232

Post by iLemming »

zug_zug wrote: post #107
xyzzy4747 wrote: post #48

I'm happy with TypeScript, Go, and Rust. Don't feel like learning anything else.

I'm with you. I'll even go a step further, since I haven't heard anybody else say this: My hot take -- There are already too many programming languages in use and every engineers life would be easier and productivity would be higher if we standardized. There is almost no situation where making an entirely new language is the optimal solution. And the worst reason of all to make a language is anything aesthetic (e.g.…

If we were forced to use only selected, most popular languages to communicate and ban all others, everyone would have to speak Mandarin, Spanish, and English. And the world would never know the Quran, the Bible, Arabian Nights, the Epic of Gilgamesh, War and Peace, the Ramayana, or the Divine Comedy.

There are some good examples of applications that are specifically written in Clojure and would be quite difficult to replicate in other PLs - Roam Research and Logseq, XTDB and Datomic, Nextjournal and Precursor.

> And the worst reason of all to make a language is anything aesthetic

Interestingly, people avoid learning Lisp, because it doesn't look "sexy enough" the first time they see it.

Re: Try Clojure

#233

Post by iLemming »

throwaway96666 wrote: post #135
macintux wrote: post #95

Earlier quoted context omitted.

Programming without immutability is so painful to me, no matter how many functional features a language adds.

In my experience jumping from a Clojure shop to a large Java shop a few years ago, the benefits of persistent data structures are overstated. Mutable collections are just as good for 99% of use cases. And they're a lot faster (in single threaded code) and occasionally mutation makes things easier. The selling point of Clojure is that persistent data structures prevent several classes of bugs (unintended mutation, loc…

> the benefits of persistent data structures are overstated.

Well, what else is overstated?

- Structural editing? Fine.

- REPL-driven development? Okay, let's throw that out the window.

- Hosted nature and the interop? Gone.

- Destructuring? Eh, we kinda have it in Javascript, right?

- Concurrency support? Who needs that shit, anyway, right?

- Simplicity and elegance? Arguable. Some like verbose Typescript code more.

- Functional programming? What the heck is it even?

The point I'm trying to make is that you can't just "remove" an essential part of what makes a language. Rich Hickey took a year-long sabbatical (or was it two or even three years? I forgot) and used his savings to get this aspect of the language right. Without the immutable collections, the language would've been an entirely different beast.

Re: Try Clojure

#234

Post by android521 »

Clojure will get more adoption if they find a way to make it very easy to build cross platform mobile and web apps like React & React native. They need to keep adding libraries to make the eco-system bigger.

Re: Try Clojure

#235

Post by didibus »

pron wrote: post #190
amelius wrote: post #151

> unlike full-JVM Clojure it has a very fast startup time I can't believe that after all these years Java still didn't fix their startup time.

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state. [1]: E.g. see htt…

You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.

Re: Try Clojure

#236

Post by didibus »

koito17 wrote: post #168
rtpg wrote: post #156

Earlier quoted context omitted.

My understanding is that this isn’t really a JVM thing, but I might be wrong.

Your understanding is correct. JVM startup accounts for a small portion of Clojure's startup time.[1] Most of the overhead is in compiling and loading clojure.core. Efforts have been made to remedy this issue[2] (e.g. direct linking, ahead-of-time compilation, ...), but this doesn't remove the fact that clojure.core is huge and virtually any Clojure program will be importing more than just clojure.core, so there is s…

Well, it's still partially the JVM at play. For example, if your application has big classes, and many classes, the JVM will be slow to start. This is what is happening here. Clojure is like a large-ish Java project, it has big classes, and many of them, with static initializers, that need loading at the start, and the JVM does all that slowly.

In some sense it's Clojure's fault for having an implementation that causes slow JVM startup, but it's also the JVM's fault that the way Clojure uses it causes it to take a long time to start.

Re: Try Clojure

#237

Post by geokon »

pron wrote: post #190
amelius wrote: post #151

> unlike full-JVM Clojure it has a very fast startup time I can't believe that after all these years Java still didn't fix their startup time.

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state. [1]: E.g. see htt…

Why can't you do some JVM equivalent of memcopy/execve the starting state of the program?

Isn't the initialization procedure (or at least the vast majority of it) exactly the same at each run ?

Re: Try Clojure

#238

Post by geokon »

neilyio wrote: post #158
amelius wrote: post #151

> unlike full-JVM Clojure it has a very fast startup time I can't believe that after all these years Java still didn't fix their startup time.

When you get into REPL-driven development, the JVM startup time (which is often under a second for me anyways) is a total non-issue. You don't continuously restart your program to see changes or run tests. You can refresh all your state instantly without exiting. But before Babashka, that was indeed a barrier to using Clojure in shell scripts. Now we have it all!

Except in Babashka you can't use Java libraries.. Right?

I feel a good fraction of code will dip into Java libs at least a bit - so you're limited in what libraries you can use

I think the real solution is probably Graal native - though it's not part of the official toolbox/deps.edn

Re: Try Clojure

#239

Post by didibus »

paulddraper wrote: post #214
amelius wrote: post #151

> unlike full-JVM Clojure it has a very fast startup time I can't believe that after all these years Java still didn't fix their startup time.

It's not the JVM. It's how much code you load.

I mean... That's not an issue in other runtimes, so it's kind of a JVM quirk no?

Re: Try Clojure

#240

Post by zug_zug »

ekzy wrote: post #184
zug_zug wrote: post #107

Earlier quoted context omitted.

I'm with you. I'll even go a step further, since I haven't heard anybody else say this: My hot take -- There are already too many programming languages in use and every engineers life would be easier and productivity would be higher if we standardized. There is almost no situation where making an entirely new language is the optimal solution. And the worst reason of all to make a language is anything aesthetic (e.g.…

https://xkcd.com/927/

I'm not sure if you meant this as evidence for or against my point, but this is exactly what I mean.

Every year dozens of people think they're going to make some holy-grail language and it's 1% different from the prior version but now every single library needs to be rewritten, a dozen years of patches/bugs/security-holes must happen, whole resumes get shined up rewriting tech stacks that were perfectly capable, all for it to be thrown for the next shiny toy in less than a decade.

A new language just fractures knowledge.

Post reply on HN