it’s really well done 👏. Sublime 4 is so refreshingly fast that I’m almost reconsidering my current relationship.

Sublime has been my go-to text editor of choice since at least 1.0, simply because of its speed. It starts faster than the built-in Notes app on my mac.

I use vim now, but if I was teaching code (clojure) to someone, I now think I would throw sublime back in the miix

Looks super sweet! I love that he makes the case for #nrepl. It is such a wonderful piece of software!

so many great options now. it's very different to when I started with slime and swank in '12. what a great community 🙂

👍:skin-tone-2: For ! FWIW, I responded to some of the points regarding Tutkain over at Reddit (https://www.reddit.com/r/Clojure/comments/rflhxf/comment/hoi250s/).

@https://app.slack.com/team/U4ZDX466T thank you for writing this up! What are to-go REPL choices for CLJS today? I’m afraid I’ve been out of touch for too long and they change it again?

@tonsky I think shadow-cljs is the most popular choice, then Figwheel. Figwheel's nREPL integration is powered by Piggieback, I believe, and shadow-cljs has its own thing. Back when Tutkain targeted nREPL, I tried setting up a ClojureScript REPL using the simplest possible Piggieback configuration and failed to come up with a usable setup. In any case, with Piggieback, you must always first connect to a Clojure REPL before you can turn it into a ClojureScript REPL, which I don't want to do. There are times when I just want to connect to a ClojureScript REPL. I also feel like Piggieback does not offer a particularly beginner-friendly experience, generally speaking. What I'd really like to have is a ClojureScript REPL experience that is as close as possible to the kind of the Clojure REPL experience Tutkain and Sublime Clojure have: tell your editor to connect to a socket port and voilà, you're off to the races. (Of course, with ClojureScript, you also have to spin up a JavaScript runtime and so on, but still). Tutkain actually has that, but it only supports shadow-cljs, sadly. I would really, really like to have a ClojureScript REPL thing that's build tool agnostic, but it is sadly not possible. ClojureScript itself does not have support for an editor-connected socket REPL, and even if it did, simply having shadow-cljs in the classpath would prevent you from using it. All in all, if I were to begin building an editor-connected, build tool agnostic ClojureScript REPL on top of nREPL (with support for symbol info lookups, auto-completion and other runtime querying), I'm not sure where I'd begin. With shadow-cljs, using shadow.remote would be your best bet, but it is obviously shadow-cljs specific. You might be able to build some sort of abstraction that wires up shadow.remote for shadow-cljs and does something else for Figwheel etc., but that'd be quite a bit of work, I think.

All that said, I know plenty of folks use nREPL-based ClojureScript REPLs successfully every day, so maybe this is just me being somewhat particular about the whole thing. I guess to me it all just feels way too complicated. 🙂

From a UX point of view, I don't really care about connecting to a CLJS REPL directly either. I want to "connect to my project", and somehow have that magically mean that I'm connected both to CLJ and CLJS as necessary, and have things eval in the correct place depending on which file I'm in. This is not trivial, of course, and .cljc makes that ambiguous as well. If I remember correctly, both Proto-REPL and Chlorine handle this pretty well. Our current setup is to start the Shadow server with Integrant, which exposes a socket REPL and an NREPL (so that either can be used, based on editor/preference), then use shadow/repl <build-target> to get to CLJS. Using Shadow gives us access to build control via the REPL, as well as provide a nice dashboard and tap target on port 9630, etc.

> From a UX point of view, I don't really care about connecting to a CLJS REPL directly either. I want to "connect to my project", and somehow have that magically mean that I'm connected both to CLJ and CLJS as necessary I do care about connecting to a CLJS REPL. There are ClojureScript-only projects, too. And I definitely want no magic. 🙂 I'm with you on the editor having to know whether to evaluate Clojure or ClojureScript, though (which Tutkain does as well: https://tutkain.flowthing.me/dialect.mov).

If it's a CLJS-only project, then it's obvious that you want to connect to CLJS. I think the point stands. It's not magic (poor word choice), it's just about how closely you can model the intention of the person using the tool.

You know, "magic", in the sense that things that are frictionless in places where friction usually is encountered can feel like magic. (Until you get acclimated, and then the previous friction spurs anger when it's encountered again. Clojure itself is an example of this with regards to certain aspects)

Right, I think I understand. Something like that might make sense if it could be neatly composed of existing functionality. But to me, connecting to a Clojure(Script) runtime with Tutkain (or something like Chlorine, I think, although I've only tried it briefly) already has so little friction that I don't see it as a huge priority. Anyway, although I feel like saying more, I'm slightly worried we'd be veering a bit too far off topic. 🙂

Thanks for the heads up 👍

Thanks, although judging by the post the issue is a bit overblown. When attacker has write access to the code (this is where config files are), the system is already compromised enough for this vulnerability to matter IMO

something like this allows an attacker to easily establish a remote shell while not disrupting the running services otherwise. it's not overblown, it's just not as trivial to attack as the log4j vulnerability. a lot of hacking is moving horizontally, combining multiple stages of vulnerabilities to establish persistent access. the fewest changes an attacker can make to establish a permanent foothold, the better (for them).

and writable configuration files don't necessarily mean writable application files, especially if the vulnerability you're using to rewrite files can only rewrite plaintext

I tend to concur with Vlad here, the authors in their post of the vunerability have not deemed it as a critical vunerability. It takes an existing compromised system to exploit this one, and whilst there is merit in getting in via the "back door", if you have that level of access to a system running with logback and a writeable file, then you have bigger worries than the one here. Naturally, practicing caution is good and ensuring you update to the latest library is a given, but it doesn't have the same criticality as the log4j exploit.

I never said it has the same criticality of the log4j exploit, I even said it was harder to exploit

they're urging everyone to update as soon as possible and have ripped out functionality wholesale because it's so dangerous. I guarantee you people taking the OSCP in years to come will be checking for this vulnerability as a relatively easy way to get a reverse shell. it's a big deal. so 1) they want everyone to update as soon as possible, and 2) it's a really big deal. I call it critical and I'm out of line? come on

The news item on the logback home page , even says that this exploit and the log4j exploit are "....uttterly different severity levels".

yes, I said it was harder to exploit

it requires you chain vulnerabilities

it still gives you a remote shell and was deemed dangerous enough to rip out wholesale, by the software authors you're pointing to for judgement on how critical the bug is

Right, totally agree, but in terms of announcing to the community that this is a "critical" update, when no such mention of the word is used, and that it requires chaining of exploits, is I feel unduely panicy.

the software authors are urging everyone to update as soon as possible...

I agree there, like any good author of software that has a security vunderability, that is totally due diligience.

like even by the authority you're pointing to it's something to handle as soon as you can

But they would say the same if it even had a minor vunerability, or major, or omg, the world is about to explode if you even run this software.

look: this argument is really boring and I'm grouchy. if you want to make another post with whatever language you want to use then go right ahead

Naw, I'm tired too.

¯\(ツ)/¯

your comments are here for the record, people can see there's a big thread

it's all fine

yup 🙂

nice! in case you didn't know, you could add highlight and marked to a deps.cljs file so they get installed automatically

Thanks! I only thought about it in passing, will have a closer look at the details with the next opportunity, feel free to raise a PR in the meantime 🙂