Fork me on GitHub

would it make sense for packages to include the version in their namespace? would it not be more in accord with the idea of immutability and robustness? why should my project break if some implicit dependencies lose consistency over a simple update?


i would understand if this limitation is due to the legacy way of doing things in production


Rich Hickey didn't recommend keeping immutability of code -- he recommended that updates to code should not break the API provided by previous versions, i.e. you can add new functions or other kinds of Vars, or extend their capabilities to require less in terms of inputs, or provide more as return values, but not vice versa.


If you want to break the current API, then you should consider creating a new name for the library and its namespaces, so it is a new thing, not a broken version of the old thing.


@andy.fingerhut are there any ecosystems that consider the version to be part of the namespace?


@andy.fingerhut does it make sense to have such a thing?


One way to provide a new library that is similar to an old one is to put a number in its name, e.g. the first version was mygreatlib, and when you want to break the API of mygreatlib, you instead publish mygreatlib2. I believe the talk I linked above mentioned a few cases of Windows APIs where this was done, but it was pretty rare.


@andy.fingerhut but say different packages dependencies are pulling different versions of the "same" library, would there not be a conflict?


Depending upon what mygreatlib and mygreatlib2 do, they might conflict with each other, e.g. they both open a network socket listening on the same TCP port, or might write to a config file with the same name, etc., but in many cases there would be ways to prevent such conflicts. I could imagine some library functionality where it doesn't make sense for them both to be loaded at the same time in the same program, and some where it would make sense.


If they have different names like mygreatlib and mygreatlib2, most package management systems will treat them as different libraries that can both be depended upon. Whether they can both be used from the same program is a separate question. Most package management systems I am aware of that have library names and version numbers do not let you depend on both mygreatlib version 1.1 and mygreatlib version 1.2 at the same time -- you must pick one.


Slightly off topic but immutability in code might be one of those things that needs a lot more of the language built up around it, like how you wouldn't be doing as much functional/immutable programming in Java. Interesting experiment on this very idea is Unison lang


hmm, but isn't it bad practice to hide such stateful actions in the behaviour of a namespace? i suspect that in any case the namespace shouldn't open files or ports implicitly without knowledge of the caller


what you described sounds like a bug to me, it does not justify the expectations of the package manager


come to think of it... how do linux package managers treat this?


@eagonmeng unison seems like a hardcore implementation of what i had in mind


If the library you are using is intended to help serve web requests, then it is supposed to listen on TCP sockets. In that particular case it is likely that merely loading the library doesn't open up sockets -- you would have to make an explicit call, and in most cases you could probably provide an optional, or required, parameter for the TCP port number to listen on, so even then two differently named libraries that do that might not conflict with each other.


Linux package managers and Clojure Leiningen/deps.edn/boot are doing related, but still quite different things.


There are Linux packages that conflict with each other, even if they have completely different names. Sometimes this is documented, sometimes not.


@eagonmeng i am not sure if the namespace/version issue is addressed there


Unison's pretty early on but as all code is immutable and more importantly, all names are transient, you get that extra layer of indirection that symbols/vars give in Clojure. See


so if different versions of the "same" lib are present, does the importer include the version explicitly where the import is declared?


how does a namespace know which version it is importing?


Code is always referenced by hash, so since it's completely immutable, nothing is ever updated. A new "same" version of a lib needs to be explicitly updated by a "patch". Think of it exactly like Git - when someone "updates" the dev branch with code, or when the update the library version, you have to merge the changes. If those merges are like cases in git where you have strictly additive changes (like Rich talked about in non-breaking changes) then you have nothing to do. If any definitions are at all changed, you need to merge those locally. Unison has an interesting mechanism for always making such "patches" or diffs visible, so you always have the granular power to update functions you want to. In fact there's not really a concept of a library, just a bunch of functions that might depend on one another as part of a big group.


