Fork me on GitHub
Jack Park00:11:22

Intention: create a pluggable API, similar to what the Java Interface allows. Use: different databases, e.g. an RDBMS, or a REST-based remote client, etc, all callable through the same function calls. There are interfaces and prototols. My OO instincts remind me that I can import (require) a given class as the interface and call it, but I'd like to better understand how I could use definterface` or defprotocol`` in different files, then just require one or the other without rewriting the calls.

Jack Park01:11:20

digging into the Programming Clojure book, it feels like defprotocol is the right way to go, and just namespace the implementations. Does that sound right?

✔️ 1
Ben Sless05:11:41

I think there are only two reasons to prefer using interfaces over protocols - performance and exposing your code to Java. In any other case protocols, being more pleasant to work with, should be your goto. They also allow external users to extend the protocol to existing classes, while interfaces force them to define adapters. There's also a convention with protocols to not expose the protocol method directly but define a function which dispatches to it. You seem to be on the right track there


What is the current status of ? Is it's type checking speed fast enough for interactive REPL use ?

👀 1
Alex Miller (Clojure team)14:11:31

Typed Clojure was a PhD project and is not really in active development anymore afaik


That's not true, the author is still working on it, and is currently receiving funding from Clojurists Together.


I would ask your question in the #core-typed channel, the author could respond to it there.


The new development is here: and not in the old core.typed repo anymore. Here is the funding details


Is there a flag for clj, like clj -R some_file.clj where -R makes clj drop into a repl after running the some_file.clj. Therefore, in the repl, one can play with the variables defined in the some_file.clj.

Ngoc Khuat08:11:05

I don’t know about clj but you can use load-file i believe

Ngoc Khuat08:11:46

this is CLJ version : clj -i filename.clj --repl

thanks3 1
Alex Miller (Clojure team)14:11:57

That will give you a warning - should be clj -M -i filename.clj -r

🙏 1

Suggestion: Improved error message for macros when non-gensymed symbols in a let binding. Here's a macro that doesn't use a unique symbol.

