This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (25)
- # asami (39)
- # beginners (39)
- # biff (12)
- # clojure (53)
- # clojure-dev (4)
- # clojure-europe (6)
- # clojure-hungary (1)
- # clojure-norway (4)
- # clojure-spec (3)
- # conjure (2)
- # cursive (1)
- # dev-tooling (9)
- # emacs (4)
- # introduce-yourself (2)
- # juxt (4)
- # membrane (8)
- # off-topic (3)
- # polylith (8)
- # portal (4)
- # releases (1)
- # scittle (9)
- # sql (11)
- # squint (5)
- # xtdb (12)
Hi, is there a function like groupWith in Ramda.js (https://ramdajs.com/docs/#groupWith) in Clojure core library which I can use to group/chunk items in a vector? Example:
groupWith(isEqual, [1, 1, 2, 3, 4, 5, 5]) // Output: [[1, 1], , , , [5, 5]
@U04BQTA73C2 Thanks! One more question, how can I turn the returned list, from partition-by into a vector?
(into  (partition-by identity [1 1 2 3 3 4 5 6 7])) but it only converted the outer list.
I thought I'd take a shot at converting this to a transducer:
This should be more efficient as it avoids the intermediate step of creating a list of lists.
(into  (comp (partition-by identity) (map vec)) [1 1 2 2 3 3 4 4])
so is the kit framework heavily used? I see there's a bunch of things that I used to build myself, like migrations, system startup/dependencies, etc. So while it looks generally light weight, all of those features feel super heavy weight. i.e. if I don't fully grok integrant, I'm kinda stuck. Any thoughts on this? @yogthos?
Kit largely builds on Luminus which is pretty mature at this point, and it is getting use in production today. Kit is designed that the core of it is extremely light, when you make the base project all it creates is an HTTP handler and the router. Things like migrations can be added to the project as need arises. I recommend watching this intro for Kit as it explains the general structure, how Integrant is used, and shows how to add features as you go https://www.youtube.com/watch?v=DFzukK5-rpU
working through an intro project can also be helpful https://kit-clj.github.io/docs/guestbook.html
It's probably also worth noting that Luminus and Kit aren't really "frameworks" in the traditional sense you find in other languages -- they are curated collections of libraries that work well together, and the templates behind Luminus and Kit are mostly ways to "automate" a lot of the boilerplate code needed to wire those libraries together.
I don't particularly like some of the libraries that Luminus and Kit have standardized around so I still prefer to build web apps "from scratch". I prefer Component over Integrant, for example.
One big reason for the choice to use Integrant in Kit is that it plays really well with Aero allowing describing the whole system using a single EDN file. All the configuration and resource declarations are described in a single place making it easy to see all the relationships, and set flags for dev/test/prod configurations there.
I do think these kinds of projects provide less value for seasoned devs though. If you already have a set of libraries you like to use, it’s easy enough to make your own template around them. The main goal is to hopefully remove some barriers for newcomers and make some choices that will get them set on a good track.
We've just switched to Aero at work (from our two(!) custom configuration libraries that we built over the years) and it is very nice.
If we ever replace our custom SQL migration code, I suspect we'll adopt Migratus 🙂
Back to @U0DCK21EJ’s original Q: the libraries that are curated into Luminus and Kit are heavily used in production -- and are far more widespread than just in the Luminus and Kit templates.
that makes sense -- I've built my own version of things that do things like migrate SQL schemas and such. If there's any library I'm looking for, it'd be for single sign on and things like that
my experience with clojure frameworks and most clojure libraries is that I have to read most of the code my app touches to figure out issues in documentation, or I have to put debuggers in the framework code, just to figure out if I'm doing something wrong, or the framework has a bug. it is very hard to determine what side a bug lies on in this case. so if you find yourself trusting the documentation of your current framework, and you aren't constantly running into framework bugs, you should probably not switch.
so the other thing I noticed is that Leiningen seems to be on the out, and there's lots of clojure tools and deps.edn. Is that the trend?
well, I've got a few different projects in flight... one is a personal one, published to heroku. The others are more like microservices, notebooks, and little data science environments shared with my team
If you have projects based on Leiningen that are working, continue using
lein in those projects. For new projects, I would recommend the Clojure CLI and
deps.edn because that has the support of the core team. The 2022 State of Clojure survey (published back in June) showed that Leiningen usage had dropped from 94% in 2018 to 69% by this year while
deps.edn has grown to 64% (it was only introduced in 2018).
trying deps out is pretty pain free compared to switching web frameworks. so, try it out. you can both lein and deps in the same project
We started with
lein back in 2010 because it was the only option. We switched to Boot in 2015 because Leiningen was too limited for the sort of programmatic build stuff we needed at work, but we ran into limitations and bugs in
boot and switched to the CLI in 2018. It works well for us -- we have 134K lines of Clojure in a monorepo with 170+
deps.edn files (we have a lot of subprojects!).
yeah I'm kinda worried that clojure cli/tools/deps is going to leave lein in the dust, and it will be like 2004 and ant-vs-maven, or later maven-vs-gradle
I think over time you will see
lein usage continue to decline. It's served us well.
The original creator and maintainer of Leiningen moved on to other tech. I'm not sure how active the current maintainer is. But Leiningen is very mature and stable at this point so as long as someone is able/willing to update it to run on new JDKs and with new versions of Clojure, it'll continue to be useful into the future.
FWIW, the #C0AB48493 channel and the #C6QH853H8 channel both have about 1,000 members, give or take.
now we're getting to the ground truth on what's been going on in the tools department, with the clojure core team and investment going into clj tools/deps, plus the ability to have gradle-style flexibility, seems like a winner
anyhow, I'm going to watch the video and walk through the guestbook example to get a feeling on some of these library choices
Component is another of those and predates both. It's what we like to use at work. There are several others that also manage state lifecycle.
I'm trying to decide if I take an older luminus code base, and kinda refactor/migrate into kit
if you have a project that works already there might not be a lot of value migrating it over.
But while i am doing this is always getting
(tick.core/long (tick.core/now)) => 1671913688 (DateTime. 1671913688) => #clj-time/date-time"1970-01-20T08:25:13.688Z"
1970-01-20T08:25:13.688Zwrong timestamp, can anyone please help me with this problem
Wild guess but have you tried to input milliseconds instead of seconds?
Also you used tick for deriving the seconds value of
now but you then use
DateTime and probably this is why they expect something else as input.
As this code
(DateTime. 1671913688) is in our common service where we are receive input from java & clojure its working fine with the value receiving from java
the problem is only when we send the value form clojure
> Is there any way we can get with the milliseconds form tick? I have no idea. Please read the docs, you chose the library so you have to know where they are. You can always divide by 1000 to get seconds... or vice-versa... You can divide and multiply in any part of your system.
If you are new to Clojure, you'll find the #C053AK3F9 channel more likely to give you more in-depth answers (and you'll be less likely to be told to go read the docs 😁). The assumption in #C03S1KBA2 is that you already know what you're doing.
> multiply in any part of your system Don't do multiplication because sometimes the milliseconds will matter and it will be a bug if you truncate them to seconds and them multiply by 1000 to get milliseconds. You'll lose precision (also with milliseconds/seconds you already lose time zone).