for now I will just convert it all and select from it`(reduce-kv #(assoc-in %1 [(keyword (namespace %2)) %2] %3) {} fields)`

Not sure I fully understand what you want, but if you retrieve items from a map fewer times than there are items in the map, it might be better to just convert the keys you're using: (keyword (name :article) (name :keys)).

What does fields look like?

You want to get the subset of a map that belongs in a specific ns, is that right? e.g. for

{:foo/bar 1
 :foo/baz 2
 :bar 3
 :baz 4}

{:foo/bar 1
 :foo/baz 2}

(defn select-keys-of-ns [m ns]
  (into {} (filter #(= (name ns) (namespace (first %))) m)))

(select-keys-of-ns {:foo/bar 1
                    :foo/baz 2
                    :bar 3
                    :baz 4
                    :zoo/baz 5}
                   :foo)
;; => #:foo{:bar 1, :baz 2}

Watchers are always run in the same thread that's doing swap!/`reset!`.

Ah, that explains it all. Is there a way to pass control over to the main thread again? That is what I hoped to do by just updating an atom.

Yes, something like: Instead of calling reset! from the callback, just do:

...
    (read-process bb-process :out jobid)
    (.get jobfuture)
    (reset! app-state/jobresult [jobid (.exitValue p) job])))

I don't know what you're trying to achieve, but feels like you're overcomplicating things. What are you trying to achieve exactly?

I want to start bash jobs in futures and when they are done I want some result processing to be done (in the main thread).

Do you need to start multiple jobs in parallel? Why is it important that you do your processing in the main thread specifically?

1. Yes. 2. To simplify debugging. When errors happen in futures they just seem to disappear.

Regarding errors - this is a good read: https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions I'm not sure whether Thread/setDefaultUncaughtExceptionHandler applies to completable futures (probably not), but you can experiment and figure out. In either case, it's always a good idea to call some form of get on all futures, or join or what have you, exactly for correct error propagation. If you deal with that correctly, then suddenly you don't care about watchers being run in different threads anymore.

And if you want to wait on multiple futures, you can either store them all in a non-lazy collection and then iterate and get each one, or you can use allOf: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#allOf-java.util.concurrent.CompletableFuture...-

I can't really answer your question, but FWIW I'm personally very hesitant to pick up Rust for anything involved, mainly due to posts at https://drewdevault.com/ (you can search for mentions of Rust there - not just in titles though). In particular, Rust is too big and it's getting bigger, and the rate at which it happens is far larger than I'd like.

This write up is well done and fun: https://gist.github.com/oakes/4af1023b6c5162c6f8f0

I like Rust but definitely still prefer the simplicity and interactive repl style development of Clojure. But if I had a need for no GC I would reach for Rust as it did feel I could punch above my weight for such tasks. I don't trust I can do it safely in C (and C++ but I haven't tried that one).

@U2FRKM4TW: Thanks for the link! I got a good chuckle out of this quote from one of the posts: > "Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language."

@U9J50BY4C: Thanks for chiming in, and for sharing that gist! Looks interesting at a glance. I'm going to read through it more carefully later this evening after work.

I believe @U04V15CAJ (a highly prolific Clojurian) has explored Rust for some things recently so he can probably give you a more up to date comparison if he doesn't mind me calling him in here.

Rust and Zig kind of serve in the same domain. Zig might be more aligned with the Clojure philosophy whereas Rust is more like Scala (big on the type system to guarantee correctness + safety).

An interesting topic I think between the two is how Clojure avoids the problems of state and mutation through pure functions and immutability while Rust approaches it through the borrowing/ownership rules (preventing shared mutable access to a variable). I think this was explored a bit here: https://without.boats/blog/notes-on-a-smaller-rust/

But Rust is useful for probably a pretty different subset of applications than Clojure.

