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

My thoughts after using Clojure for about a month

acdw.net

Post reply on HN
Print view View original

181–190 of 204 posts

Re: My thoughts after using Clojure for about a month

#181

Post by pdimitar »

zbentley wrote: post #180
pdimitar wrote: post #179

Earlier quoted context omitted.

Thank you. As a guy who made a career out of Elixir (and begins to regret it recently but oh well) I agree that Elixir's throughput is not amazing. However, it can get very far and we should always optimize for the most common usages. I've personally rewritten one hobby and one professional projects from Elixir to Golang and loved the result; as you said, extremely difficult to bring down a Golang service to its knee…

> I did witness it brutally murder a MySQL cluster because it couldn't serve it fast enough. That was both fun and terrifying to watch on the dashboards. Haha yep. In my experience, everyone running CGI/process-per-request application servers is bullish on switching to a concurrent or cooperative runtime...until they realize they just removed the primary ratelimiter on downstream DB/service accesses. The converse war…

Oh yeah, definitely. If your DB server (or any storage backend) cannot have like 200+ connections alive at all times then it's absolutely pointless rewriting your app in Elixir or Golang. You'll just serve DB timeouts in your responses.

Re: My thoughts after using Clojure for about a month

#182

Post by iLemming »

pdimitar wrote: post #6

With respect, this topic in particular has been beaten to death. I too liked Clojure when I tried it some years ago (agreed on the composition and data structures; both are _great_). But the real value-add is in the runtime, not the syntax. Java has a solid runtime but it's not yet as good as Erlang's, maybe even not up to the standards of Golang -- I am talking concurrency / parallelism here (for memory management I…

[flagged]

Re: My thoughts after using Clojure for about a month

#183

Post by pdimitar »

zbentley wrote: post #171
whaleofatw2022 wrote: post #78

Earlier quoted context omitted.

BEAM threads are kinda magicsauce tho, instructions have a cost and after a certain cost total (quantums) the scheduler can divert to another virt thread to guarantee forward progress. Also the immutability rules etc make it easier to optimize this switching.

Eh, reduction counting isn't magic. Golang manages similar preemption semantics without counting that many operations (some tight loops do have barriers inserted every so often, but that's the exception and not the rule). And reduction counting has some serious costs! It slows the runtime down a shitload (and the BEAM is already in the bottom half of interpreted language runtimes by speed) and makes lots of JIT-flavo…

These are all true and I have recognized those as innate limitations of the BEAM VM. For now I am OK with those but I am already skirting at the limit and I am starting to want to jump to Golang and Rust again.

Re: My thoughts after using Clojure for about a month

#184

Post by midnight_eclair »

zbentley wrote: post #176
midnight_eclair wrote: post #108

Earlier quoted context omitted.

from experience, during bursts it's never actual web/api server that is bogged down, it's the downstream io bottlenecks. if your accepting layer is abstracted away and implemented correctly, there is very little performance difference between different concurrency approaches and all you're exposed to as developer is implementation of your handler functions.

Not the case; good abstractions are valuable, but the performance differences between runtimes are very real. Take the example of some simple HTTP blob store service gets slammed with millions of requests when someone using the API does a backfill via some framework on their end that aggressively scales request volume up and out. Something like, say, async Python/starlette with a coroutine per request is gonna perfor…

> You're right that those differences are sometimes marginal when the latency of whatever IO the backend's doing dominates the equation. However, in my experience huge volume surges show issues with the runtime (the thing managing/launching multiplexed request handler routines) or the ecosystem (the backend IO libraries' ability to work with the runtime's IO multiplexing and make things like request coalescing easy or automatic) more often than you'd think.

fair enough, although at this point we start talking about LB in front of the thing, consumption mechanics, autoscaling signals

i will still maintain that my simple advice for a dev worrying about scale, is that they should focus their efforts on ensuring downstream IO doesn't get overwhelmed (db read replicas, caching, etc) before optimizing runtime performance or autoscaling out unnecessarily.

Re: My thoughts after using Clojure for about a month

#185

Post by zbentley »

midnight_eclair wrote: post #184
zbentley wrote: post #176

Earlier quoted context omitted.

Not the case; good abstractions are valuable, but the performance differences between runtimes are very real. Take the example of some simple HTTP blob store service gets slammed with millions of requests when someone using the API does a backfill via some framework on their end that aggressively scales request volume up and out. Something like, say, async Python/starlette with a coroutine per request is gonna perfor…

