Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects.
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
As the saying goes, a bad workman always blames his tools. You can make a mess in any language, and Clojure is no exception.
There are plenty of ways to mitigate the problems the author describes. A few of these things would be having coding standards to ensure that code is written in a way everyone is comfortable with. This also covers things like adding schemas and documentation for maintainability. Doing pairing and code reviews so that multiple developers are familiar with different parts of the codebase. Having good tests so that you can have confidence that the code does what's intended when you make changes.
I'm also not sure what makes Clojure esoteric. It's a clean and well designed language that embodies good principles. It's a niche language, but far from being esoteric. I've been using Clojure for over a decade now, and I've seen the opposite of developer churn. Most people are pretty happy to stay at a company using Clojure. The fact that there is high churn is suggestive of a toxic environment that drives people away.
Finally, here's [1] a talk from a founder of a Clojure startup that grew into a large successful company. Clojure didn't get in the way of that.
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work.
But I absolutely hate maintaining an old Clojure codebase (unless it's tiny).
The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get into a dynamic-versus-static-typing debate, but I've long since come to the conclusion that -- all other things being equal (hah!) -- if I have to dig into a large and old project, I'd much rather have types by my side than not. Code will not ever be adequately documented or commented (and even if it _seems_ to be at first glance, you will always have nagging doubts about how up to date that info really is). This is where type definitions help to figure out the shape of the data that any piece of code is working with. People talk about adding spec/schema definitions but that doesn't solve all the problems with not having type definitions unless you add these spec/schema definitions _everywhere_ ... and let's face it, you just aren't going to do that in any Clojure project. So, best case scenario is you still have a large collection of functions in your project that are calling each other, etc that you are left having to deduce yourself what this random map or list actually contains.
Oh man, this is not my experience. We may be different because we are a small company, and Clojure is our main language. But, we have a Clojure codebase of 90K lines, and is 10 years old. It has its problems, and while your points about an opaque data model resonate, for us, tests, specs, and assertions provide enough hints to help newcomers. And... where I disagree the most: the quality and professionalism of the developers who work on it are unparalleled. New, senior-level developers, quickly catch on to the system. I am grateful to Clojure __because__ it attracts this caliber of developer.
I'd say 100% developer churn is the real problem here, no inherited 100kloc codebase is going to be a walk in the park if the original devs are not around.
However, I do think that it harder to keep a large code base understandable when using a dynamic language v.s. a statically typed language.
Having problems with understanding the shape of expected data is certainly a problem experienced in larger Clojure code bases, I guess this is just a disadvantage of using Clojure.
Documentation, tests, spec/schema and good naming conventions can mitigate this disadvantage to some extent.
OK but that's a 500k LOC codebase in javascript/python that nobody understands, maybe the project doesn't even get there
everybody hates their language when they have 100k LOC of tech debt from 8 years ago
You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not collapse once it reaches 500k+ LOC Java, 500k XML, 300k SQL ...
- dev churn is just a fact of life in this industry
- I'd love to know which language stops you from having 100k LOC codebase that nobody understands! Certainly not C#, typescript, Java...
- "esoteric developers" - that's a bit glass half empty! In my experience people who have taken the time to learn functional programming or any non top-10 language are usually pretty smart and motivated.
What worries me the most about clojure and languages like it, is that seems to be for people who want to be clever with how they write programs, when that is the opposite of what I want from people I work with.
Knowing how to design and structure maintainable code is a must for any successful code base to remain manageable over many years.
Clojure, in the hands of someone that knows this, works wonders. It gives your team 10x productivity, safer more correct code, that's simple to extend and grow over time, keeping your velocity high and your tech dept low.
But if you don't know how to leverage it's strengths, what best practices to follow, you can end up in a mess like that.
And this is true of all languages honestly. I've seen this for C++, Java, JavaScript, C#, Scala, all kind of code bases that suffered this same fate, with 100% team attrition, and all kind of other issues.
I say this from first hand experience, 6 years on a team that transitioned to Clojure, in that time the team rotated fully twice, during the pandemic it had 100% attrition, even I left (working on another team), but all the new developers, even though they have zero Clojure experience, had no issue understand the code base and start making improvements and building new features, velocity saw no impact whatsoever. You get the usual some of them would rather it be something their more familiar with, others are loving it, some don't care either way. But no complaints about the code base itself, no talks of spaghetti code, or challenges to debug anything, or understand what's going on.
Basically don't expect Clojure to save you from yourself, it's an asset when you know what you're doing, not a safeguard when you don't.
Wow, I've finally found my tribe. All of this rings true for me. I kept hearing about how Clojure is this life-altering programming language that would make me forget all others and want to write parentheses for the rest of my life. But after working at a startup using Clojure for a couple of years, I've come to a couple conclusions about it: a) it is indeed a really nice, consistent language that's really nice to read and write, and b) the choice of programming language is a rounding error when determining whether a project or company is successful.
> esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code)
And to the article's title, "building a startup on Clojure," you're better off building a startup on a customer base.
> And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
If I was choosing a language to base the tech stack for a startup on these days I'd be very reluctant to pick anything that didn't have a local user group. Slightly more esoteric languages that enable you to write better code faster are brilliant, but if you're successful enough to grow quickly, or you can raise funding, you'll need to hire devs relatively early on. If you've chosen a stack that's too esoteric then this will be a huge blocker to making any real progress.
When I did my last startup we switched from a Python API to Node for this reason. Python is a great language but there are no devs available where I live. I can't even imagine considering Clojure unless I was in a major tech hub.
The move to remote work is probably going to be a massive benefit to building in less mainstream languages.
Counterpoint: building in esoteric languages can serve as a filtering mechanism in and of itself. Given how broad the swaths of JavaScript and Java developers are, they can be much more hit-or-miss.
I haven't gotten to that stage yet. But I think it's difficult to hire good devs for all stacks, be it Python, Ruby, JS. Clojure community is super friendly and full of very talented developers and I'd love to pay someone to write Clojure :).
Also a point for node: in the time people have argued about how node sucks (some valid points, all easily mitigated) and how X is better, they could have already shipped a bunch of nice features.
Focusing only on web stuff.. If you have a good grasp of design patterns and you can build out your system in a modular way, I think node is a great starting point.
I love starting with node because typescript is awesome, the performance is nice, the community support is tremendous, the scaling is easy, and finally it’s easy to move off it. If some part of the system starts becoming a bottleneck, just swap that piece out for something more suitable. One thing I like about this time right now is that most things are built just fine to be used in creating something new and useful products.
Have we learned nothing from covid? You don't need to limit your talent pool to your own backyard. Especially since you're not in a major tech hub, by your own admission.
For me, the killer feature of Clojure is "REPL driven development". The ability to get rapid feedback as you build things up is incredible. I'll make a comment form and evaluate expressions within it to try things out as I go. By the time I've written any reasonably complex function, all of the pieces have been tested on various examples. Once I'm done, the comment form leaves a helpful record of my thought process.
If you're wondering what's so great about the Clojure repl (and other lisp repls) in particular, the thing is that you never have to actually type something into it. You can run evaluations from the code file itself. The structure of lisps makes it clear exactly which code you want to evaluate. To do this, I use the excellent CIDER package for emacs. I understand Calva for VS Code and Cursive for IntellJ offer similar functionality.
I kind of agree with you. I used to work with Common Lisp in a Desktop App (Nyxt browser). I had some fun playing with Racket. And I love Emacs. So, I am already into the Lisp idea. But, I was kind of disappointed with Clojure which is new in my life and has been used in my current job. Maybe you have a backend bias in your testimony?
I have been working with ClojureScript (re-frame and reagent) on front-end stuff and, unfortunately, the REPL does not seem to help me that much on my workflow. I miss the REPL driven development, by the way... The real "interactive programming" seems to happen on Chrome Dev Tools + Browser's reactions to Chrome Dev Tools tweaks on the UI + (lastly) changes on the source code via the editor (Emacs in my case).
Namespaces as prefix of invocations on the REPL are not that trustworthy on ClojureScript, apparently. It could also be that I am a noob and I missed something, so... How do you feel about ClojureScript?
Our experience building a business with Clojure has been amazing. It has helped us to attract extremely strong engineers, and churn has not been a concern in the slightest. We've taught people (from code beginners to experienced engineers) Clojure, and all of them are able to start adding value in a very short space of time. We're six years in and there are no signs of increased maintenance difficulty due to the language. We follow the Polylith Architecture (https://polylith.gitbook.io/polylith/), which has given us yet another boost in
developer happiness, speed of delivery, and ease of maintenance. There are many extremely large Clojure code bases out there (Ladder life, Lemonade, Simply life, Wallmart, Nubank, Atlassian) not suffering from the maintainability issues that some people here have described.
After six years, I would absolutely (without hesitation) start another business with Clojure as the core.
I have not built a business with Clojure and I wouldn't recommend it. For the reason that I'm hoping one day to build one and beat the averages. Stay away from Clojure, or else... :)
My company (as in "I work there," not "I own it") is I think unique in that it started as an Elixir/TypeScript shop, things went seriously downhill, they brought in a new engineering team (I'm on it), we switched to Clojure, and we're doing fine.
If I were to start a new company I'd absolutely run it on clojure. Even without frontend/backend code reuse, REPL-driven dev---paredit is the killer app for me. It just makes editing text files, which is what we're doing if we admit it, so much easier.
This might actually be the first thing I've seen pop up organically about Elixir that isn't red hot glowing praise. Can you elaborate on what was going wrong and if it was anything specific to Elixir/Typescript?
> Any sufficiently complicated TypeScript or Java program contains an ad hoc,
> informally-specified, bug-ridden, slow implementation of half of Clojure.
Once you grokk the approach and workflow Clojure takes in solving problems, the distance between having an idea and writing a rock solid implementation of that idea is the shortest I've experienced in my ~20 years of programming.
If you want to write succinct, transparent code whilst minimizing the future potential of introducing bugs, Clojure is as good as it gets.
Besides being fun for sure because you can use whatever you want for your own stuff I don't see what's special about clojure here. They are using react (behind a wrapper), IME, clourescript is not worth the hassle. On the server they are using ring/compojure which is similar to js/express, python/flask that can get the job done equally well in this case. The story would be more interesting if they were using something like datomic instead of postgres since datomic is were clojure could differentiate itself.
Keep in mind that they have to juggle between almost four different languages, Java, Javascript, Clojure and Clojurescript, almost because there are differences between Clojure and Clojurescript. Instead of for example just using one language: JS.
ClojureScript is one of the main reasons why Clojure makes sense in my business. I can use the same language and share the same business logic code between the server and the browser app. That's huge!
Also, I avoid a load of problems related to communication and serialization, because the native serialization format is EDN, e.g. Clojure data structures. There is no need to adapt your data structures to the limitations of, say, JSON.
I worked at a startup that was built on Clojure. It had trouble finding developers for reasonable salaries at the early mid stage. They decided to switch the stack to python at that point. Just an anecdote!
I think this is the key here. Clojure developers are expensive (see the Stack Overflow charts for how being a Clojure dev essentially guarantees a great salary) — but that's not because of them being Clojure developers, but rather because of them being more experienced, knowledgeable, and flexible than your "average" developer.
If you start a business and use Clojure, you should expect to hire more expensive developers. You will, however, need fewer of them, so this might all balance out in the end, especially as we all know that teams don't scale infinitely.
Building a company in Python feels like a bet against yourself ie the company/codebase will never get big enough that using Python (lack of static typing etc) will ever be a problem
I don't know how any non-FAANG companies in the bay area hire non-junior developers. I have 4 kids and the difference in mortgage payments alone for relocating there is well into 5 figures per year.
Always great to see more start ups being built on Clojure! For folks interested, this is a great talk on the same subject: https://youtu.be/L9KcoRZcdbc
Full disclojure: I work for the company in the talk, though I'm not one of the presenters.
One thing to note about coding in Clojure — if you never learned Java, you hit a wall at a certain point. I only know scripting languages and I had fun writing little scripts in clojure, but at a certain point the lack of java knowledge and it's class system / standard libraries held me back from doing more serious things.
It was interesting to me the author seems to use 'old-school' Clojure, for lack of a better phrase, with lein as the build tool, etc., rather than more recent tools/stacks; I don't use Clojure myself, is my impression off?
Something being "more recent" doesn't necessarily make it better :-)
I use leiningen, too. I tried other approaches, but had trouble getting them to do everything that I need (for example, AOT compilation of the entire code that goes into the final .jar), and I couldn't really see any massive advantages.
deps is more flexible, but I you just want to run a repl, build and deploy code then lein still works fine.
I usually default to leiningen: I can't be arsed to spend time configuring deps to do what lein does out of the box. (For example: building an uberjar)
Question for Clojure's pros: as a designer I started programming javascript for a long time, now I can do my own APIs on Node easily, would it be hard to do APIs in Clojure? Can you recommend me a video course for learn it?
I learned by reading through a book, then working through problems on https://4clojure.oxal.org/. If you've got JS experience it won't take too much effort to pick up. Don't get too carried away with forming the perfect tail recursive pure functional monad or whatever. Get into just doing what you're trying to do quickly, then after you're competent, read other people's code to correct your style.
Well, i have to add having developing in a Clojure shop that starting to develop a new feature with Clojure is easier than Kotlin, you don't have to care almost about of the shape of the data. But later, this is a pain, you need a lot of discipline to document because you would look back at this code a who knows what data are you receiving.
In addition i have to say, that a lot of libraries are falling into clj-commons because the original developers no longer works on the project, other like compojure, that is mentioned in the blog post last stable release is from 2016 and version 2 is in alpha since then.
I am curious why are you using c3p0 on 2022 when hikaricp is being maintained, and last release of c3p0 is from 2019. Also no support for R2DBC.
My impression is that in the last 2 years, the ecosystem has shrink, less talks, less new libraries, new libraries that are no longer maintained.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library. No conversion from Java 8 CompletableFuture to clojure async primitives in 2022. And i think they not going to support it in the near future.
What i am saying is that Java is in the future, and Clojure is in the past. They just cannot catch with new Java features and i doubt they are going to support it ever. You can still run it on modern jvm because they update the bytecode but that is all.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library
Ouch, Java 8 was released in 2014. To be fair, Clojure was never a community project though.
What does everybody think here of C#? I've just made foray into it and I like it a lot compared to Python, Java etc. It almost feels like Kotlin, but with certain even cooler properties.
- Tons of developers know it
- Tons of Java developers can be made to know it with ease
- A good default IDE experience within VS and VSCode, and a JetBrains product if you prefer it.
- A good LSP implementation with OmniSharp if you don't want to use an IDE.
- ASP.NET, a good default Web framework.
- NuGet as a package manager with tens of thousands of packages.
- Better than java reflection and runtime generics.
- Cross-platform CLI tooling since .NET Core, now it's just .NET.
- Ability to deploy self-contained applications.
- Mono version of C# is used for making games.
- A continuously evolving cohesive language with minimal competitors (like Groovy, Kotlin, Scala, Clojure, etc... on the JVM)
- F# if you want a stricter functional language that interoperates with C# seamlessly.
- PowerShell as a way of interactively running any .NET assembly, regardless of how it was compiled.
And many more... C# is one language you can build a career on and also use for hobbying and have fun.
The haters will complain that MSBuild (the default build system) and Visual Studio suck. If you've tried them in the past, you're probably right. Try them again in 2022 and see if your opinion doesn't change.
re-iterating what onion2k said, hard pass on building a company around an esoteric language. enjoy attempting to hire people to work on this. best case you get an eager programmer wanting to learn the language. worst case you get zero experienced hires unless you’re a massive success.
The real worst case scenario is facing a competitor that's much faster than you on implementing new features and testing hypothesis. Using an esoteric language might be one of the leverages that this competitor has against your tight mainstream stack.
That "best case" seems dishonest at best. How is the best case not "Best case you get awesome programmers with lots of experience and knowledge about what Clojure is all about, being able to ship software better than anyone else" or similar?
Clojure has pitfalls for sure, but no need to be dishonest in order to flag them.
I would also argue that the productivity delta between something like Clojure vs Python or Javascript or Kotlin is not as high as it was between Common Lisp vs C++/Java 10-15 years ago. So the payoff for a risky bet is not as high.
That said I would love to work in a lisp full time. There's just something appealingly elegant about it.
We have a number of libraries that are easy to use together for the backend, no fancy web framework (build your auth page yourself), no fancy client-side lispy libraries. We might have a Fighweel-like tool, but no one is interested (Trident-mode for Emacs).
There's one framework that looks promising to build fully dynamic apps in pure CL with one code base (websockets inside). It provides a GUI-like experience to build all kind of apps (a website, a chat, the snake game…): https://github.com/rabbibotton/clog/
I am using Hunchentoot, a routing library on top (easy-routes), the Mito ORM, and for the client side I am conservative: HTML templates with Djula, interactivity with HTMX, Vue if required, JS.
The great thing is that I can build a standalone binary of my web app, including the static assets, the webserver, the lisp compiler and debugger… for ±28MB unzipped and instantaneous startup times.
Not an expert, but I would expect hunchentoot https://edicl.github.io/hunchentoot/ for the backend and a Common Lisp "dsl" generating javascript for the frontend.
I am a hobbyist lisp developer and have written webapps in CL.
I use cl-who[1] for generating html and parenscript for javascript. I use clack on the backend, but hunchentoot is probably more popular. Both backends have plenty of routing libraries available (hunchentoot comes with a decent one baked in, clack does not).
postmodern is a Postgres specific sql backend that is great. There are database-agnostic SQL libraries as well (clsql and cl-dbi I believe are the two big ones) but I haven't tried them.
1: People whose opinions I trust have told me that spinneret is a better choice. It did not exist when I learned cl-who. cl-who is "good enough" for me that I haven't switched.
Here's a nice interview of a company using CL for their document processing stack: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ (edit: not a pure CL web stack: Ruby to CL logic via websockets to a lispy client side)
some recruiters tried to recruit me a while back. too bad they wanted an experienced clojurist for their client. i mean, it's good and all but it's too hard to find some corps which use clojure around here where i live.
so, yeah. while i'm excited with lisp, i don't think i have the gut to start my own shop with clojure as the main language.
ldite|3 years ago
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
yogthos|3 years ago
There are plenty of ways to mitigate the problems the author describes. A few of these things would be having coding standards to ensure that code is written in a way everyone is comfortable with. This also covers things like adding schemas and documentation for maintainability. Doing pairing and code reviews so that multiple developers are familiar with different parts of the codebase. Having good tests so that you can have confidence that the code does what's intended when you make changes.
I'm also not sure what makes Clojure esoteric. It's a clean and well designed language that embodies good principles. It's a niche language, but far from being esoteric. I've been using Clojure for over a decade now, and I've seen the opposite of developer churn. Most people are pretty happy to stay at a company using Clojure. The fact that there is high churn is suggestive of a toxic environment that drives people away.
Finally, here's [1] a talk from a founder of a Clojure startup that grew into a large successful company. Clojure didn't get in the way of that.
[1] https://www.youtube.com/watch?v=u-4FiFpkPlQ
gered|3 years ago
But I absolutely hate maintaining an old Clojure codebase (unless it's tiny).
The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get into a dynamic-versus-static-typing debate, but I've long since come to the conclusion that -- all other things being equal (hah!) -- if I have to dig into a large and old project, I'd much rather have types by my side than not. Code will not ever be adequately documented or commented (and even if it _seems_ to be at first glance, you will always have nagging doubts about how up to date that info really is). This is where type definitions help to figure out the shape of the data that any piece of code is working with. People talk about adding spec/schema definitions but that doesn't solve all the problems with not having type definitions unless you add these spec/schema definitions _everywhere_ ... and let's face it, you just aren't going to do that in any Clojure project. So, best case scenario is you still have a large collection of functions in your project that are calling each other, etc that you are left having to deduce yourself what this random map or list actually contains.
kbuchanan|3 years ago
synthc|3 years ago
However, I do think that it harder to keep a large code base understandable when using a dynamic language v.s. a statically typed language.
Having problems with understanding the shape of expected data is certainly a problem experienced in larger Clojure code bases, I guess this is just a disadvantage of using Clojure.
Documentation, tests, spec/schema and good naming conventions can mitigate this disadvantage to some extent.
I found some the advice in this blog post useful: https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-l...
dustingetz|3 years ago
everybody hates their language when they have 100k LOC of tech debt from 8 years ago
You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not collapse once it reaches 500k+ LOC Java, 500k XML, 300k SQL ...
LAC-Tech|3 years ago
- dev churn is just a fact of life in this industry
- I'd love to know which language stops you from having 100k LOC codebase that nobody understands! Certainly not C#, typescript, Java...
- "esoteric developers" - that's a bit glass half empty! In my experience people who have taken the time to learn functional programming or any non top-10 language are usually pretty smart and motivated.
CyberDildonics|3 years ago
didibus|3 years ago
Clojure, in the hands of someone that knows this, works wonders. It gives your team 10x productivity, safer more correct code, that's simple to extend and grow over time, keeping your velocity high and your tech dept low.
But if you don't know how to leverage it's strengths, what best practices to follow, you can end up in a mess like that.
And this is true of all languages honestly. I've seen this for C++, Java, JavaScript, C#, Scala, all kind of code bases that suffered this same fate, with 100% team attrition, and all kind of other issues.
I say this from first hand experience, 6 years on a team that transitioned to Clojure, in that time the team rotated fully twice, during the pandemic it had 100% attrition, even I left (working on another team), but all the new developers, even though they have zero Clojure experience, had no issue understand the code base and start making improvements and building new features, velocity saw no impact whatsoever. You get the usual some of them would rather it be something their more familiar with, others are loving it, some don't care either way. But no complaints about the code base itself, no talks of spaghetti code, or challenges to debug anything, or understand what's going on.
Basically don't expect Clojure to save you from yourself, it's an asset when you know what you're doing, not a safeguard when you don't.
Mikeb85|3 years ago
Startups that act too much like big companies just don't ever get product out the door and fail before you can bitch about technical debt...
ilkhan4|3 years ago
newlisp|3 years ago
dehrmann|3 years ago
And to the article's title, "building a startup on Clojure," you're better off building a startup on a customer base.
ngc248|3 years ago
This is a big problem with Dynamic languages. If you are new to the codebase, you have no idea of what the shape of the data is, what to expect etc.
tasubotadas|3 years ago
Wow. Pretty insightful :)
onion2k|3 years ago
When I did my last startup we switched from a Python API to Node for this reason. Python is a great language but there are no devs available where I live. I can't even imagine considering Clojure unless I was in a major tech hub.
The move to remote work is probably going to be a massive benefit to building in less mainstream languages.
DrBenCarson|3 years ago
outworlder|3 years ago
Clojure is... esoteric now? I would understand if we were talking about, I don't know, INTERCAL. But Clojure? Is Scala 'esoteric' too?
> Python is a great language but there are no devs available where I live.
Ah, I see. Yeah, by that measure Clojure will be esoteric indeed. Python developers being rare is very surprising.
drikerf|3 years ago
Yes, remote work for sure is an edge when hiring!
Also reminds me of the essay "The Python Paradox" by Paul Graham (http://www.paulgraham.com/pypar.html)
bsder|3 years ago
Wow. Where on Earth do you live? Real question, not being sarcastic.
Presumably not the US. I've found Python developers even in some fairly small towns (approx 25K people).
mradek|3 years ago
Focusing only on web stuff.. If you have a good grasp of design patterns and you can build out your system in a modular way, I think node is a great starting point.
I love starting with node because typescript is awesome, the performance is nice, the community support is tremendous, the scaling is easy, and finally it’s easy to move off it. If some part of the system starts becoming a bottleneck, just swap that piece out for something more suitable. One thing I like about this time right now is that most things are built just fine to be used in creating something new and useful products.
LAC-Tech|3 years ago
zerr|3 years ago
freilanzer|3 years ago
If only there was a worldwide information technology network allowing people to work together remotely.
hypersoar|3 years ago
If you're wondering what's so great about the Clojure repl (and other lisp repls) in particular, the thing is that you never have to actually type something into it. You can run evaluations from the code file itself. The structure of lisps makes it clear exactly which code you want to evaluate. To do this, I use the excellent CIDER package for emacs. I understand Calva for VS Code and Cursive for IntellJ offer similar functionality.
Here's a good talk on what this looks like:
https://www.youtube.com/watch?v=gIoadGfm5T8
pedrodelfino|3 years ago
I have been working with ClojureScript (re-frame and reagent) on front-end stuff and, unfortunately, the REPL does not seem to help me that much on my workflow. I miss the REPL driven development, by the way... The real "interactive programming" seems to happen on Chrome Dev Tools + Browser's reactions to Chrome Dev Tools tweaks on the UI + (lastly) changes on the source code via the editor (Emacs in my case).
Namespaces as prefix of invocations on the REPL are not that trustworthy on ClojureScript, apparently. It could also be that I am a noob and I missed something, so... How do you feel about ClojureScript?
staticelf|3 years ago
seer-zig|3 years ago
domparry|3 years ago
After six years, I would absolutely (without hesitation) start another business with Clojure as the core.
jwr|3 years ago
Together with ClojureScript it's one of very few solutions for writing server/browser apps with shared code, which enables interesting economies.
iLemming|3 years ago
udkl|3 years ago
invalidOrTaken|3 years ago
If I were to start a new company I'd absolutely run it on clojure. Even without frontend/backend code reuse, REPL-driven dev---paredit is the killer app for me. It just makes editing text files, which is what we're doing if we admit it, so much easier.
It's a data point.
powersurge360|3 years ago
unknown|3 years ago
[deleted]
fredrikholm|3 years ago
If you want to write succinct, transparent code whilst minimizing the future potential of introducing bugs, Clojure is as good as it gets.
synthc|3 years ago
> Any sufficiently complicated Clojure program contains an ad hoc, > informally-specified, bug-ridden, slow implementation of half of Spring.
xapata|3 years ago
ithrow|3 years ago
Keep in mind that they have to juggle between almost four different languages, Java, Javascript, Clojure and Clojurescript, almost because there are differences between Clojure and Clojurescript. Instead of for example just using one language: JS.
jwr|3 years ago
ClojureScript is one of the main reasons why Clojure makes sense in my business. I can use the same language and share the same business logic code between the server and the browser app. That's huge!
Also, I avoid a load of problems related to communication and serialization, because the native serialization format is EDN, e.g. Clojure data structures. There is no need to adapt your data structures to the limitations of, say, JSON.
alfl|3 years ago
Conversely, you can also get to the end of your roadmap quickly (Clojure being great) and end up overstaffed.
There's a different line to walk with languages like Clojure.
Source: I walked this line.
kubb|3 years ago
Ah, you probably want to pay them 70k/year.
thih9|3 years ago
ar7hur|3 years ago
Most engineers we hired has no prior experience but learned quickly. It gave us a great advantage to hire the best.
beiller|3 years ago
jwr|3 years ago
I think this is the key here. Clojure developers are expensive (see the Stack Overflow charts for how being a Clojure dev essentially guarantees a great salary) — but that's not because of them being Clojure developers, but rather because of them being more experienced, knowledgeable, and flexible than your "average" developer.
If you start a business and use Clojure, you should expect to hire more expensive developers. You will, however, need fewer of them, so this might all balance out in the end, especially as we all know that teams don't scale infinitely.
silentsea90|3 years ago
aidenn0|3 years ago
drfuzzy89|3 years ago
Full disclojure: I work for the company in the talk, though I'm not one of the presenters.
pedrodelfino|3 years ago
marrone12|3 years ago
georgeoliver|3 years ago
jwr|3 years ago
I use leiningen, too. I tried other approaches, but had trouble getting them to do everything that I need (for example, AOT compilation of the entire code that goes into the final .jar), and I couldn't really see any massive advantages.
synthc|3 years ago
I usually default to leiningen: I can't be arsed to spend time configuring deps to do what lein does out of the box. (For example: building an uberjar)
meerita|3 years ago
heneryville|3 years ago
drikerf|3 years ago
mulberrybush|3 years ago
https://www.jacekschae.com/
slifin|3 years ago
logistark|3 years ago
In addition i have to say, that a lot of libraries are falling into clj-commons because the original developers no longer works on the project, other like compojure, that is mentioned in the blog post last stable release is from 2016 and version 2 is in alpha since then.
I am curious why are you using c3p0 on 2022 when hikaricp is being maintained, and last release of c3p0 is from 2019. Also no support for R2DBC.
My impression is that in the last 2 years, the ecosystem has shrink, less talks, less new libraries, new libraries that are no longer maintained.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library. No conversion from Java 8 CompletableFuture to clojure async primitives in 2022. And i think they not going to support it in the near future.
What i am saying is that Java is in the future, and Clojure is in the past. They just cannot catch with new Java features and i doubt they are going to support it ever. You can still run it on modern jvm because they update the bytecode but that is all.
newlisp|3 years ago
Ouch, Java 8 was released in 2014. To be fair, Clojure was never a community project though.
vario|3 years ago
guhidalg|3 years ago
- Tons of developers know it - Tons of Java developers can be made to know it with ease - A good default IDE experience within VS and VSCode, and a JetBrains product if you prefer it. - A good LSP implementation with OmniSharp if you don't want to use an IDE. - ASP.NET, a good default Web framework. - NuGet as a package manager with tens of thousands of packages. - Better than java reflection and runtime generics. - Cross-platform CLI tooling since .NET Core, now it's just .NET. - Ability to deploy self-contained applications. - Mono version of C# is used for making games. - A continuously evolving cohesive language with minimal competitors (like Groovy, Kotlin, Scala, Clojure, etc... on the JVM) - F# if you want a stricter functional language that interoperates with C# seamlessly. - PowerShell as a way of interactively running any .NET assembly, regardless of how it was compiled.
And many more... C# is one language you can build a career on and also use for hobbying and have fun.
The haters will complain that MSBuild (the default build system) and Visual Studio suck. If you've tried them in the past, you're probably right. Try them again in 2022 and see if your opinion doesn't change.
mylons|3 years ago
haolez|3 years ago
capableweb|3 years ago
Clojure has pitfalls for sure, but no need to be dishonest in order to flag them.
cageface|3 years ago
That said I would love to work in a lisp full time. There's just something appealingly elegant about it.
ducktective|3 years ago
vindarel|3 years ago
There's one framework that looks promising to build fully dynamic apps in pure CL with one code base (websockets inside). It provides a GUI-like experience to build all kind of apps (a website, a chat, the snake game…): https://github.com/rabbibotton/clog/
I am using Hunchentoot, a routing library on top (easy-routes), the Mito ORM, and for the client side I am conservative: HTML templates with Djula, interactivity with HTMX, Vue if required, JS.
The great thing is that I can build a standalone binary of my web app, including the static assets, the webserver, the lisp compiler and debugger… for ±28MB unzipped and instantaneous startup times.
https://lispcookbook.github.io/cl-cookbook/web.html
https://github.com/CodyReichert/awesome-cl#web-frameworks
https://lisp-journey.gitlab.io/blog/lisp-for-the-web-deploy-...
mejutoco|3 years ago
aidenn0|3 years ago
I use cl-who[1] for generating html and parenscript for javascript. I use clack on the backend, but hunchentoot is probably more popular. Both backends have plenty of routing libraries available (hunchentoot comes with a decent one baked in, clack does not).
postmodern is a Postgres specific sql backend that is great. There are database-agnostic SQL libraries as well (clsql and cl-dbi I believe are the two big ones) but I haven't tried them.
1: People whose opinions I trust have told me that spinneret is a better choice. It did not exist when I learned cl-who. cl-who is "good enough" for me that I haven't switched.
vindarel|3 years ago
Example apps I can think of:
Screenshot bot: https://github.com/screenshotbot/screenshotbot-oss
Webcheckout: https://webcheckout.net/ (they were hiring recently)
Math Pastebin: https://github.com/susam/mathb
Ultralisp: https://ultralisp.org/ (built with their Weblocks refactoring)
A programmable desktop and bookmark application with CLOG (TEASER) https://www.reddit.com/gallery/w4rj4k (https://codeberg.org/mmontone/mold-desktop/)
unknown|3 years ago
[deleted]
lemper|3 years ago
so, yeah. while i'm excited with lisp, i don't think i have the gut to start my own shop with clojure as the main language.
ghufran_syed|3 years ago
drikerf|3 years ago
bambam24|3 years ago
[deleted]
bhanumanish|3 years ago
[deleted]
as4hretret|3 years ago
[deleted]