(defmacro return-some-list [x]
  `(let [one 5]
     [one ~x]))
(return-some-list one)
; Syntax error macroexpanding clojure.core/let .
; user/one - failed: simple-symbol? at: [:bindings :form :local-symbol] spec: :clojure.core.specs.alpha/local-name
The syntax error assumes that the user knows what a gensym is, and that fully qualified symbols are not simple symbols. whereas a gensym-ed symbol is a simple symbol. Of the top of my head I think it would be more helpful to raise an error like "did you forget to use a unique symbol?" or "try appending symbol names in let with #"


I thing you can post it in but the error you're seeing has nothing to do with macro or gensym. Your macro expands to form with non-simple symbol inside of let bindings form. So let is complaining about it


if I prefix one with # it works fine.

(def one 1)

(defmacro return-some-list [x]
  `(let [one# 5]
      [one# ~x]) )

user=> (return-some-list one)
[5 1]


Right, # has special meaning inside of ` form


@U04V4KLKC yeah, it's autogensym. Which was what I was talking about. It would've been nice to have an error message saying so


Missing # at the end of the symbol is not an error during macro expansion.


> Improved error message for macros when non-gensymed symbols in a let binding. As others have pointed out, you don't need to use gensym for symbols in let bindings (although it's a good idea for hygiene in most cases). Making this happen would involve making syntax-quote have special knowledge of let, which may or may not be a good idea. And besides, if you really want one to be the name of the local, you can make it happen:

(defmacro f [x]
  `(let [~'one 5]
     [~'one ~x]))

user=> (macroexpand-1 '(f 1))
(clojure.core/let [one 5] [one 1])


@U883WCP5Z I know it's possible to have one as a local name. but the syntax quote is there to "protect" you from unhygenic symbols in let bindings. In fact before spec was introduced, you can see that it would raise an exception Exception: Can't let qualified name: If you tried to use a non-gensymed symbol in a let binding Here is a link from braveclojure showing this exception (I think the clj version is 1.7.0),each%20successive%C2%A0call%3A


Hello! May I ask where I can find good sample projects to use as references for organising a ring + integrant project? And may I know if is the goto way for ring/integrant related test? Or are there other things I might want to be looking at? Or any advice that would be useful? (:


hello to deploy on new group(a reversed domain name, from a domain that i own) on clojars, you have to send New group creation, an wait for an administrator to approve it?


yes. but your github login account's group will be automatically created / approved for you.


ok thank you : ) i did that i will wait

Bryce Tichit19:11:45

Hey everyone, just asked me a question today and would like to have your tought. It's 2 questions actually, 1. Would it be possible to host Clojure on the Go ecosystem? 2. Would it be worth it ? In other words would it be interesting in a Clojure point of view? My compilation knowledge is very basic but still I think that 1) should be possible. Go is way better than Java on many points, as well it's very easy to build binaries for most platforms in Go so it would not be such a disavantadge to switch from the JVM that you can "write once and run everywhere". As well for me I see that it would be much better to write interop in Go rather than Java. A first downside that I could see would be that, at least for now, the Go ecosystem and all of its libaries are not up to Java ecosystem. Which is normal because the JVM ecosystem is much older, but it should change more and more and at some point the Go ecosystem would match Java's one and this could benefit Clojure a lot. The second downside would be that every Clojure code that is dependent on Java interop could be totally or partially broken, but we already have ClojureScript hosted on JS and it's working great. So I don't really know if this is a big problem or not. All of these downside can be adressed but with a lot of work. What do you think? Would love to hear your toughts !

Bryce Tichit19:11:59

One thing that could make 1 impossible is that in the end Java is compiled to JVM bytecode that is in some way interpreted, as well JS is an interpreted language. This is not the case of Go that compile down directly to assembly. Maybe that could block things, my understanding is not deep enough to answer it


to answer 1) I'm sure it's possible given enough effort. for 2) Seems like a hard sell for me. What would be the main features from the go ecosystem that you would like to access? • As you mentioned, the java ecosystem has a huge number of libraries compared to go • the jvm ecosystem now has graalvm's native-image which is another way to address some of the jvm's weaknesses like startup time and memory usage • if you really need access to a go library, there is great support for ffi on the jvm • if you really need a clojure library in go, you can now compile a native library with graalvm's native image.

Bryce Tichit19:11:10

I did not know about graalvm, it looks amazing. I think it solve most of the JVM problem so you're right if this GraalVM thing is really working it's definitely not worth it to host Clojure outside of the JVM

Bryce Tichit19:11:29

Do you have any interesting articles to share about GraalVM? It's very interesting

Bryce Tichit19:11:10

As well is it easy to use GraalVM with Clojure?


I don't have any particular articles, but there is a #graalvm channel with some links. There are still some caveats when targeting graalvm with clojure, but it's much less work than re-hosting clojure on a new vm.

Bryce Tichit19:11:33

Perfect, yes completely agree on the fact that graalvm is an amazing solution to most of JVM problems and it's still new so it should become better and better to use it with Clojure anyways. Thanks a lot for sharing, with this it seems like that Clojure has definitely 0 disavantages

Bryce Tichit20:11:06

@U064X3EF3 Interesting I will have a look thanks a lot

Bryce Tichit20:11:01

Looks like this project has been abandoned, but I can understand why


@U02342WU2AK For a lot of people, the ability to use Clojure with the whole JVM ecosystem is one of its biggest selling points -- since you can introduce Clojure "as just another dependency" into any existing JVM-based project. That's how we introduced Clojure at work and started using it as "just a library" for our applications, and gradually writing more code in Clojure until it became our primary language.


I started on a lisp to compile to go years ago, largely because I was interested in the concurrency model, and it was an uphill slog, the go compiler is pretty strict (complains about unreachable statements etc) which can be annoying for code generation. It is also by design a very static environment (static linking, tree shaking, etc) which makes laying on a dynamic language trocky

Ben Sless21:11:54

Now that Go has dynamic linking and soon generics, such a project seems more viable Reference a dynamically linked lisp* in go:

Bryce Tichit22:11:09

@U04V70XH6 Interesting thanks for your opinion. For sure the only time I used Java was in University and it's considered a legacy langage and most of the people I know that are about my age will never think about Java to start a project. That being said it's very clear that the JVM ecosystem is widely used by a lot of companies, because in the end it's the ecosystem that has the most libraries. The magic of Clojure makes the JVM ecosystem appealing even to me because I can use a langage that I like and just pick libraries that already exist within JVM. So yeah definitely understand why using Clojure with JVM is a strong selling point !

Bryce Tichit22:11:26

@U0NCTKEV8 Interesting that you already tried to go this road, thanks for sharing 🙂 I think it may be a little complicated to adapt a dynamic language to a static environement as you say

Bryce Tichit22:11:09

@UK0810AQ2 Just looked at Slick, it's good that some people already did this kind of work ! Interesting project

Bryce Tichit22:11:32

Overall as always I learned a lot of things tonight, like always on this Slack. Thanks a lot for all the precious information !


We used and enjoyed the experience. @U04V15CAJ’s work however has made other pathways much more favorable to me personally.

Bryce Tichit22:11:42

joker is an interesting approach to scripting with Clojure thanks for sharing, which work of @U04V15CAJ are you refering to?

Bryce Tichit22:11:03

(I am still new to Clojure)

Bryce Tichit22:11:20

Are you talking about GraalVM related work? Looks like it's this


I started with Java in 1997. I've used a number of JVM-based languages since then, including Groovy, Scala, and -- for the last decade -- Clojure.


I am surprised to hear anyone considers Java to be a legacy language. I wonder what they mean by "legacy" in that context?


I expect @UDRJMEFSN means babashka and sci and perhaps a few other of @U04V15CAJ’s (many) projects?

Bryce Tichit22:11:22

@U04V70XH6 And since you discovered Clojure what do you think about the future of the JVM ecosystem? Would love to hear your toughts. About Java in itself, it's a very verbose language. It's complicated to do simple things without having to write a lot of code. But it's my own opinion, I'm 25 and I don't like OOP and imperative programming 🙂 But now that I discovered Clojure I understand more about the JVM ecosystem and its power, especially the libraries available. I have a better opinion about JVM languages now


Regardless of Clojure, the JVM ecosystem is going to be around for decades, running a lot of mission-critical software for a very large number of companies.


Yes, Java is verbose. It's gotten better over the years -- but it's always going to be more verbose than, say, Groovy or Scala or Kotlin or Clojure...

Bryce Tichit22:11:35

Yes, completely understand that. I don't know myself any companies that use JVM but know that it's widely used. I think it's mainly used by bigger companies, which represent in the end most of the companies.


@U02342WU2AK - #babashka, feel free to join and ask questions.

Bryce Tichit22:11:40

@U04V15CAJ Amazing project, joining the channel now 🙂

Bryce Tichit22:11:58

Congrats for the amazing work !

Ben Sless04:11:53

I don't have that much experience in the industry but from the impression I get java is often the language services get rewritten in after initially being developed in Python. There are also plenty of new new features getting into the language which can make it either an appealing enough prospect or just more tolerable. The ecosystem is another aspect, but another important one is the platform. The JVM itself has top notch GC and JIT. So the JVM becomes an appealing notion, too. Add to that big data processing will probably require a cluster of JVMs, that stream processing frameworks are rich and strong on the JVM land, and you find more reasons why companies can invested in it. From the perspective of verbosity, I'm still waiting on an explanation of who though err != nil was acceptable

Ben Sless11:11:52

Therefor, technologically I feel pretty secure in hitching my carriage to the JVM platform, and personally I absolutely love Clojure and wouldn't want to use another language