> You're right that those differences are sometimes marginal when the latency of whatever IO the backend's doing dominates the equation. However, in my experience huge volume surges show issues with the runtime (the thing managing/launching multiplexed request handler routines) or the ecosystem (the backend IO libraries' ability to work with the runtime's IO multiplexing and make things like request coalescing easy o…

> focus their efforts on ensuring downstream IO doesn't get overwhelmed (db read replicas, caching, etc) before optimizing runtime performance or autoscaling out unnecessarily.

All good advice, but the choice of runtime can affect the point at which autoscaling and load balancing even need to enter the conversation at all. Optimizing, say, a mostly in-memory cache service and writing it in Golang may yield results like "we can run a single instance of this and serve three orders of magnitude of business growth; slap it behind a DNSRR or a k8s NodePort for update/replacement/fast failover if it crashes, no complex load balancer needed", where writing the same thing in, say, PHP might require discussing orchestration/load balancing/memory/worker process recycling/autoscaling early on in the service's lifetime. Being able to skip those conversations (entirely or for a long time) is a very significant business benefit.

Re: My thoughts after using Clojure for about a month

#186

Post by Sharlin »

mpweiher wrote: post #156
Sharlin wrote: post #120

Earlier quoted context omitted.

Indeed. The incredibly clumsy way we choose to edit source code has baffled me since I was first acquainted with parinfer. Having to keep the source in the shape of a valid AST almost entirely manually is really annoying.

Syntax-directed editors were all the rage in the late 70s early 80s...and a huge failure, because they were a lot more annoying than any text editor has a chance of ever being. It's one of those things that, like visual programming, is absolutely and obviously The Right Thing™ until you try to implement it and use it. That said, we have made progress in both areas, and maybe we will figure them out in the future.

Yes, it’s definitely not a trivial problem. But parinfer shows it can be done mostly non-annoyingly at least for lisp; what is less clear is whether it would generalize to languages with more syntax.

Re: My thoughts after using Clojure for about a month

#187

Post by djblue »

Hammershaft wrote: post #91
Jeaye wrote: post #38

Once you learn Clojure's syntax and semantics, you're no longer bound to the JVM. There's ClojureScript (JS), ClojureCLR, ClojureDart, jank (C++), Basilisp (Python), babashka (SCI), and many others. This means that, if you don't know Java or don't like the JVM, you can likely use Clojure wherever you already feel most comfortable. For the most part, any Clojure code which doesn't use host interop will work on all dia…

As someone who loves Clojure, I wonder about the real portability across host languages. Do you have experience with any of these other dialects? (beyond the obvious CLJS & Babashka?)

I build and maintain Portal, which runs on multiple platforms including: Clojure, Babashka, ClojureCLR, ClojureScript, nbb, joyride, basilisp and soon jank. The main thing that's different per platform is the os/fs/http/ws libraries but the runtime state and serialization is all the same and reused across all platforms. Also, recently I was able to get most of Portal's reagent viewers, which were designed primarily to run in a browser via ClojureScript, running on the JVM for Server Side Rendering. Clojure is the most portable language I have ever used!

Re: My thoughts after using Clojure for about a month

#188

Post by djblue »

pdimitar wrote: post #6

With respect, this topic in particular has been beaten to death. I too liked Clojure when I tried it some years ago (agreed on the composition and data structures; both are _great_). But the real value-add is in the runtime, not the syntax. Java has a solid runtime but it's not yet as good as Erlang's, maybe even not up to the standards of Golang -- I am talking concurrency / parallelism here (for memory management I…

I think one of Clojure's main strengths for concurrency / parallelism is structural sharing of immutable data across threads, which you simply cannot do in Erlang.

Re: My thoughts after using Clojure for about a month

#189

Post by pdimitar »

djblue wrote: post #188
pdimitar wrote: post #6

With respect, this topic in particular has been beaten to death. I too liked Clojure when I tried it some years ago (agreed on the composition and data structures; both are _great_). But the real value-add is in the runtime, not the syntax. Java has a solid runtime but it's not yet as good as Erlang's, maybe even not up to the standards of Golang -- I am talking concurrency / parallelism here (for memory management I…

I think one of Clojure's main strengths for concurrency / parallelism is structural sharing of immutable data across threads, which you simply cannot do in Erlang.

I kind of agree. Erlang took the "share nothing" thing to extremes by copying everything which, while improving memory safety by a huge margin, introduced (a) various GC footguns (like the shared big binaries gated behind refcounting which is a famous footgun for very long-running apps) and (b) reduced its raw speed.

Re: My thoughts after using Clojure for about a month

#190

Post by rekabis »

HN hug of death?

> Too Many Requests

> The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.

>

> Details:

> Actioning this file would cause "www.acdw.net//clojure/" to exceed the per-day file actions limit of 80000 actions, try again later

Post reply on HN