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

281–290 of 404 posts

Re: Try Clojure

#281

Post by pjmlp »

derefr wrote: post #173
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.

I think, in a lot of cases when people still complain about "the slow startup time of the JVM", they're really just talking about how the big JVM GUI apps (like IDEs) struggle to get started on heavily-loaded systems. And this, I think, is mostly just due to these apps eagerly reloading the most recent workspace on startup, and so pre-allocating big chunks of memory on startup to be ready for that — which can ripple…

They are working with PGO, and adding also AI based optimization algorithms, both can help.

Re: Try Clojure

#282

Post by cospaia »

createaccount99 wrote: post #258

The problem I see with clojure, isn't it missing autocompletes? You work with JVM/typescript libraries, but your editor isn't smart enough to pull types from those into clojure. That slows you down tremendously.

As a Clojure editor tool smith it pains me that this is the case. Especially for ClojureScript where I spend most of my time. I really want to fix this.

For JVM interop, I think Cursive (IntelliJ Clojure plugin) is smart enough to help with autocompleting Java libraries.

Re: Try Clojure

#283

Post by pjmlp »

didibus wrote: post #239
paulddraper wrote: post #214

Earlier quoted context omitted.

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?

Those other runtimes also don't do half of the features a JVM usually has to offer, and most people complaining also don't bother to actually learn the Java ecosystem, the existing set of JVM implementations, and the optimizations features made available to them.

Re: Try Clojure

#285

Post by fire_lake »

zarathustreal wrote: post #128
neilyio wrote: post #83

Earlier quoted context omitted.

And when you're ready to take the fun to the web, look no further than Biff: https://biffweb.com

I love this so much. The power of being able to connect a repl to your production instance and fix bugs instantly is hard to understate. It’s actually kind of hard to explain to devs used to deployment cycles measured in weeks

How is the fix committed once you are done? Does this run counter to immutable deployments?

Re: Try Clojure

#286

Post by ungamedplayer »

neilyio wrote: post #189
hi-v-rocknroll wrote: post #188

Earlier quoted context omitted.

Ah neat. But darn, I was kinda hoping for supporting tools and packages with names like tannen, delorean, doc, mcfly, and strickland ;)

It features a time-travel database, if that helps! https://biffweb.com/p/xtdb-compared-to-other-databases/

I don't know if op had chance to evaluate because they were outatime.

Re: Try Clojure

#287

Post by didibus »

winrid wrote: post #211
rads wrote: post #195

Earlier quoted context omitted.

In practice I do wrap `jdbc/execute!` with my own `execute!` function to set some default options. However, there is no ORM layer. What makes you think the code above is terribly unproductive? Edit: Not trying to dismiss your concerns, by the way. In Clojure you can often get away with doing less than you might think so I'm genuinely curious about the critique.

In Django I would just do Posts.objects.filter(title=x) I don't need to define driver boilerplate for every query (or ever have to write it... at all).

In Clojure you'll have to write the queries yourself unfortunately. People always ask, where is the fully fledged web framework in Clojure? There isn't one. Why there isn't one is hard to answer, but it's partially because the people who could write one, don't find they need one themselves.

There's definitely a preference in Clojure for not relying on frameworks, because the current people in the community like to be in control, know what's going on, or do it their own way.

That said, the whole code still ends up being relatively small. So, you kind of end up with a similar amount of total code, but you're much more in control. And if certain things you find too repetitive, you can remove the repetition yourself through many of Clojure's facilities, specifically where they annoyed you.

See: https://github.com/didibus/simple-website-with-posts where I implemented the small website you were talking about, creating posts and seeing them. The whole code is here (minus the CSS): https://github.com/didibus/simple-website-with-posts/blob/ma...

It's 95 loc and that includes the templates. There's no framework.

Re: Try Clojure

#288

Post by BaculumMeumEst »

nine_k wrote: post #79
jakebasile wrote: post #67

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on. I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-lik…

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things…

Writing Go is less fun but the language has far better tooling, dead simple deployment, lower memory usage, generally higher performance, and is easier to onboard new developers. Also I find it way easier to read old projects after time away.

You can get incredible mileage out of Go using just the stdlib, built in tools, and the pure go port of SQLite. With Clojure it feels like I have to stitch a million random libraries together to get anywhere. Writing Clojure is delightful but the ecosystem and tooling pale in comparison, and at the end of the day I think that’s what matters.

If Clojure had great built-in tooling, better error messages (and maybe some SBCL-esque type checking features), and if Datomic was open source and less rough around the edges, I think the language would have been far more successful.

Re: Try Clojure

#289

Post by ReleaseCandidat »

nine_k wrote: post #124
ReleaseCandidat wrote: post #115

Earlier quoted context omitted.

I'm actually surprised Go's tooling as as good as it is _although_ it is made by Google. But to be fair, GoogleTest is OK too.

Google has produced a number of quite good tools. See also Bazel, for instance. During my time there, I was genuinely impressed by the quality of many of the internal tools. E.g. it took GitHub code review tools a long time to get on par with Google's internal code review tools from 2015.

> Google has produced a number of quite good tools.

"Quite good" is exactly the wording that I would have used too. But Go's tooling is _really_ good; the language itself is, well, "quite good". And is still supported and actively developed!

Re: Try Clojure

#290

Post by ErikCorry »

cess11 wrote: post #97
nine_k wrote: post #79

Earlier quoted context omitted.

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things…

Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions. To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm m…

These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane.

If you are making JavaScript look good you are failing as a language.

Post reply on HN