This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-13
Channels
- # 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 require and :require?
This code using require returns an error:
(ns hello-world.core
(require [clojure.set :as set])
(:gen-class))
:require compiles 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 ns or require outside of it?
What's the ":-"
Is it part of spec?
It seems it's some kind of type hinting?
E.g. (s/defn make-consumer :- FranzConsumer ...)
Thanks Dominicm!
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?
(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
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
does it make sense to use leiningen and tools.deps side-by-side?
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 clj completely.
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
maybe switching whole makes more sense!
Chat to Rich when he's around, and see what limitations he's aware of with the lein integration.
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 @U04V70XH6 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.