It's an interesting idea overall, but I don't think it applies to Clojure very well, as I agree with Rich in general that code doesn't need the same immutability properties. I think you get a lot of leverage out of the idea if you build an entire system around it like Unison (free distributed routines, zero compile ecosystems, no "broken" code ever), but a lot of what makes that work is the Haskell-level type system and needing to rebuild the entire thing from the ground. I'm curious how many of the ideas could be somewhat imported into Clojure though


Is it correct to say that in transit, if a json map is produced as output then it must be produced via json-verbose and there won't be any caching


i'm trying to write a transit library for elm (just doing the decoding side for now)

Ben Sless07:03:12

Is there a way to define a "mutually defined" :inline implementation for a function? Something like

(defn foo
   (fn [code]
     (if (pred code)
       `(inline-form [email protected])
       `(foo [email protected])))}
  [& args] (,,,))


I just noticed that when constructing a string from a keyword the string is not identical to its literal form. Anyone knows why this is so?

(= "foo" "foo")                ; => true
  (identical? "foo" "foo")       ; => true
  (= (str 'foo) "foo")           ; => true
  (identical? (str 'foo) "foo")  ; => true
  (= (str :foo) ":foo")          ; => true
  (identical? (str :foo) ":foo") ; => false

Ben Sless07:03:24

Keyword's toString() instances a new string, while ":foo" is statically initialized in the context of your code

Ben Sless07:03:59

Unless you use some JVM option to force it to remove duplicate strings they won't be identical


Ah, thanks. But for a symbol it is not like that, I take it?

Ben Sless07:03:53

Beware of context

(def sym 'foo)
(def s "foo")
(identical? (str sym) s);; => false

❤️ 1

Also, can I safely instruct others that keywords are always identical, no matter how they come to be?

Ben Sless07:03:56

because keywords are interned


I thought strings where too, and was writing in a beginners guide that they are, then tested it some…


While I have your attention then, the reason this throws is that map lookup is based on equality?

{(str :foo) :bar
 ":foo" :baz}

Ben Sless07:03:16

Yes, but it probably throws on the hash collision even before testing for equality


duh! Thanks!

Ben Sless07:03:03

Strings are usually interned but you have no guarantee they'll be the same object if not initialized statically. Especially with dynamically created strings you wouldn't want to intern them. Keywords are always interned and guarantee identity, which is why they make excellent map keys

Ben Sless07:03:16

When in doubt I just read the source


It was this suitability for map keys that I was writing about.


Then I went on a tangent with how strings can be lookup efficient too, but I have scrapped that now, since it was a bit deeper than suites the context.

Ben Sless08:03:38

If you're writing about map keys consider adding the following piece of data: collections as map keys are nice but their performance is hot garbage because lookups always entail an equality check

Ben Sless08:03:37

With less hyperbole


Haha, I was about to ask about that, actually. Thanks!

Ben Sless08:03:17

Nested maps or synthetic keys have better performance


Even collections as keys can be fast, if your application is set up so that it happens to always do lookups with identical collections, since then clojure.core/= finishes quickly after checking identical?


But that is not necessarily a typical case, I agree. I have seen it sometimes be the case, for some applications.


e.g. a library given some set of values (that might be collections) that it then internally uses as keys in a map to associate data with each of those values. The library will never construct a fresh value of those types -- it will always use the values provided by the caller.

Ben Sless07:03:42

they were probably only identical because you initialized (symbol "foo") and "foo" in the same context


The line between special forms and macros just became blurry to me. I see that the defmacro of let has metadata saying :special-form true . What is the implication of this? let is listed as a special form here as well:


I believe this is an implementation specific thing - let can be thought of as a special form, but in practice it's defined as a macro in terms of the actual special form let*


Makes sense to me, but it doesn't sound like an entry-level comment. let is a special form, that's it. The fact that it's implemented as a macro is an implementation detail that regular users should not care about, let alone beginners.


True, true. But it might be confusing to read about it in a guide where you are instructed to examine all things and find that defmacro. I actually had let among the macros in the guide first, because that’s what I thought it was.


Tricky to strike the balance. The guide promises to be basic in both the conflicting meanings of the word (short, yet foundational).


I solved it by not leading with that non-beginner material, and by not explaining it so much when I do mention it:


I think it looks better. But I'd still mentioned that it's a special form (right now it says "is a form"). Also, a typo at


Thanks. It is part of a section labeled special forms, but I changed it anyway. Staring at where I have a typo without seeing it.


Now I see it! I should rest from this a bit now…

😄 1

Do we have a channel to ask about Clojure internal implementation?


For example how namespaces work on the compiler level


I've been reading clojure core but I still have questions


@kevin.van.rooijen yes, #clojure-dev is the place


I think #clojure-dev is more for development of clojure itself


so this #clojure channel would probably be appropriate for asking questions about clojure internals as well

👍 2
Ben Sless11:03:36

Anyone here ever extended a function via metadata with Component's lifecycle protocol?


Probably you mean implementing Component's lifecycle protocol via metadata? Yes, it works well

Ben Sless14:03:07

I mean implementing it for a function. I want to return a function which will depend on a closed over stateful component. I ended up going the other way and implemented IFn on the record


What should the function do?

Ben Sless14:03:48

It's the handler passed to a web server

Ben Sless14:03:40

somewhere in the handler I have an interceptor with a kafka producer


I have a pretty hard time understanding what you're trying to do. It would help to state your original problem, plus your current attempt and its perceived drawbacks

Ben Sless14:03:49

I have a web server where I want to produce incoming messages to Kafka. I wanted to experiment with interceptors a bit so I used Reitit and Sieppari. I handled the production to kafka by instantiating an interceptor which takes the producer as an argument. The interceptor is instantiated when creating the router, so the function which instances a router needs to take the producer as an argument The implementation which emerges from this is two components, one for the web server, one for the producer, where inside the web server I call (http/start-server (routes producer) options) I wanted to create an implementation where the server doesn't directly depend on the producer, only on the handler

👍 1

> The interceptor is instantiated when creating the router, so the function which instances a router needs to take the producer as an argument This part might be the odd one. Creating routes shouldn't have to pull much detailed knowledge about Kafka concerns. Wouldn't it be possible to create an interceptor in the producer component definition, so that the web component simply depends on producer and pulls the already-done work of creating an interceptor?

Ben Sless15:03:30

And then the function which instances the routes will take the interceptor as an argument?

Ben Sless15:03:12

Still seems a bit arbitrary. Why just one interceptor as an argument? what about when the API expands in the future?


The interceptor wouldn't be an argument but an extra k-v in this Component systems inject component dependencies into one another via using. See ExampleComponent in , where database is used / depended-on but never passed explicitly. Translating that defrecord pattern to vanilla defns, the result would be:

(defn start-routes [{{producer-interceptor :interceptor} :producer
                     :as this}]
  (assoc this :routes (make-routes producer-interceptor ...)))


So, adding more 'external' interceptors means simply pulling more data from the destructuring part, which avoids having to add more positional arguments.


This just crossed my mind: since clojure.spec.alpha is a transitive dependency, anyone using it should probably declare this as an explicit dependency.


That seems wrong


You should consider it part of Clojure


Even though it’s broken into a library from an impl point of view


Can we rely on clojure.spec.alpha being there always from now on? If not, then declaring the dependency is probably a good idea for future proofing?


The intent was that spec is part of clojure and you don't need to depend on it explicitly


whatever migration we do for spec 2 will depend on that assumption


sounds good, thanks


Btw, are you suggesting that there will be a migration thing in clojure that will allow you to use clojure.spec.alpha as is, and it will stay this way in future versions?

Yehonathan Sharvit15:03:54

Is there a way to make byte arrays comparable by value, in the context of of a unit test. For example, I’d like to write a midje prerequesite with a byte array argument, something like this:

(fact … (provided (foo (.getBytes "abc")) => nil)
The problem is that two byte arrays generated from the same string are not equal in Java (for good reasons, because a byte array is mutable)
(.equals (.getBytes "aaa")
         (.getBytes "aaa")) ; => false


 (.getBytes "aaa")
 (.getBytes "aaa"))
=> true


(= (vec (.getBytes "aaa"))
   (vec (.getBytes "aaa")))
=> true

Yehonathan Sharvit16:03:29

My question is: how do I tell = to use java.util.Arrays/equals instead of .equals ?


you cannot "tell" =, it's not a protocol (and even if it was, you should not override it for types you don't own)

Yehonathan Sharvit16:03:38

So what can I do in the context of unit tests?


you can write unit tests that don't use =, I do it frequently

Yehonathan Sharvit14:03:14

I need a way to convince a midje prerequesite


write your own =

Yehonathan Sharvit16:03:28

The problem is that I don’t know how to progragate my definition of = to midje


Then don't use midje =)

💯 1
Yehonathan Sharvit16:03:52

I was hoping that = would call to a method from a protocol that I could override in the context of the unit tests


I'm half kidding, but you can't state a "fact" using some wrapper function?

Yehonathan Sharvit16:03:11

A fact, yet. But not a prerequisite


Ask in #midje


Can anyone point me to a connection pool library like in Ruby? Seems a very Clojure-y concept to have a lib that splits this concern out from eg. hikari. Or does everyone just roll their own?


Isn't HikariCP specifically a connection pool library?


That's what I've always used, and it's always Just Worked™.


Maybe I’m reading wrong … isn’t it a JDBC connection pool lib?


Oh, yes it is.


My use case is for keeping 10-20 TCP connections to Apple’s notification service going.


I didn't realize you were talking about connection pooling in a more generic sense.


er, yeah, meaning generic connection pooling (eg. TCP connections) not just connections to a JDBC data source.


So many JDBC connection pools around - perhaps it would be easier to create a JDBC-compliant interface for TCP connections. :D


A quick search does not turn up any TCP connection pooling libraries for Java...


haha, maybe. I’m just a little surprised since it’s almost difficult to avoid using the word “decomplected” to describe what I’m after 🙂


there are generic object pools like, I haven’t used them so can’t say if they are any good

🙏 1

That Ruby library doesn't seem like a whole lot of code — maybe just port that to Clojure? 😛


Hah it might come to that.


example of using the generic object pool


good example!


can’t promise a Clojure wrapper lib but I suspect a reasonable interop example is within my abilities.

Jeff Evans19:03:04

How would pooling work for "plain" TCP? Wouldn't you have to do a bunch of programming just to get the pooling library to understand your protocol? How would it know whether a connection can safely be returned and used by another thread (i.e. it's not in the middle of framing a message or waiting on a server response)?


Yeah, looking at the ruby one it’s relying on every “connection” being an object so presumably in Clojure terms each “connection” would probably also have to be an object conforming to some sort of lifecycle protocol, with the actual connection buried deep in there someplace.


something’s got to be doing the bookkeeping.


taoensso.carmine.commands has this code:

(defonce ^:private command-spec
  (if-let [edn (enc/slurp-resource "taoensso/carmine/commands.edn")]
      (enc/read-edn edn)
      (catch Exception e
        (throw (ex-info "Failed to read Carmine commands edn" {} e))))
    (throw (ex-info "Failed to find Carmine commands edn" {}))))
If I start a REPL and run
(require '[taoensso.encore :as enc])
(enc/slurp-resource "taoensso/carmine/commands.edn")
I get a proper EDN. Not a nil. But when I run (require 'taoensso.carmine.commands), I get Failed to find Carmine commands edn. And it only happens on Heroku. I cannot reproduce it at all locally. How is this possible?


Of course. Despite all the thinking and staring at the above text for a good minute before posting the message, only after hitting Enter did I realize that I'm compiling Clojure code on Heroku, along with some of the libraries.


Seems to work without compilation. But frankly, I still have no idea why io/resource wouldn't work after compilation. Strange.


Aaaand now I'm getting "App boot timeout" errors without the compilation. Sigh.


Are you perhaps neglecting to deploy to Heroku the directory taoensso/carmine containing a file commands.edn?


I guess you probably are deploying such a file, if a remote REPL returns a good result for (enc/slurp-resource "taoensso/carmine/commands.edn")


Yep, it's all there.