Appcanary eliminated Clojure code - porting functionality back to Ruby

I thought some of the resident Ruby developers might find this interesting. Ultimately the “why” is more interesting and elaborated in:


(RubyConf Cincinatti 2016 - To Clojure and back: writing and rewriting in Ruby by Phill MV)

It’s kind of a “my educational journey out of my comfort zone and back” account.

Listening to his “how Clojure has affected my Ruby code” makes me wonder if he ever knew about Brian Marick’s (5 year old) videos Three Functional Ideas for Ruby and Some Thoughts on Classes After 18 Months of Clojure.

(No - I don’t think they want to hear about Elixir right now).

3 Likes

At work currently, can anyone summarize why they left Clojure?

2 Likes

Some key points here:

To quote the opening part of the top comment,

The key criticisms of Clojure seem to be in the “death by a thousand papercuts” section starting at 14:00:

    not clear how to structure large apps
    fun to write, can be difficult to read ("too expressive")
    has deep subtleties ("like C++"; "reducers, transducers, atoms, agents, protocols, reader macros...all this cool shit")
    useless stacktraces (especially with anonymous functions)
    comically terse documentation
    there doesn't seem to be a debugger? ("I can't attach something and say 'show me what's happening'")
    omg the jvm

…but at the end of that section, he admits “this is all just another way of saying I’m way more fluent in Ruby.” I mean, yeah, building a large app in a language (and language paradigm) you’re not fluent in is going to mean some learning. Learning is not painless.

3 Likes

Act 2: The Fall

  • Why is everything taking so long (development in a diversified environment)
    1. Bad Architectural Assumptions
  • Underestimated Domain Complexity
    1. Separate Deployments = More Overhead
  • High Fixed Cost to Orchestrate Multiple Services at Once
    1. Death by a Thousand Papercuts
  • Not Clear How to Structure Large Apps
  • Fun to Write, can be Difficult to Read
  • Clojure has Deep Subtleties (… having to know Reducers, Transducers, Atoms, Agents, Protocols Reader Macros, etc.)
  • Useless Stacktraces
  • Comically Terse Documentation
  • There Doesn’t Seem to be a Debugger?
  • OMG the JVM
  • App takes 30 seconds to boot
  • Deep editor integration is required (emacs, Cursive with IntelliJ)
  • Deploys are 100s of Megs; App Consumes Gigabytes of RAM (… can’t fix something from a coffeshop …)
  • Maven Jar Dependency Hell
  • Way More Fluent in Ruby
  • Feeling Frustrated
  • Am I… sure I’m Not Stupid?
  • “user hostile”
  • In A Nutshell: Developer Happiness is not a Priority?
  • “Well… you have a REPL. That Should be Good Enough?” (i.e. Clojure does not support “debugger driven development”" …)
  • Strange Feeling of Culture Shock
3 Likes

So basically JVM bloatiness in the usual on-disk size, in-memory size, and dependency-hell seems to be the largest points with a few other miner ones? Interesting. Clojure is one of those languages I’ve only dabbled in, try to stay away from the JVM as much as I really can though. I did see it ‘from the other side’, I.E. accessing Clojure code from Java, that was a world of pain there, not transparent like Scala, it has its own… everything, even function types… >.>

1 Like

The way I see it they just wanted to play with Datomic - that seems to be the only reason they got involved with Clojure in the first place. During the refactor they changed the PostgreSQL data model to a point in time architecture so there was no reason to keep Datomic/Clojure around. You could argue that Datomic/Clojure was never critical to their business need and should have never been adopted under the circumstances (hindsight being 20/20).

The positive impact on their Ruby development environment should have been gained on some throwaway code - not by using the technology inside the core of their product.

That being said they are now back to maintaining a Ruby/Rails monolith avoiding the “fixed cost of distribution”. So as such they are not prepared for sudden, exponential growth (as they’ll likely not experience that anyway) but at the same time it isn’t clear whether the are investing in practices like identifying and adhering to bounded contexts, especially after they admitted to underestimating the domain complexity. Now my exposure to Ruby/Rails has been extremely brief so I don’t even know how easy or difficult that would be (my superficial impression is that Rails wouldn’t lend itself all that easily to maintaining bounded contexts - but I really don’t know).

2 Likes

Yes I had the same problem with Cojure sometimes it is hard to read, the same as Scala.
I like to have nice syntax :slight_smile:
And it is hard to refactor Clojure code.

About Clojure good practices
https://pragprog.com/book/vmclojeco/clojure-applied

Some alternative talk: from Ruby to GO
Conclusion: Go is good for APIs bad for Web Apps

(Please don’t yield at me :slight_smile: )

Correction Go claims that have good Web framework
http://gobuffalo.io/

2 Likes

I tried to learn Clojure last year because I believe on learning one programming language per year. The stacktraces are terrifying. You don’t have a clue on what’s going on, and it’s all Javaish stuff. Really bad, if you compare with Elixir stacktraces.

What I like of Clojure are the alternatives of concurrency you have - STM, Actors and Fibers. My wish is that someone builds a programming language on .NETCore that looks like Elixir, has all metaprogramming features that Elixir have plus optional Types. And, of course has all the alternatives for concurrency implemented. :slight_smile:

3 Likes

on .NET Core you have http://fsharp.org/ plus concurrency http://getakka.net/ | https://dotnet.github.io/orleans/ and for web https://suave.io/ ->. enjoyable pack :slight_smile:

https://github.com/aspnet/Home/issues/1432

But I won’t be using .Net core for serious projects until it gets mature.

1 Like

Yes I’m aware of that stack and F# is awesome!

But I miss something with a direction which is not directly tied with Microsoft. An alternative would be awesome, even more one that has same features as Elixir. And the CLR is a way better place to build programming languages than the JVM, it’s such a shame most of the .NET devs only have looks for C#.

1 Like

F# is not tied to Microsoft. It is driven by community :slight_smile:

1 Like

Somewhat driven, yes.

1 Like

I’m looking into Clojure and while researching the gotchas of the system I stumbled upon this video:

For anyone who doesn’t want to watch it (IMO 30 min well spent) basically a Ruby guy discovers FP with most its nice parts but without BEAM, then has few problems (some are Clojure related, but most are not - distributed is hard, JVM is no walk in the park, this kind of stuff) and goes back to Ruby now trying to bend it to become somewhat functional since it’s better then nothing and better then working with what he had before.

This arguably sad story made me appreciate my case so much more: I researched a lot of alternatives and switched to Elixir in a similar situation, though most of the paper-cuts that this guy had do not exist in Elixir world and are something we don’t think about till it hurts us (so we take it for granted). Also we get BEAM and it’s really awesome :slight_smile: Still I wonder if there are people going back from Elixir to where they came from, but they sure have not too many reasons to do that.

3 Likes