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

291–300 of 404 posts

Re: Try Clojure

#291

Post by didibus »

pjmlp wrote: post #277
didibus wrote: post #236

Earlier quoted context omitted.

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.

Can you talk more about these?

Re: Try Clojure

#292

Post by DeathArrow »

I wonder why no functional language has the degree of success imperative or OOP languages have.

Is functional programming too weird for majority of computer programmers? Is functional programming not optimal for solving industry problems? Maybe there is no functional programming that that is up to some set of standards? Is functional programming too complicated?

I do enjoy functional programming myself, and while I don't use a functional programming language at work, I try to use functional programming paradigms when I finds it suits the probem.

Re: Try Clojure

#293

Post by hpeter »

BaculumMeumEst wrote: post #223

Clojure is a really interesting and well designed language with bad error messages and bad official tooling. It feels very sloppy. Compared to Go, it has a weak stdlib, is more memory intensive, and generally slower. You get beautifully concise code but it can be very hard to follow (or return to after time away). Go can look completely idiotic or unbelievably focused and practical, depending on the light. It is pain…

"weak stdlib": You can use the Java ecosystem, most of the things you need are there

"it can be very hard to follow": I agree, if you are not a lisp developer it's really hard, but if you develop clojure everyday, it's as easy as anything else.

The answer is usually clean code when it comes to clojure. Keep your functions small.

"more memory intensive, and generally slower": yep, the JVM is more memory intensive than Go. No surprise there and Clojure adds up on top of that. Startup times are pretty slow too. But compared to python it's still fast. Apples to oranges.

I would say Clojure and Go are both great languages that tackle different problems so it's not a fair comparison.

Re: Try Clojure

#294

Post by pron »

geokon wrote: post #237
pron wrote: post #190

Earlier quoted context omitted.

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 ?

That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.

Re: Try Clojure

#295

Post by pron »

kamaal wrote: post #224
pron wrote: post #190

Earlier quoted context omitted.

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…

>>The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. Im yet to reach the X-men level super qualities that can detect, and work in 40 ms chunks. Or at least even notice a 40 ms delays. I envy the humans who can notice such small chunks of time.

Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.

Re: Try Clojure

#296

Post by cageface »

DeathArrow wrote: post #292

I wonder why no functional language has the degree of success imperative or OOP languages have. Is functional programming too weird for majority of computer programmers? Is functional programming not optimal for solving industry problems? Maybe there is no functional programming that that is up to some set of standards? Is functional programming too complicated? I do enjoy functional programming myself, and while I d…

Functional programming languages haven't gone mainstream but functional techniques are very common now.

Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

Re: Try Clojure

#297

Post by ReleaseCandidat »

nine_k wrote: post #171
ReleaseCandidat wrote: post #89

Earlier quoted context omitted.

I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).

That's cool! How do you manage? E.g. the `if err != nil { return err; }` stuff?

Well, in the context of Lisp, `err != nil` is equivalent to Lisp's parens: if somebody complains about that, chances are their critique is superficial (and there are enough "real" problems when using Go, especially when using goroutines and channels). The amount of low abstraction Go code I write is compensated by the amount of "abstraction boilerplate" like implementing type classes by myself or letting the compiler derive, implementing newtypes, adding GADTs, adding Pattern Synonyms and Type Families to be able to comfortably use the GADTs without much boilerplate and so on. Rust adds for example the need for associated types and is generally more verbose than Haskell.

I do not see a significant difference in the amount of boilerplate needed for catching exceptions, pattern matching or branching on the existence of an error value. Nobody can stop you from implementing `bind` in Go for your error (which I did in some places), but of course Rust "wins" with its `?`.

Re: Try Clojure

#298

Post by nXqd »

vaylian wrote: post #256
kubb wrote: post #90

Earlier quoted context omitted.

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…

> 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 reasoning. How does this affect readability when one tries to dive into an existing Go project? Is Go code harder to navigate than code in more expressive languages?

We shouldn't overestimtae the complexity of expressive language like Clojrue vs Go. Go is perfectly simple and easy to follow, even compared with Clojure. If you come from background of Computer Science or programming first, Go is easier to follow.

Re: Try Clojure

#299

Post by [deleted] »

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

[deleted]

Re: Try Clojure

#300

Post by ReleaseCandidat »

nine_k wrote: post #166
chuckadams wrote: post #104

Earlier quoted context omitted.

While I share your perspective on go, I do prefer developing in a bottom-up way myself: I just do so with the intent of iterating my way to a higher level abstraction. Sometimes I see the abstraction right away and start with it, but I don’t want a language that gets in my way in either direction.

A Lisp (like Clojure), or Haskell are great for playing around with things and developing bottom-up. I did just that for a day job sometimes. Of course, I then had to translate that to Python or TS, but once an idea is understood and tried, it's not such a big deal.

That's interesting, for me Lisps, Python or TS (or Go) are great for playing around with things and developing bottom-up. And then I translate that to Haskell (or Rust or C++ or Go).
Post reply on HN