This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (17)
- # beginners (33)
- # calva (9)
- # cider (2)
- # clj-kondo (17)
- # cljs-dev (2)
- # cljsrn (2)
- # clojars (3)
- # clojure (60)
- # clojure-australia (2)
- # clojure-europe (8)
- # clojure-gamedev (5)
- # clojurescript (27)
- # cursive (2)
- # emacs (9)
- # fulcro (8)
- # gratitude (5)
- # lsp (41)
- # malli (3)
- # meander (18)
- # pathom (5)
- # polylith (25)
- # re-frame (17)
- # reagent (1)
- # rewrite-clj (6)
- # shadow-cljs (11)
- # uncomplicate (5)
- # vim (6)
- # web-security (5)
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
defprotocol`` in different files, then just require one or the other without rewriting the calls.
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?
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 https://typedclojure.org/ ? Is it's type checking speed fast enough for interactive REPL use ?
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: https://github.com/typedclojure/typedclojure and not in the old core.typed repo anymore. Here is the funding details https://www.clojuriststogether.org/news/september-2021-monthly-update/#typed-clojure
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.
I don’t know about clj but you can use
load-file i believe https://clojuredocs.org/clojure.core/load-file
That will give you a warning - should be
clj -M -i filename.clj -r
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.
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
(defmacro return-some-list [x] `(let [one 5] [one ~x])) #'user/return-some-list (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
I thing you can post it in http://ask.clojure.org 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
# it works fine.
(def one 1) (defmacro return-some-list [x] `(let [one# 5] [one# ~x]) ) user=> (return-some-list one) [5 1]
@U04V4KLKC yeah, it's autogensym. Which was what I was talking about. It would've been nice to have an error message saying so
> 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)
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 https://github.com/ring-clojure/ring-mock 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.
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 !
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.
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
Do you have any interesting articles to share about GraalVM? It's very interesting
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.
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
https://www.redpill-linpro.com/techblog/2021/03/31/faster-clojure-with-graalvm.html Just read this article, amazing read on using Clojure with GraalVM
@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
Now that Go has dynamic linking and soon generics, such a project seems more viable Reference a dynamically linked lisp* in go: https://github.com/pcostanza/slick
@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 !
@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
@UK0810AQ2 Just looked at Slick, it's good that some people already did this kind of work ! Interesting project
Overall as always I learned a lot of things tonight, like always on this Slack. Thanks a lot for all the precious information !
joker is an interesting approach to scripting with Clojure thanks for sharing, which work of @U04V15CAJ are you refering to?
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?
@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...
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.
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