Fork me on GitHub

@dm3, true. Aleph enables you to make network servers & clients that use Manifold's abstractions. Aleph is splendiferous and Manifold's "Deferred" abstraction really hits the spot. Etc etc.


@petr Yada is built on top of Aleph, and I hear nothing but good things about Aleph. It's built on top of netty, which makes it a solid http server.


are there any advantages of Aleph over pedestal?


overall performance, probably stream handling and the abstractions behind it (depends on what you like, might be subjective)


and aleph is not only a webserver, it's offers more out the box (more general purpose networking lib, including a webserver )


@mpenet Can I find some benchmarks somewhere?


google clojure web server benchmarks


Yea, the ones I found were from 2015


to be taken with a grain of salt, these are fine tuned to perform well in that context too


not much has changed since


Well, its as always with benchmarks, looking at the techempower ones, http-kit performs best in most setups


As I said, benchmarks have to be taken with a grain of salt. I had bad experiences with http-kit in production/heavy load personally. Happy with jetty9 based frameworks so far, but aleph is also a good, well tested contender (so is undertow).

Shantanu Kumar14:11:01

@mpenet Just to add my http-kit exp I am running a forked http-kit in prod that instruments it to add metrics logging for request drops (`503` and various status codes) etc

Shantanu Kumar14:11:52

I’ve noticed 503s at times under load


my exp is from a while ago (prob 2 years ago), but we had deadlocks, 100% cpu spins etc, pretty much a show stopper, we just switched. It was also before the new maintainers stepped in, I don't know how it is now. But I am happy with something less exotic like jetty personally


Aleph was also heavily used by factual if I recall, with some quite impressive numbers behind their usage. So I'd expect it to be solid too


Just wondering here, it's about design, as an example (and a line of code says more than a 1000 pictures, ... 😉 ) : (-> task store dispatch) dispatch is based on the properties of task and dispatches to a task-handler every task-handler will use some functions somewhere in its workflow, such as check-result and store-result (depends on the task and it's result) and act-on-result (action depends on original task, result of task and task-handler) every task-handler also can use some functions, such as set-status and notify-watcher (can be email, phone, slack, ...) Does this make sense: 1. core.async publisher to dispatch to several subscribers (task-handlers) 2. my-ns.core contains mainly (-> task store dispatch) (main logic of the namespace) 3. I have a bunch of my-ns.task-handler.handlerX namespaces, each implementing their own handler logic. I must, however, require these namespaces in my-ns.core, so I can register (subscribe) the handlers. 4. my-ns.task-handler.util contains check-result, store-result and act-on-result. I don't put them into core, because if I do, I have to pass them several levels deep, which doesn't make sense to me. All handlers should do this at some point, only, due to the very different logic of each of them, it can be at a very different point. 5. my-ns.task-handler.mixin contains set-status and notifiy-watcher. I can't think of a better name. It are just functions that may be used by the handler, or may not. Some functions in ....mixin and ....util could be multimethods, or I could just use case/cond/match (since they depend on the task and result) Does this make any sense?


@sveri I'd also note that Pedestal and Aleph aren't really comparable. Pedestal is an application framework, Aleph is a web server.


http-kit has issues with backpressure I believe. This, for example, can cause issues when a client stops receiving from a websocket.


It's probably a good idea to look at benchmarks for the underlying engines if applicable: netty (aleph), jboss (immutant)


Immutant's "underlying engine" is Undertow:


BTW: in case you haven’t seen it, there’s a new doc site for Pedestal.


Clojure 1.9.0-alpha14
Java HotSpot(TM) 64-Bit Server VM 1.8.0_60-b27

user=> (require '[clojure.spec :as s] '[clojure.spec.test :as stest])
user=> (defn f [x] 3)
user=> (s/fdef f :args (s/cat :x nil?) :ret string?)
user=> (stest/instrument `f)
user=> (f 1) ; (1) are invalid args, which correctly throws exception

clojure.lang.ExceptionInfo: Call to #'user/f did not conform to spec:
                            In: [0] val: 1 fails at: [:args :x] predicate: nil?
                            :clojure.spec/args  (1)
                            :clojure.spec/failure  :instrument
                            :clojure.spec.test/caller  {:file "user7054451703452456727.clj", :line 1, :var-scope user/eval2314}

user=> (f nil) ; valid args, so the function returns, but it returns an invalid 3 without thrown exception
Here, clojure.spec correctly detects for me when an instrumented function receives invalid :args input (e.g., (f 1)), but it does not detect invalid :ret output (e.g., returning 3). Am I missing something here?


there's a blurb about this @cigitia in the guide ^


@ghadi Ah, of course, I missed that part; thank you!


@vigilancetech a list of symbols is not a function (it hasn't been compiled yet)


'(fn [] nil)
=> (fn [] nil)
(fn [] nil)
=> #object[user$eval28312$fn__28313 0xa4ee7d8 "user$eval28312$fn__28313@a4ee7d8"]


see? a function is an object that gets printed like that, what you have is a list of symbols that gets printed nicely


so how do I get the compiled version to store in my list and call it later?


it depends on the context. if you're in a syntax quote ` then use unquote ~


`("foo" ~(fn [] nil)) => ("foo" #object[user$eval28348$fn__28349 0x16feb661 "user$eval28348$fn__28349@16feb661"])


or you could construct the list more manually with like (list "string" (fn [] nil))


ie, don't do quoting


if you can avoid quoting forms then you'll probably find it easier to understand if you're just getting started with clojure. quoting is like another whole syntax to learn


Well, I'm from elisp so I should have known better 🙂


but elisp has eval so such things would probably work there. My target is clojurescript and I don't want to drag along eval


I can handle the backquote/tilde combo just fine. It was a little different w/elisp

Al Baker19:11:18

there a good lein template for a CLI app (i.e. a little program you feed a few arguments to and it does a thing) ?


@dominicm @mtnygard Thanks for your input


@tcrawley Apparently I mixed up sponsor & name, oops. Thanks.


why isn't this valid defrecord syntax (the destructuring portion)?

(defrecord Blerg [{:keys [a b c]}] ...)


you can't do destructuring in a defrecord declaration


I'm trying to use defrecord while extending a protocol, and it'd be nice to do something like this. If I can't destructure here, I have to destructure in each of the protocol's function implementations or not use a map.


hmm... unless there's a better way, i'll just do one of those


yeah I guess it could be handy, but it's definitely not supported. at a minimum I don't know how you'd deal with the fact that the defrecord positional fields require names, while destructuring lets you omit them


@bfabry thanks for the sanity check, I really thought that feature should be there, and thought I was doing something wrong since it wasn't 🙂 makes sense why not tho.


base impl of defrecord expects bare symbols to have typehinting


@ghadi that'd work, thanks for the idea 🙂


Question: How to call a clojure function from Haskell? :thinking_face: Lots of attention on this bountied question, but still no reasonable answer:


you'll have to create a bit of "glue" yourself, probably by creating a clojure server that haskell can call over a port, or by creating a standalone script that haskell can call from the system...


I love haskell, i love clojure, but i wouldn't personally look forward to merging them like you're attempting


Unclear how old it is, but if good this would solve the problem immediately.


which problem is that?


Being able to use clojure in the C/C++ (and hence GHC/Haskell) ecosystem


It's a cool project, not sure it meets the "it's clojure" sniff test


you might find more of interest in your quest sniffing around the planck-c project


Interesting I just checked it out although there is no mention (AFAIK) of a FFI


in particular: exporting clojure functions to be consumed by a C/C++ library


I'd expect that to happen by floating them up through webkit as JS entities