Outside of very special circumstances, I don't think it is a good idea to replace Python code with Clojure code. In fact, judging from my own contracting experience and seeing the many mistakes made by first-time Clojure programmers, I more often than not suggest moving from Clojure to anything else.
The problem with using esoteric languages is multi-fold. First, you have to trust that the original programmers actually know the language enough to not create a massive disaster. Are they comfortable working without a framework, are they knowledgeable about all the issues that arise from building closer to the metal, so to speak? It seems to me that the answer is "no" more often than "yes."
Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions. You are then left in the position to ask 15 people if they can make dollars or sense of anything written, and if you are fortunate, you will get one "yes." I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement. If you want your code to exist, and you aren't a real somebody, then good luck. If you aren't located in SF, LA, or some other city that attracts talent, definitely do not use Clojure or any other esoteric language!
Of course, I didn't read the article, as it isn't loading at all.
I don't see how Clojure is "close to the metal". To me it seems pretty high up in the ladder of abstractions.
In Java, we have Lambdas and Streams and some concurrency APIs and Clojure only seems to build _on top_ of these, making them much more ergonomic, simpler, AND encouraging immutability, to boot. Novice programmers love mutability, but in Clojure you kind of have to go out of your way to solve something with mutation. So to me (as long as users aren't getting carried away with writing macros) it seems you should land in a better spot with Clojure. If you're not seeing that's the case, then what is it? What are the common mistakes that you see these novices making that make for unmaintainable code---that somehow is not found in the same proportion in something more mainstream? Would seriously love to hear.
Specifically the parent is talking about coding without a framework that has solved many problems for you. "Metal" is the language in this case, not the CPU
Any framework that Java and/or Javascript has can be used in Clojure.
I guess this is an apples to oranges comparison when you put it that way. Eg, React and Clojurescript are great together; and of course so are many JVM frameworks and Clojure.
You really don't though. Clojure ecosystem consists of lots of mature libraries. Luminus http://www.luminusweb.net/ will wire them up for you in a standard way. All you have to do to make a new project is something like:
lein new luminus myapp +postgres +auth
And you're good to go. Everything is setup, and you just have to add the code relevant to your application.
It's also worth noting that the nature of how web apps are built has changed over the years. Everything used to be done server-side, with the client just rendering HTML for the most part. A big framework makes sense in that context.
However, SPA approach is the popular way to build apps today, and all the UI logic lives client-side. The server becomes just a set of service operations, that are ideally stateless for scaling. You really don't need anything too fancy on the backend with that approach.
This is pure and complete FUD. Clojure is not some esoteric language you can't hire people for. My team has been working with it for over 7 years, and we never had a problem hiring people.
Today, there are plenty of companies using Clojure and consulting. There are literally thousands of Clojure programmers in the US, and many more around the world.
Meanwhile, Clojure is used by companies such as Amazon, Apple, Boeing, and Walmart. This isn't some obscure language anymore.
In terms of performance, Clojure is well known to be fast, and it runs circles around Python without any optimizations.
So you're saying we should all just settle for Javascript, Python, Java, and C because they're familiar and not esoteric (whatever that means)? Should we not consider ReasonML an option for frontend development, even though it solves many problems, because it is esoteric?
The problems you list above are true enough regardless of language choice. I've seen disasters in Clojure as many times as I've seen disasters in Java or Python. Also, why are first-time Clojure programmers code worse than first-time C programmers?
Do you understand that he is talking about Lacinia, which is from WalMart? Do you feel that WalMart is esoteric? Do you wonder why WalMart has decided to commit to Clojure?
A friend of mine offers the somewhat humorous summary of Clojure as "a library that makes concurrency easier in Java." And I suspect that is why so many large companies are moving towards it. These were companies that had a large number of Java programmers. Presumably the programmers often made mistakes regarding concurrency, and they were looking for a way to make it easier to manage concurrency. And so they switched to Clojure.
Interop between Java and Clojure is seemless, so a lot of companies that are already using Java can add in Clojure painlessly. Actually, I should state that more strongly, Clojure removes some of the pain of dealing with concurrency.
Lacinia is new. The first public release was just 6 months ago:
The fact that big companies like WalMart are committing to Clojure, and then releasing their libraries to the community, suggests that Clojure is going mainstream.
> I more often than not suggest moving from Clojure to anything else.
Rewrites are notoriously risky projects, I'm surprised you suggest this the majority of the time.
> you have to trust that the original programmers actually know the language enough to not create a massive disaster
This is my experience, but I've come across many coding disasters and none have been caused by misunderstanding the programming language. All have been due to poor software design or testing.
> Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions.
Why have you pinned the blame on Clojure? What are the properties of Clojure that cause programs written in it to have so many bugs? Programming languages don't make decisions, let alone stupid ones.
> I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement
This is a massive overstatement. Netflix, Apple, Soundcloud, and Walmart are all using Clojure. I work on a large team of Clojure developers, many of whom are located in the US. The Clojure community is large, healthy and growing. This is not an "esoteric" language.
> If you aren't located in SF, LA, or some other city that attracts talent
I work with Clojure developers all over the world, many in small towns in their respective country. My address hasn't been a factor for any tooling decision I've been a part of, it's a strange (overlooked?) criteria by which to judge technology.
> What are the properties of Clojure that cause programs written in it to have so many bugs?
Well, I can only speak from my own experience, but twice now I've personally seen enthusiastic talent python programmers create clojure projects which 'did all the things':
- used core-async heavily, including blocking channels that are never resolved in the UI.
- massive 'global application state' top level atoms that are mutated arbitrarily throughout the application
- massive complicated one line reduce/map/whatever where people are trying to be clever and reduce the lines of code, because 'fewer lines of code is better'.
I think it's telling when you get a 'walk through' from the person who wrote the code, and they have to stare at it, trying to figure out why it was they needed 10 different channels as they're explaining it.
After thinking about it quite a lot, my conclusion is that I would recommend against clojure for the same reason I would recommend against C: It's easy to mess it up.
Clojure allows you to create very complex applications; and you have all the tools to shoot yourself in the foot.
I don't think I'd tell people to migrate off clojure, but if the opportunity came to work on a new project, I would run away unless at least 50% of the people had actively used it before.
(and by comparison, my experience with a relatively novice team using elixir has been extremely positive; so yes, I do actually think this is a reflection on a clojure itself, not just 'insert any unknown programming language here').
You can write bad code using bad practices in any language. All the points you've made have absolutely nothing to do with Clojure, and are simply bad architecture.
Every language allows you to write complex applications, and shoot yourself in the foot. If I pick up Python tomorrow, and start writing a large application in it, it's pretty much guaranteed I'll make a mess.
Wow, that is a shockingly steep dropoff! If you believe this chart, clojure will be extinct in another year. Could there be some other explanation than that clojure is really in a death spiral, like maybe Indeed has been growing faster in less developed markets or something?
I can’t speak for the others, but at least for Amazon, for every clojure programmer you find, you’ll find 1000 using Java. Sure it’s a big name using it, but it’s only a few teams on a few projects. That’s kind of the point of SOA, it allows the team to do what they want without huge top level decisions on what technologies to adopt or abandon.
I think that's the point. Although Clojure has been adopted by a small cluster of big names it tends to be ignored further down the food chain. Search Indeed.co.uk's API for title:Clojure in London and you'll find 8 jobs compared with 378 for Python. For the UK as a whole it's 19 Clojure to 669 Python.
Python has been around a lot longer than Clojure though, especially if you count years of it being used in production. Clojure has only started seeing wide use about 5 years ago.
The fact that it's already used successfully at large companies shows that it is an effective language. Most companies that try it end up sticking with it. So, I'm not really seeing a problem here to be honest.
Clojure was released 10 years ago with 1.0 officially announced 8 and 1/2 years ago. Clojure adoption has been stagnant for a few years now. 8 jobs in London after 10 years, IMHO, represents a serious adoption problem.
Python was released 26 years ago, and it certainly didn't have the ecosystem or the popularity it has today 16 years ago.
There are certainly more than 8 jobs in London for Clojure. JUXT https://juxt.pro/index.html alone hires more people than that. Maybe you're just looking in the wrong places.
That is not interesting. If you are making the point that the rate of Clojure job growth is declining, it could be a data point in support of that hypothesis.
What do you think Clojure's absence from zdnet's list indicates?
All of these articles are kinda click baitey sugary snacks for junior developers in my opinion. It’s conflating too many concepts and introducing too many variables. A vanilla comparison of GraphQL versus REST -or- Python (not Django) versus Clojure would have been more interesting.
You can build anything with anything. It’s all data manipulation. Some languages have a more fruitful ecosystem of libraries or offer a more efficient syntax for your particular task.
To be honest, the way that graphql is handled by the author in Clojure looks kinda inefficient. You have a language that allows you to create your own dsl with abstractions and macros but you write a massive edn map of your types? What’s the difference between that and using any other language at that point?
Interesting insight but I hope folks don’t read this post and think: “wow we are wasting our lives with Django and REST”. The four technologies here all have value and merit in their own ways.
P.S. I use Clojure and Python on a daily basis at FarmLogs
I agree with you that that wasn't the best comparison. As I wrote somewhere downthread, in a perfect world, I'd be comparing Clojure/GraphQL with Python/Graphene. But it is what it is and, even though the project I could compare to wasn't ideal, I still think we were able to draw valuable lessons for our use cases. It isnt't feasible to choose a technology just because it would be a better comparison.
> Interesting insight but I hope folks don’t read this post and think: “wow we are wasting our lives with Django and REST”.
God no! As the author, I hope to god no one thinks that after reading the article. We're mostly a Python shop and we love it, but sometimes it isn't the best choice.
Clojure is neither an "esoteric language" nor "close to the metal". Also, Clojure does have a pretty popular micro-framework called Luminus (which is basically ring+compojure), and there are other options too, so developers don't need to code a web server from scratch.
> you have to trust that the original programmers actually know the language enough to not create a massive disaster
The same can be said for any programming language, although I think you may find much more disasters in, for instance, PHP and Python projects than in Clojure and Elixir ones...
developers don't need to code a web server from scratch.
I mean, that statement is true. But there is nothing in the Clojure ecosystem anywhere remotely close to the level of functionality contained in a framework like Django - Luminus included. Partially this is cultural: the Clojure party line is that libraries are good and frameworks are baaad.
The headline is misleading. He actually built similar products in both Python/Django and Clojure at the same time. He didn't replace one with the other.
It's mostly a language comparison blog post. "These were the good parts of Clojure, these were the bad parts, etc."
Not really. It was more of a "platform choices" comparison blog post. We're mostly a Django shop, so the Python project began a few months before the Clojure one. We had the feeling that Clojure might be a good fit for a few use cases that we have, especially mobile-focused API backends, so the post is a summary of some of the lessons we learned when using a Clojure web stack instead of Django.
So you are basically saying that "Don't buy an Audi TT because it is harder to drive than a Mazda?" Not a good idea. I'd replace Python 100 times out of 100 with Clojure.
People usually say "closer to the metal" to mean more control over the hardware. Its hard to see what mainstream language clojure has more control over the metal then given that it targets the two of the largest languages it self.
The problem with using esoteric languages is multi-fold. First, you have to trust that the original programmers actually know the language enough to not create a massive disaster. Are they comfortable working without a framework, are they knowledgeable about all the issues that arise from building closer to the metal, so to speak? It seems to me that the answer is "no" more often than "yes."
Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions. You are then left in the position to ask 15 people if they can make dollars or sense of anything written, and if you are fortunate, you will get one "yes." I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement. If you want your code to exist, and you aren't a real somebody, then good luck. If you aren't located in SF, LA, or some other city that attracts talent, definitely do not use Clojure or any other esoteric language!
Of course, I didn't read the article, as it isn't loading at all.