Sometimes I wish I wasn't such an early bird

Hey, it means you get to chat with me before I go to bed in California @dharrigan! 🙂

🙂

Well, only thing to report is that I'm looking to deploy clojure code into our live environment for the first time EVAR today

I'm hopeful that in a few years time, I'll look back at that codebase and think - ehhh? what was I thinking? Since I hope my skills/experience will have improved by then 🙂

Very cool milestone!

I no longer remember our very first production deploy that included Clojure... 2011... Spring... Clojure 1.3 Alpha 7 or 8, embedded into our legacy apps. But we had a lot of other stuff going on that meant Clojure was sort of the least of our worries back then.

These days, our production deploys are mostly "meh" which is a good thing 🙂

meh is good

The MD is interested to see how this goes. I'm having to maintain a functionally equivalent Kotlin version, you know, just in case....

I'm hopeful I won't need it - as my tests show that my Clojure version produces the same results as the Kotlin version

Plus, there's a bus factor of 1 here

So until that changes (which it will!) then I have to do that.

I see that Rich is coming to Lawndawn this year.

Oh cool! Is that for the PL conf?

I guess it would be far too much (imposing) for him to give a small 30 minute talk to London Clojurists whilst here?

You know, to inspire the community

It never hurts to ask 🙂

Tis for this https://hopl4.sigplan.org/

I'm looking forward to the transcript/video of his History of Clojure talk from that. I know he's been researching it heavily for a while -- Alex has been reaching out to folks to confirm historical details etc.

I've reached out to Cognitect to see if there might even be a possibility of a small meetup chat from Rich

Let's see!

If there was one thing you could say to your younger self, as you embarked upon writing production Clojure code, what would that be? Any particular style, methodology, functions to really learn?

Hell yeah: avoid global data! Pass all that shit through the call chain instead!

We figured, back in 2011, we only have a fixed set of data sources so we'll just stick them in atoms in and initialize them at startup. That was a terrible idea.

We built huge call chains on top of that where the data sources are implicit, and only hardwired into the bottom layer.

When we started to want to switch code from the master to the slave, or to a different DB account so we could leverage different access permissions, we got into a world of hurt.

And we did it with our caching layer too -- but that wasn't so painful: we have only ever needed one set of caching logic and we built in multiple named caches from the get-go so... yay, us.

So, avoid global state

🙂

I've spent a lot of the last several weeks refactoring code to remove those globals. I'm still only partially done.

In my codebase, I have one atom, that's when I define the datasource. I keep it in it's own namespace txi.higgins.db and all SQL queries etc., all go through that namespace.

Fine for MVP launch. Won't scale. So plan to refactor away from that pattern before your code gets any more complex.

so, the callees never see the datasource.

Sure, I'll look to refactor definitely - it's as much a learning experience for me as getting a MVP out to prove Clojure can be used at work 🙂

