Fork me on GitHub
hipster coder01:04:55

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.

hipster coder03:04:07

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])
The error message is “syntax error macroexpanding clojure.core/ns”. But this code using :require compiles just fine:
(ns hello-world.core
  (:require [clojure.set :as set])

dominicm06:04:15 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?


Inside of ns is conventional

Yannam C Chiranjeevi06:04:30

Is it part of spec?

Yannam C Chiranjeevi06:04:01

It seems it's some kind of type hinting?

Yannam C Chiranjeevi06:04:43

E.g. (s/defn make-consumer :- FranzConsumer ...)


It's a type hint in the library schema


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
(BTW No need to import Thread)


well, it clashes when you call a static method on Thread


I have no use case, but when analyzing code it’s good to know what to expect


yeah, just tried. So no nice integration.


I think Clojure requires/aliases are prioritized, so I’ll assume that for now


evidence seems to confirm that


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.


you can see it in use on line 357 of that file, for example


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

Lennart Buit21:04:18

does it make sense to use leiningen and tools.deps side-by-side?

Lennart Buit21:04:13

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).

Lennart Buit21:04:36

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.

Lennart Buit21:04:04

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

Lennart Buit21:04:02

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.

👍 4

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.

👍 4

@lilactown although slightly hacky, I think one also can do that sort of thing with I've used both tools (refactor-nrepl + rewrite-clj) and the latter can be a bit low-level.


Anyone have experience with enums in lacinia?