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

271–280 of 404 posts

Re: Try Clojure

#271

Post by fire_lake »

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…

Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.

Re: Try Clojure

#272

Post by createaccount99 »

ilikehurdles wrote: post #265
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.

No. When working with JVM/typescript libraries you have their autocomplete information. If you need method autocomplete scoped to a type you can use the `..` macro for more concise call syntax: (ns my-project.core (:import (java.util ArrayList Collections))) (defn example [] (let [list (ArrayList.)] ; ArrayList constructor can be autocompleted (.. list (add "Hello") ; The .add method on ArrayLists will be autocomplet…

That's cool, I had no idea. In clojure itself I suppose you eval code and then get autocompeletes from the repl output? -- I mean for stuff with no types

Re: Try Clojure

#273

Post by nathants »

createaccount99 wrote: post #269
nathants wrote: post #259

the best reason to learn clojure is reagent[1], by far the best way to use react. shadow-cljs[2] makes using npm libraries easy. i’ve settled on go backends and reagent frontends as my default setup[3]. 1. https://reagent-project.github.io/ 2. https://github.com/thheller/shadow-cljs 3. https://github.com/nathants/aws-gocljs

Does your setup do code splitting, SSG? I can't really be shipping a blank html file in 2024, destroys SEO. Otherwise am interested in trying.

no, i’m not interested in seo.

this setup is a single go binary that serves a single pre-gzipped html file from a lambda.

that html file contains inlined js, that is a reagent app.

there is also a favicon. total of 3 files in the lambda zip.

you desired setup is certainly possible though. you’d probably want clojure on the backend though, so you could more easily do SSG.

Re: Try Clojure

#274

Post by pjmlp »

nine_k wrote: post #131
a_wild_dandan wrote: post #92

Earlier quoted context omitted.

I must use PyTorch for ML, but badly wish I could use TypeScript instead. Its type system demolishes anything else I've used. Writing anything from SPI communications, to server logic, to rich GUIs is a breeze. Then I work in Python and have to fight `Any`s, ambiguous arguments, more verbose code, and bizarrely slow run times. It makes me sad.

While I agree with you, Python is getting better in this regard, as is mypy. Making historical interfaces well-typed is another kettle of fish. For instance, Python's range() is actually two overrides with incompatible signatures. I bet PyTorch has more of such examples.

If it only had a V8 class JIT in the package as well.

Re: Try Clojure

#275

Post by pjmlp »

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 problem lies with Clojure implementation, not Java or the JVM.

Re: Try Clojure

#276

Post by nXqd »

kubb wrote: post #90
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…

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasonin…

I do switch between Clojure and Rust depends on the problems I solve at hands ( prototypes vs building production ). And yes I need go through my checklist of each to switch from connecting data flows at high level to examine nuts and bolts at low level.

Re: Try Clojure

#277

Post by pjmlp »

didibus wrote: post #236
koito17 wrote: post #168

Earlier quoted context omitted.

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 caus…

The various JVM implementations have mechanisms to fix that, like JIT caches and AOT compilation, which Clojure doesn't take advantage of.

So it is indeeed a Clojure issue, not a JVM one.

Re: Try Clojure

#278

Post by ziftface »

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.

Autocomplete works for me with jvm imports

Re: Try Clojure

#279

Post by simongray »

createaccount99 wrote: post #272
ilikehurdles wrote: post #265

Earlier quoted context omitted.

No. When working with JVM/typescript libraries you have their autocomplete information. If you need method autocomplete scoped to a type you can use the `..` macro for more concise call syntax: (ns my-project.core (:import (java.util ArrayList Collections))) (defn example [] (let [list (ArrayList.)] ; ArrayList constructor can be autocompleted (.. list (add "Hello") ; The .add method on ArrayLists will be autocomplet…

That's cool, I had no idea. In clojure itself I suppose you eval code and then get autocompeletes from the repl output? -- I mean for stuff with no types

Autocomplete also works for the functions and vars in the namespaces. You don't really use methods in Clojure unless you're doing interop with Java or JS.

Re: Try Clojure

#280

Post by simongray »

askonomm wrote: post #7
hombre_fatal wrote: post #6

Earlier quoted context omitted.

Oh, interesting. Yeah, that's even better for an onboarding tutorial. I didn't know it existed (used Clojure for 6 years a long time ago). Cool: https://shaunlebron.github.io/parinfer/ I always thought that the surrounding tooling (having to learn how to edit parens productively, using nrepl/cider, maybe even emacs... with evil-mode of course) to be both the worst and then eventually the best parts of Clojure.

I'm one of those mainstream devs (who also did Clojure for 6 years, coincidentally) who never got into emacs, and always just used the Cursive IDE plugin for IntelliJ and its Parinfer editing mode. I know I probably didn't unlock true god mode of productivity, but it worked fine for me.

I'm the same, always just used parinfer with IntelliJ, though I do know a few paredit key combos that I use occasionally (paredit isn't disabled just because parinfer is enabled).
Post reply on HN