@U01PE7630AC I've spent many years with Clojure. I've also spent about a year writing a lot of Rust, trying it out for a personal/startup project (I ended up deciding it wasn't a fit for my needs). I haven't written anything on the topic, but can say a little now, and answer any other specific questions you might have. I'll simplify with bullet points. - Speed: Rust is generally accepted to be faster than Clojure. Personally, I've rarely ever needed something faster than Clojure (because Clojure is fast), but in this case I thought my needs might be extreme enough to warrant Rust (or C, C++, zig etc). - Memory Safety & Concurrency: Rust's approach (ownership&references) is completely different from Clojure's (ex atoms). Rust's approach is (almost always) enforced by the compiler. It creates (for me at least) a HUGE learning curve, which might be insurmountable if not for Rust having by far the most helpful compiler error messages I have ever seen. Tangent: Everything around the dev experience (quality of tooling, package mgmt, docs, compiler error messages etc) is EXCELLENT. Overall, Rust has done those things better than any other language I've ever worked with. - Macros & Metaprogramming : Rust's macros are hygenic, making them completely different than Clojure's. I found them easy to work with for simple things, but too difficult for more complex things. Technically, I believe Rust and Clojure macros to have about the same capabilities, but to acheive anything beyond simple requires delving into complexities that I didn't want to get into. - Re: borkdude's comment: "But Rust is useful for probably a pretty different subset of applications than Clojure." That is how I see it, but I would say most in the Rust community would disagree -- they want to use Rust for everything. I think they are lunatics. But, I think most choices that (non-Clojure) programmers make are completely insane, so... - When would I reach for Rust? Only as an alternative to C/C++; when Clojure is just not a fit. WebAssembly is an interesting case here -- Rust's capabilities there are very good. But, if I'm doing any sort of work where the JVM and/or javascript is appropriate, then, hands down, I am reaching for Clojure/clojurescript.

I did rust for a few months and very much agree with all of that

also a big ➕ for "Rust is more like Scala"

OH and... not having paredit (or similar) is infuriating

Interesting thread, but would it be better in #other-languages?

Maybe, but at least it is all in a thread 🙂

Since the comparison to Scala came up, the big question I have with Rust is if dependencies are handled better than with Scala. Everything I’ve written has been small and self contained, so I haven’t had to depend on much yet, and crates have been easy for me to work with. I figure that it’s somewhere in the midpoint between the ease of Clojure, and the disaster that is Scala.

Rust is source based, whereas Java/Scala deps are usually byte-code based. You always compile all the sources on your own machine, so no binary compatibility issues.

There is no VM in Rust-land and no IR

at least not exposed

Yes, that’s the compelling reason to use it

(I read something now about MIR but I don't think that affects what I said about deps)

But I’ve had to deal with dependency issues with C/C++ projects in the past, which is why I was thinking that it the difficulty might be somewhere in the middle

@U051N6TTC: Thanks for pointing that out! I was not aware of the channel #other-languages until you mentioned it. Noted for future posts! I apologize for instigating this in the wrong channel.

@U051N6TTC it's pretty straight-forward https://doc.rust-lang.org/cargo/guide/dependencies.html

and having a lock file that includes all dependencies and transitive dependencies means it's repeatable, too

and more on the lock file https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

Rust was one of the "learn a new language every year" experiments for me (well every "year or two" 🙂 ) and as someone who spent a decade doing C++ (in the '90s), I think if I had to go back to that sort of problem space -- systems programming -- I'd be happy to use Rust for it. But I'm also thankful to have escaped that space and that, since my C++ days, my arc has been Java -> Groovy -> Scala -> Clojure so I don't have to worry about memory management, etc. I think Rust is a very impressive language -- in many ways, it is what I had hoped Go would be (an earlier "learn a new language" experiment) -- but right now there's no problem on my plate that I can't solve with Clojure (and feel happier while doing so). I do worry about Rust's speed of expansion/development as a language tho', as others have mentioned above.

@U02N27RK69K Yes, I’m aware. I’ve used it.

oh, I misread your comment then 😅

my apologies

Go and Rust are very different. Personally I would only use rust in cases where I cannot afford the use of a GC. Then about golang, you can be somewhat productive in a matter of hours with it, with Rust it takes a bit more effort.

Cool discussion. But I feel Clojure is best qualified as FUN AS HELL. And if you don't find that true, then that's that, use something else. And from that angle, it doesn't really matter if another language has compelling features lol, unless it were to be EVEN MORE FUN! Personally, I've struggled finding anything as fun as Clojure that doesn't provide similar or better interactive development and capability for extension (with easy macros, function closures, protocols, late binding, etc.) The fun for me comes from the live interactive development workflow, the ease in navigating the code (like someone else said, pareinfer and company), and the ability to try out almost anything since the language can easily be extended for whatever crazy fun things, as in trying all kind of new constructs and ways to model and tackle problems. Rust kind of fails on both, but especially on the former. Now it can be debatable if Rust is functional as well. Depending on which FP we're talking about. But Rust does not lean on pure function, immutability, recursion, laziness, and all that. Though it does have closures and being able to pass function as values. Yes its types can bring back some of the guarantees, but the feel you get from using it is different, because it achieves independence between function using another strategy than immutability. And that means it also offers imperative looping which require mutation, etc. Apart from that, I'd be repeating what others have said. It's weird to compare the two, since their runtime is so different. When you can afford managed memory, Rust seems like just a pain in the **s. Why deal with all those type constraints if you can happily have a GC.

Really cool stuff. Watching your video now :thumbsup:

I'm not sure if it applies in this case, but you can usually substitute commas for whitespace. Can be a bit hard to read, though.

my guess, based on https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/325506 is that when using the java version you are using a jvm packaged by a third party, and when running on the clojure version you are using a jvm that debian packaging has fiddled with

Not the same JVM instance, but the same JDK-11 (Amazon Coretto). However, I start both processes without any arguments or JVM parameters. The thing is, my app is deployed as datomic ion and I have no control (and no idea) how and with what params it's actually run. That's why I need to load the library from a relative path at runtime in the first place. And if it has any additional, transitive deps I need to place them in my projects resources as well later

@U012ADU90SW, Is this a c library or a c++ library? fwiw, the c interop libraries based on JNA and project panama are sometimes easier than using java wrapper libraries: • my go to library, https://github.com/cnuernber/dtype-next/ • I've used https://github.com/Chouser/clojure-jna/ a few times and was happy with it • uses project panama, https://github.com/IGJoshua/coffi

It's a C++ library and the Java wrapper is provided by the vendor. I'm just trying to use it. I'm currently using dtype-next for other stuff in my project and absolutely love it! coffi looks great, but I'm stuck with JDK11 for the time being.