(and I'm still very much a newbie...)

Funnily enough, Clojure has given us a "magic power" that no one expected: the ability to apply critical patches to live, running, production processes with zero downtime 🙂 Via a Socket REPL into production. Not something we'd really planned on -- and not something we do very often.

Most of our processes are clustered so a rolling, automated redeploy is our normal procedure.

Right, that was in mind this morning (strange things when one wakes up at 3:30am)

Does the socket repl need to be running when the application is launched? It's not like you can "attach" to already running Clojure application magically?

But we have one app that is used internally and downtime is a major issue during work hours -- so being able to patch that via a REPL is amazingly convenient.

Well, you actually can attach a REPL to a process that was started without one -- but that's a security problem and you should have it disabled (Bing for "jvm attach security").

so, having a switch (say environmental, or runtime configuration) that would create a listening socket repl on the server application (if appropriate) is the answer - i.e., only enable listening if the computer says yes.

So we have a JVM options file that is picked up by our daemon script that starts/stops services and we add a Socket Server option to that as needed. Some processes have that enabled all the time, others only when we need debugging (and we're happy to restart a process).

right right, same approach 🙂

It's literally a -D option on the JVM.

Why choose a socket repl over a nrepl?

any advantages?

Socket REPL is built into Clojure -- no dependencies. You can start a Socket REPL in any Clojure process (or Java app that includes Clojure as a dependency!) just by adding a JVM option.

And I sort of despise nREPL as a protocol 🙂

right right

We used to start nREPL with middleware in some of our processes but I always hated having that as a dependency.

I was super happy when we dumped all of that and switched to a basic Socket REPL -- for both dev and production.

I'm going to experiment with that today

i.e., run my app in a docker container, expose the port, enable the socket repl (via a feature toggle on the app startup) and see what I can do 🙂

I use Atom/Chlorine so a Socket REPL is all I ever need. My team mate uses Emacs and, I think, inf-clojure mode or something similar so he also avoids nREPL.

How about pREPL?

that came with 1.10

That can be started with a JVM option too.

I use that with my editor (nvim + Conjure)

Basically it's a Socket REPL with a different listener.

cool - eager to try this out

so, say you want to redefine a function on running code, you in-ns '.... to the namespace and redefine the function (or def...)?

Yeah... I mean, Chlorine does that behind the scenes, so I can just put my cursor into an updated version of the code in that file and ctrl-; B and it evals the top-level block (form) into the Socket REPL which, yeah, does the in-ns and the defn

And I can use RCFs containing code to explore/debug things in a production context.

awesome

Conjure does the same - you can eval a buffer etc..

For me, production is identical to (local) development in that respect -- and so is our QA/showcase server since it also runs Socket REPLs.

neato

Yes, that makes sense, it's all network based anyway

so no difference between your editor and the clojure code on your machine, and your editor and the clojure code 1,000 miles away in some data centre.

The only difference is that locally I run my REPL in a context that has the add-lib branch of t.d.a. so I can load new dependencies on-the-fly.

(maybe a bit of latency...) 🙂

I hope Alex considers adding in add-lib

it's pretty handy

But once add-lib lands in a non-alpha context, I'll probably run that in production too... just in case I ever need to make a code change that requires a new dependency be added.

(but I'd prefer a rolling deploy via our automated system with an updated uberjar!)

Given that we can have a change committed to git be deployed to production in just a few minutes already...

so, if you make a change to production code, and it works, you then commit that code into your repo and shortly afterwards your application in production is updated with the fixed code (officially)

For all but one app in production, yes.

kewl

I'm going to demonstrate that on my Friday Sessions

where I show some Clojure stuff

We have one legacy app that is not all Clojure and that still requires a manual deploy process 😐

Ooops, the kiddo is stirring and calling out for me

Laters!

Time to attend to fatherly duties!

I'm about to head to bed anyway...

🙂

thanks sean, a doppo!

(once I've finished my beer)

🙂

ttfn

.

måning

Morning!

morning

Morning

So, I have a very small chance of introducing Clojure/ClojureScript on our team, for whitelisting. We whitelist people and services (e.g., allowing one service to call another) using properties of SSL certs (emailAddress, OU). Right now we're manually writing this data structure in JSON, but it's too easy to make a mistake. Was thinking of suggesting a small bit of Clojure, using Spec to validate the relationship between all of the moving parts (access groups, consumers, etc.). We'll probably end up doing this in Node or Scala, but spec seems like a big advantage. Another possible one: can you use something like cljc to generate both a JVM library and a Node library from the same code?

Following on from the conversation I had with Sean this morning (vvvvvery early this morning). I tried launching my Clojure process with the JVM arg running a socket repl listening on port 55555. Anyone had experience of doing this within a docker container? Even although I'm mapping the ports, when I telnet (to kick the tyres) to the local port, I don't get a connection

I've officially reached the end of my tether with windows / c# / powershell

Morning 🙂

o/ Do any of you guys know of companies with open positions for a QA engineer? An excellent QA I've previously worked with is looking for immediate employment in London.

I will ask my boss

Would the person be willing to travel to Epsom?

it's about 40 mins from Waterloo, going out

Thanks! I'll ask about the location. It's less of a question of willingness (which there is) and more of school/childcare hours.

sure

let me know

The potential opening for Clojure in my team (described above) came to naught. We'll do something with Python instead. I'd love to try to interest some people in our team to try Clojure, because I think they would like it, but there's an immediate, knee-jerk reaction to lisp syntax that I can't seem to overcome. Does anyone have any success stories about getting Clojure adopted by a team? What kind of project did you try first? We're a Scala (back)/React (front) team and I think that might have something to do with it -- adopting both was a big deal and took quite a long time. Clojure, on the other hand, you could learn 90% of it in a day or two and the Scala developers (we write it purely functionally) would understand most of the other 10%.

I have

We are mostly a Kotlin/Python/Javascript shop

In terms of project, the one I'm getting into our production is a very isolated, read from kafka, write to database application

I also maintained a functionally equivalant kotlin version - just in case

but our boss has given me the go-ahead to see how it goes 🙂

and he's also open to hiring a programmer 50/50 split between kotlin/clojure

also, I did a few (still do) friday sessions where I show clojure stuff

so, I just kept on-and-on-and-on-and-on about it 🙂

Like Mrs Doyle 🙂

ah...go on!

I also wrote up use-cases where it fits into what we do (we process large amounts of data per day)

and hyping on about immutability, easy concurrency/parallelism etc.. basically the selling points of clojure

.

One of the issues for us is that the gap between Scala and Clojure is a bit smaller -- we already do functional, immutable data and have quite high-volume concurrent services. I'm working on a 10%-time project (we can work on whatever we want one day every two weeks), but it's quite a big project and it'll take me months. So, I'm happy (I get to work on Clojure), but I do think Clojure could solve some of the problems we're having -- like on-boarding new developers into Scala. It's a real bear of a language.

isn't the clojure/python Bridge very much alive and kicking? Karin Meier keeps tweeting about it

My own opinion of course, but I think Scala is sorta spining atm until Dotty comes out

I also find that scala code can be very hard to read

I heard that the python bridge is awesome

saw a demo

does it create a bit of wiggle room on those python projects?

It's a good point,

Those Scala/Clojure races seem to come down to culture, you can write impenetable spaghetti code in both languages but it seems more acceptable to the Scala community to do so

dunno, is that unfair?

You can write spaghetti in any language, but I don't think that's the case here. We even go out of our way to write Javascript using a functional style, which makes this fertile ground for a much simpler functional language. For us, I think it would fit in quite well for projects just above what we use Python for (mostly scripts) and around where we do Node.JS servlets or Scala microservices.

if you've got people getting hung up on syntax that's a hard problem - i've encountered that before and it's not generally a rational objection, which makes it very hard to counter with a rational argument

You know what, I've seen kotlin code wrote very badly

yeah, it's possible I've actually poisoned the waters a bit too -- I'm the only Emacs user amid a sea of Intellij/VS Code users (so strike one), have a greying beard (strike two) and have showed people various features I've added to Emacs over the decades (strike three). Lisp? Yeah, that's something Santa Claus uses...

so I 100% agree with @mccraigmccraig

if it's just syntax, you're on a loosing battle anyway

Santa Claus is efficient (he sees all the good little boys and girls - billions of them each year), he's parallel and concurrent - he's always predictable and reliable and he's good fun!

I would be proud to equate clojure to santa claus 🙂

oh, and all the world (mostly!!!) loves him 🙂

Apart from in NL where he's a bit racist

(but they still love him)

that is not Santa Claus, but Sint Nicholas. @conor.p.farrell

ooh and a 19 day difference.

@eamonn.sullivan: > Does anyone have any success stories about getting Clojure adopted by a team? Sure. About 6 years ago I joined a startup with an existing ruby code base; and convinced the CTO to do the heavy lifting on the JVM (mainly because the best libraries for our eco-system existed in java), and because ruby was slow for handling large quantities of data, and that farming out jobs to remote external services was creating ops problems we didn’t need at our scale. i.e. we were using job queues because we wanted concurrency which ruby is poor at, not because we needed distributed computing & parallelism. Also he knew I had a lot of clojure experience anyway and had used it in many previous projects, and he was a geek and was convinced by rich hickey’s arguments etc.. fp, lisp, immutability etc. So we wrote some backend stuff in clojure; which worked really well and is still operational and under development today. And have written gradually more and more apps, libraries, tools and services in it. We’re now using it for almost everything, and have about 10 people coding clojure full time. Legacy ruby app is now being rewritten and replaced. We use clojurescript too for most but not all front end work. Regarding the syntax objections; syntax I’ve usually successfully argued with people that syntax is much less important than semantics and simplicity. Once they agree to that; then you explain the semantics of clojure syntax (takes about 10 minutes for most of it (clojure 1.0 syntax at least - the syntax has grown a bit more in recent years; but still fundamentally the same). I’ve never encountered anyone who hated the syntax after having such a discussion; and also being shown the capabilities it enables, e.g. paredit/smartparens/macros etc.

@eamonn.sullivan Macros are, in my experience, the best way to get people to realise that clojure (or more widely, lisp), syntax is not just perfectly fine, but the absolute best way to do things. Once people grok the whole, "code is just data, and data is malleable", they fall in love with the syntax quick-sharp. Depending on the organisation culture, you might want to consider putting a little internal, "fans of clojure" group together, or propose some kind of "show and tell" thing. People generally respond this this very well, particularly when you end it with a github link that they can peruse and play with in their own time.

I do find, much like with any other "product", it is the peripherals that "sell" it. Working in the REPL for example. I don't know any other language that does this even half as well as Clojure does, and a big reason for that is the syntax, or rather the relative lack of it.

Morning. @eamonn.sullivan I can't claim to have had much success in getting Clojure adopted, though not for want of trying - which probably says more about my persuasiveness as a salesman than about any putative shortcoming of the language. I went so far as to found a functional programming "guild" (not Clojure-specific) at one employer, in the hope of winning converts (which I had imagined might be an easier sell in a largely Java/JavaScript house). The reasons for failure seemed to be a mix of those frequently mentioned: • Parentheses ("Man, that just makes my eyes bleed!") • Unfamiliarity (people saw value in the features, but wanted equivalents in their comfort zone) • Fear of dynamic typing • Unwillingness to invest in what is perceived as a "niche" skill Even macros didn't seem to persuade anyone ("I can't think why I would need to do that"). The time that I felt closest to persuading someone was when a colleague saw me using Figwheel with a browser-connected REPL - so I'm inclined to concur with @wesley.hall that tooling might be the best route. I currently use Atom with Chlorine for Clojure development (having followed @seancorfield’s excellent set-up guide), and I can imagine that winning people over, too. Other than that, I'd guess it's an easier job with a greenfield project or a rewrite from an ecosystem whose shortcomings have become apparent. :face_with_rolling_eyes:

Aye, I think a good REPL-driven workflow, showing that really tight feedback loop, and showing how you actually develop "in" the REPL, is about the most persuasive thing I've seen so far in terms of making folks go "Wow, that's cool! And that's Clojure, right?" -- but even then your point #2 is a common comeback "How do I do that in <language X>?" and they often don't believe that you can't...

When I brought Clojure into World Singles Networks, I cross-trained two CFML developers (yes, really) and they mostly loved Clojure but felt the learning curve was very steep on the switch from imperative/OOP to FP. After a few years one left to go back to CFML at another company (and still does CFML as far as I know) and the other left to take some family time and then went to work for another Clojure shop. So I'd call that sort of 50% success 🙂

Most everywhere I've worked I've been able to bring in some sort of new tech, even if it hasn't always been a new language, but I've been in the industry about 35 years at this point and I've been some variant of "Senior Software Architect" for the last 20 of those so companies sort of expect me to move the needle in terms of tech...

programming also advances one funeral at a time