This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (43)
- # aws (9)
- # babashka (21)
- # beginners (76)
- # calva (56)
- # chlorine-clover (1)
- # cider (12)
- # circleci (1)
- # clj-kondo (7)
- # cljsrn (13)
- # clojars (3)
- # clojure (174)
- # clojure-dev (11)
- # clojure-europe (64)
- # clojure-nl (11)
- # clojure-spec (6)
- # clojure-uk (9)
- # clojurescript (31)
- # conjure (1)
- # cursive (7)
- # datascript (7)
- # datomic (9)
- # emacs (4)
- # fulcro (65)
- # introduce-yourself (1)
- # jobs-discuss (7)
- # kaocha (7)
- # lsp (39)
- # missionary (5)
- # off-topic (56)
- # pathom (10)
- # re-frame (6)
- # shadow-cljs (110)
- # tools-deps (41)
Clojure CLI tools user level aliases - for tools, libraries and environments across all your Clojure deps.edn projects Monthly library updates and readme clean-up All details in the changelog https://github.com/practicalli/clojure-deps-edn/blob/live/CHANGELOG.org#2021-09-13
Released a new version of holy-lambda v0.5.0. This release has been done with the financial help of https://www.clojuriststogether.org/ ❤️ Holy Lambda is extraordinary simple, performant, and extensible custom AWS Lambda runtime for Clojure. https://github.com/FieryCod/holy-lambda Changes • HL is now fully decoupled from AWS SAM • Clojure on official AWS Java runtime is obsolete. As a replacement the new Clojure on Clojure backend has been developed, which is more performant than the official one. (benchmarks in progress) • Removed interceptors. • https://fierycod.github.io/holy-lambda • Smaller & more performant core! • Update babashka backend to 0.6.1
Nice! Perhaps a typo here : >For Clojure on official AWS Lambda Java runtime the cold start is between 8-12on a 2GB memory-sized environment. -> 8-12s on What is the Clojure on Clojure backend and why is it faster than AWS' Java? I couldn't find it quickly in the docs (though I suppose it's there somewhere..) Also, do you have some benchmarks for all the backend? I've once tried babashka lambda (without HL) and it still had considerable cold start - which I blame on the fact that unpacked it had 140MB (70 bb, 70 jdbc pod) that needed to be transferred and decompressed...
@U0522TWDA thanks! Fixed the typo. Will push the change soon 🙂 Clojure on Clojure is basically uberjar + custom Clojure runtime ran on some sort of JVM. This is different than the official AWS Java runtime that: 1. Invokes the handler using reflection based on name, 2. Uses Java Correto (regular JDK users will be in some time pushed to use Java Correto, which works kinda slow for Clojure) (don't know why, yet) Regarding babashka backend HL includes the pods in the zip, so no download of pods happen on runtime. Size of the artifact does not matter much in your case I think. @U09LZR36F Here are benchmarks although not yet edited, and without tiered compilation for Clojure on Clojure, so there will be some significant differences in cold starts i suppose. https://github.com/FieryCod/holy-lambda/tree/master/benchmarks/holy-lambda-vs-other-runtimes Disclaimer: Benchmarks for Java are still using OpenJDK.
Ok, so the Clojure runtime is essentially a Docker image, currently based on OpenJDK, like this one https://github.com/FieryCod/holy-lambda/blob/master/docs/examples/getting-started/clojure-backend/holy-lambda-example/Dockerfile, correct? And it is faster b/c Correto is slower than OpenJDK for Clojure and because reflection on name is faster than whatever AWS does by default? > Regarding babashka backend HL includes the pods in the zip, so no download of pods happen on runtime What I meant was that for cold start, Lambda needs to transfer the whole lambda zip from S3 where it is kept, and the bigger it is the more time that takes. So 1kB Python script will have faster startup than 80MB (22MB compressed) bb (on my PC, unzipping that takes 500ms!)
Clojure runtime is essentially custom runtime, that does not include all the Java'ish bloat, and this is why it's faster. JVM implementation is a user choice, but yeah correto is slow, so by default I'm including openjdk
Regarding babashka I think you're assumptions are wrong. Do you cache jdbc pod? Or do you download the pod on cold start?
I mean 2-3 years ago I have packed 200mb of node_modules and cold start was around 300ms.
Are you sure the pod was not re-downloaded? 😄 I had to do some additional work on HL side to ensure it
Thank you. I will experiment with that at the next opportunity. I am quite sure (99.9%) the pod was not re-downloaded as I included it using a local path. I still think that transferring 40-50MB (in my case) and unzipping it is bound to take some time, even if there is a super network between S3 and lambda.
I am pleased to announce the first release of fijit (https://github.com/erp12/fijit). Fijit is a Clojure library for interop with Scala. The goal of this project is to make it easier and more idiomatic to use Scala projects from within your Clojure projects. Some key features include: • Conversions between Scala and Clojure collection types. • Macros for writing Clojure code that targets multiple Scala versions. • A Clojure implementation of the Scala function types. • Idiomatic Clojure interfaces for common Scala types like Option, Try, Tuple, and more. • An experimental Clojure API for Scala reflection and runtime compilation. If you (like me) have to call out to Scala projects, hopefully some of the functions and macros in fijit can help reduce some of the friction.
A long time ago I tried to use the Clojure REPL from Scala: https://blog.michielborkent.nl/2016/07/26/clojure-from-scala/ This was during a short adventure in a Scala company.
That is a very interesting idea! I never thought about inspecting the Scala/Java context using an in-process Clojure repl. Very clever.
That's perfect! I added it to the FAQ and credited you. Perhaps one day I will retcon the origins to make myself seem far more clever and cultured than I am. 😄 Thanks!
I mean I don't know latin 😅 I just figured it was one of those cases where the j replaced another letter and it just happened to work out
clj-kondo 2021.09.14 ✨
A new linter
:loop-without-recur and several other enhancements and bug fixes.
Clojure https://clojure.org/releases/devchangelog#v1.11.0-alpha2 is now available with the following changes since alpha1:
• https://clojure.atlassian.net/browse/CLJ-2123 Add :as-alias option to require like :as but not load
• https://clojure.atlassian.net/browse/CLJ-1959 Added implementation of update-keys
• https://clojure.atlassian.net/browse/CLJ-2651 Added implementation of update-vals
• https://clojure.atlassian.net/browse/CLJ-1908 Add clojure.test api
run-test-var to run single test with fixtures and report
• https://clojure.atlassian.net/browse/CLJ-1879 IKVReduce - make old slow path (IPersistentMap) faster and extend to Object, detaching it from any fully enumerable set of types
• https://clojure.atlassian.net/browse/CLJ-2600 Don’t block realized? of delay on pending result
• https://clojure.atlassian.net/browse/CLJ-2649 Fix order of checks in some-fn and every-pred for 3 predicate case to match other unrollings
• https://clojure.atlassian.net/browse/CLJ-2636 Get rid of reflection on java.util.Properties when defining clojure-version
• https://clojure.atlassian.net/browse/CLJ-2350 Improve keyword arity exception message
• https://clojure.atlassian.net/browse/CLJ-2444 Fix typo in test-vars docstring
• https://clojure.atlassian.net/browse/CLJ-1509 AOT compile more Clojure namespaces
• https://clojure.atlassian.net/browse/CLJ-2387 Fix off-by-one in socket server port validation
• Update dep to core.specs.alpha (0.2.62)
Where would be the best place to ask questions about some implementation details of some of these? I'm wondering why is https://github.com/clojure/clojure/commit/1d271d7bc74f64831985f89be1d814df2c5f046f#diff-313df99869bda118262a387b322021d2cd9bea959fad3890cb78c6c37b448299R7963 not
(transient (empty m)) but I don't seem to be able to comment on the Jira
@U08BJGV6E probably @U050WRF8X is the best person to answer this but I believe the difference here is that with update-keys, the keys are going to change and the structure of the map will change, so there is no reason to update the existing map. also, there are lots of potential issues with changing the key set for different map types (like sorted, ordered, etc). In update-vals, the keys stay the same, so the fastest thing to do is update a transient version of the existing map, if you can.
Thanks Alex. It caught my eye as we use https://github.com/frankiesardo/linked which keeps insertion order and it became a habit of mine to use
(empty m) everywhere I 'modify' a map without knowing the broader context
Importantly, the docstrings for both update-keys and update-vals both say "returns a new map" which means you should not presume anything about the relationship of the returned map type and the input map.
I understand the reasoning but (I guess due to the problems I had when the type was lost) still tend to disagree -
(empty m) also creates a new map (be it sorted or ordered etc.) so you aren't really 'modifying' the original one (as you would with
Apologies for making noise if this has already been considered, I won't pursue this any further, just hoped handling this similarly to
update-vals could broaden the applicability of this fn.