This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # bangalore-clj (1)
- # beginners (47)
- # boot (16)
- # calva (33)
- # cider (14)
- # clj-kondo (3)
- # clojure (46)
- # clojure-india (1)
- # clojure-italy (6)
- # clojure-nl (4)
- # clojure-uk (5)
- # clojurescript (10)
- # dirac (8)
- # emacs (1)
- # fulcro (1)
- # leiningen (14)
- # lumo (1)
- # off-topic (178)
- # pathom (9)
- # planck (17)
- # quil (2)
- # reagent (5)
- # reitit (6)
- # shadow-cljs (55)
- # tools-deps (3)
I just learned that Clojure and Scala are both using tries for their list data types (persistent/immutable). But Elixir uses linked lists which can be spread all over the RAM (inefficient). Could this contribute to Clojure/Scala being better at data crunching? And Elixir is more for horizontal scaling because it doesn’t share memory.
I made a mistake. Actually, Elixir can do vertical and horizontal scaling. It’s just not made for sharing memory (number crunching) like Clojure can do?
What is the difference between using
This code using
require returns an error:
The error message is “syntax error macroexpanding clojure.core/ns”. But this code using
(ns hello-world.core (require [clojure.set :as set]) (:gen-class))
:requirecompiles just fine:
(ns hello-world.core (:require [clojure.set :as set]) (:gen-class))
@aryyya.xyz the first is invalid inside of ns, it used to work by coincidence, now it doesn't.
@dominicm And which is conventional to use,
:require inside of
require outside of it?
Is it safe to assume that Clojure aliases dominate over Java class imports?
(ns foo (:import [java.lang Thread]) (:require [clojure.core :as Thread])) (Thread/+ 1 2 3) ;;=> 6
They seem to integrate “nicely” @borkdude but wouldn’t put that in my code. Do you have an use case in mind?
(BTW No need to import Thread)
(ns foo (:require [clojure.core :as Thread])) (Thread/+ 1 1) ;; 2 (Thread. "Hello") ;; java.lang.Thread 0x49872d67
so I’m thinking of doing a dirty thing and making some breaking changes to a library I maintain
mainly re-naming some functions. I’m curious if anyone’s ever done work on creating syntax transforms for Clojure that can be run on projects to help with migrations like this.
I believe the mainstream opinion is, don't break consumers. Have you considered deprecating instead of breaking?
I have 🙂 these functions are really a part of a set of idioms and naming conventions that I want to change for users of my library
I’d prefer to rename them and then give my consumers a utility to convert their code from the old naming contention to the new naming convention
I would strongly recommend introducing a new namespace with the new API and announcing to your users that the original API namespace is deprecated and encourage them to switch to the new namespace.
But then keep the old API namespace around for a long time (just don't maintain it).
I think even with deprecation, it would still be cool to have utilities that could help refactor code when API migrations occur. it sounds like this hasn’t been something people have done in Clojure
Yeah, a migration utility could well be a good idea, depending on how much code out there depends on your library.
@lilactown perhaps something like this: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj#L343-L351
like with lein-tool-deps. I am asking because tool.deps has nice git integration
Based on my experience writing and using
boot-tools-deps -- Boot +
deps.edn -- I would say that, ultimately, you'd be better off just switching to
These integrations tend to have limits. Basic stuff works well. More complex stuff tends to have weird behaviors.
Boot and Leiningen might be different enough that the limitations I hit with Boot don't impact you in Leiningen in the same way... If I were you, I'd chat with Rick about any known limitations (when he's around).
right, thanks! I must admit that I spent as little time as possible dealing with configuring tooling, but I start to see that not having Git deps is starting to be a nuisance
At work, we started with Leiningen back in 2011, switched to Boot at the end of 2015, and then introduced
deps.edn last year, via
boot-tools-deps, at first, but then switched completely to
clj. We've been very happy with the switch.
yeah at my work all of our projects use lein, but… to be quite honest, I don’t know why. I’ll investigate some more
Chat to Rich when he's around, and see what limitations he's aware of with the
As the author of
boot-tools-deps, I wouldn't recommend the hybrid approach with Boot, except as a bridge to migrating from Boot to
clj. Some of that is to do with how Boot deals with dependencies, the classpath, pods, and so on.
The main issue I ran into when using
lein-tools-deps was that the dependency resolution for
lein is similar, but not the same as
tools.deps. So, even with the same dependencies, the resolutions might be different if you use (for example)
lein uberjar you could potentially get different versions of some libraries than if you ran the
clojure script. I would second @ in recommending that a hybrid approach only be used during transition.
@lilactown although slightly hacky, I think one also can do that sort of thing with https://github.com/clojure-emacs/refactor-nrepl/#find-symbol. I've used both tools (refactor-nrepl + rewrite-clj) and the latter can be a bit low-level.