Startup time isn't what is holding the language back. In my opinion it's:
1. Tooling. You end up spending way more time getting your tooling setup than it should be.
2. Difficulty in learning.
3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices.
The last point has many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.
This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable.
So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working.
Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.
Instead of just measuring how many developers adopt Clojure and how difficult/easy that is, I'd also love a measure of how many developers Clojure "puts out of business". IME Clojure is quite aggressive on that front.
In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired and fired 4. When I left they had 3. All 3 were not experienced in Clojure prior to the project (Java), but by 2018 each knew the entire codebase and was able to modify it and able to step in for each other. They spent less than half of their budget and all goals were met ahead of schedule.
IME learning how to put Clojure and its ecosystem in good use takes more time and effort than other languages, but its effectiveness really compensates.
I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things
But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting the new one true way because most of us are refugees from other languages where it's already happened
As someone just playing with Clojure for curiosity, I agree that it's hard to find a way through the thicket of available tooling & library options.
On the other hand, to start with just picking something reasonably mainstream (in Clojure terms) is a perfectly good strategy. The choice will be poorly informed, but that's a given if you're a beginner in any case. And such a beginner isn't really in a place anyway to make this choice for a significant project (for any platform/language).
Once an initial choice is made, it seems to me (so far) pretty easy with leinigen templates & plugins just to get started on something. Time from tool setup to coding hasn't been any longer for me than other things I've learned in recent years.
What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it.
The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell.
Ultimately rust (and go to some extent) seemed to fit my use cases better.
If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).
The other interesting problem is that the experts are using tools and concepts that are a long way away from a beginner and that can make it harder for beginners to learn. In Clojure when a beginner wants to accomplish a task their biggest problem is that they are solving the wrong problem or being pushed to deal with problems they don't understand.
Case in point the var/agent/ref system is fantastic and probably critical to how to think about Clojure projects - but the problems being solved by it are a long way away from the concerns of someone at the beginner-intermediate type level. They don't need to solve multithreading right now. They don't see their data model as an urgent priority.
Compare that to Python where most of the core language is (1) call function, solve problem or (2) feature does something you could already do but with a little less typing.
I prefer Clojure but it is easy to see that the lack of an opinionated onboarding process is going to hurt the language.
> Startup time isn't what is holding the language back.
For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead).
> For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.
More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.
Great language and ecosystem. I donated at the beginning and made my living writing Clojure code for a few years. However, I find myself way more productive using Common Lisp, perhaps because since I have used it since 1982.
I think Clojure’s sweet spot is a small team working on a large enterprise project.
If you want to get started, Clojurists will insist you learn emacs. After all it's so great you must learn it.
Now I have nothing against emacs.
But I don't expect to have to invest significant effort to learn a specific editor in order to use a programming language. No other programming language has this requirement.
I was surprised at how many Clojure users took this as an attack upon emacs. It took some careful explaining to make the point that I have better things to invest my time into, such as building more code in Clojure, rather than learning yet another tool, that does something for which I have other tools already.
There were some great IDEs for Clojure. But they have all fallen into disrepair and being unmaintained.
Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.
My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic.
At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time?
I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so.
Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make.
That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there.
I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.
Over and over again, they have been perfecting the art of "building things fast." The problem [with the most] programming languages today, that although they provide frameworks, command-line tools, code generators, etc. to build things quickly, the codebases very quickly become difficult to maintain and scale.
So many times, I have seen it myself. I quit jobs simply because I exhausted my mental and cognitive capacity to deal with the code that I wrote myself several months ago.
While Clojure codebases, no matter how messy they can get, they feel very much like gardens - you can slowly and organically keep growing them.
Some may say: "You're talking about Haskell, or Scala, (or some other language)" And in my experience, although you can do pretty cool things in those languages, sometimes simple, dumbed-down solutions are better. Some may argue: "Now you're talking about Python, or Go...". I think Clojure has a perfect balance between "sophisticated, ultrasmart" PLs and Pls with the books titled "X for complete idiots."
I think Clojure is an ideal language for writing business apps and more and more companies starting to see that.
Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully.
I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
Your test is basically asking “is it similar to something popular”, there will always be a learning curve when changing to a new, different from what you’re used to, tool. In my personal experience, I’ve seen people go from no Clojure or functional programming knowledge to productive in a few weeks, that’s quicker than I’ve seen some people go from non-OO to OO (although I imagine it has more to do with the people than with the paradigms)
I think it's a problem loop. No one wants to use Clojure because it's hard to impossible finding Clojure Devs. Also no one wants to learn it for the same reasons. The demand is less to non-existent to a point any time spent learning Clojure is unlikely to give any substantial returns.
I shifted to writing Clojure full time in November 2017 and feel that I've improved greatly as a developer.
Other languages taught me how to solve problems their way, Clojure taught me how to solve problems.
My biggest hurdle while getting started was lack of Newbie friendly resources. And the language is kinda scary at first, specially if you are like me and have spent 5 years working with Python or JS.
Dr. Fynmann said that if you want to get better at something, teach it.
Following his advice I've published multiple articles [1][2][3][4] and given a talk about Clojure at a js conf [5].
The tooling is steadily improving. I don't think it will be as widespread as JS but I doubt if it aims to be. Clojure seems to attract a certain kind of developers anyways.
Thats last few sentences make no sense. The argument is that uptake is stunted by the JVM's slow startup time, making it unsuitable for commandline utils or desktop apps. However thats easily fixed which was never more hillariously stated than when Rich Hickey did it a decade ago. A blogpost went viral and it was a thunderous critique of Clojure, focused on this single point of slow start up. In the comment section was only 1 reply from Rich:
The most interesting Clojure-like language around is, IMO, Carp[^1]. Carp is a Lisp written in Haskell that compiles down to C with Rust ownership semantics and looks like Clojure. So you get a GC-less Lisp with fast startup time that is suitable for game development with the safety guarantees of Rust.
I really like Clojure, it's a well designed language and one can get quite productive, surprisingly fast.
My core criticism that is not really mentioned in the article is the error messages. At the beginning I often felt lost and had no idea where to look if something went wrong.
I used to work at a large Clojure shop. I've moved on, and I've heard anecdotally that they are building most new stuff in Go.
Barrier for entry and continued use in that limited experience was:
- Learning curve for new developers is very high in comparison to other languages, so moving existing engineers over sucks.
- Experienced Clojure developers want a job where they can "do Clojure", not necessarily because they're interested in the problems the business was created to solve, so hiring sucks.
- Lots of conversations turn to "the Clojure way" to solve a problem rather than using industry accepted protocols, standards and tooling. I mean, OK, but this makes interacting with the rest of the World a bit sucky.
- Most libraries never get to v1.0. Most people write 0.0.1 and may do some minor updates so you see it get to 0.0.5 and then it stays there. That's probably because it all 'just works', but it scares most devs when they see that and are about to bake it into their next release.
- Deployment is a known quantity and the JVM is useful in this regard, but it doesn't have the pure simplicity that some other runtimes do. Clojure implementations in other runtimes (Joker, Clojerl, etc.), might help or hinder here.
Startup time is a problem on CLI and desktop apps, sure. At my ex-employer, one server deployed app took several minutes to start and that had challenges.
That was not - I think - the reason the team started to look elsewhere or the reason I'm more likely to pick up Ruby, Python, Go or Elixir for my next project. There are lots of rough edges like the ones I identify above - many of them cultural - that need to be smoothed out a little, I think.
I look forward to functional methods becoming mainstream (again?), and Clojure could get there, so I wish the community luck.
1. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer.
2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means.
3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem.
4. Error messages. Even after years of Clojure. I still find it hard.
5. Documentation. Most of the packages I use don't have dedicated websites or good documentation.
Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.
It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is.
For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to.
It's non-trivial to set this up (more because of lack of consolidated info rather than time it takes), but it can easily be standardized across machines/envs (I Dockerize all projects in a simple way to allow team members to get started up with REPLs easily).
For me, this article is spot on. I had been looking for a long time for my one language I can use for everything, and Clojure finally (just recently) got there. I can use it for scripting, writing command line apps, making backend services, writing web front-ends, making desktop applications with GUI, toying with generative art, doing data-science, making games, and more.
It really has great reach, and its only getting better. Similarly, in terms of programming language, you can use it to explore many paradigms and innovative ideas, like CSP, logic, probabilistic, functional, meta, concurrent, dynamic, typed, contracts, data-flow, OOP, condition systems, monads, etc. All this keeps me interested and constantly learning. Never having to wait for features you miss or wish you had.
I can see myself sticking with Clojure for a long time.
Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph:
> The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and backend differ mostly just in the way that the different implementations access the host platform. The functional aspects of Clojure, especially the immutability and focus on referential transparency, ensure that source code is mostly split into chunks of highly portable code, with the host-interop conveniently put aside in its own sections. You can move code between frontend and backend at your leisure.
Is it really that good using Clojure across environments and runtimes?
I ask because I tried all of this with Scala years ago (I loved the language) and Ruby to an extent, but it was pretty miserable or rather there was really no reward but more effort on my part. I.e. I'd spend more time annotating, bridging, and learning how to interact with the different runtime than I would writing actual feature code[1].
Or like what are the killer libraries everyone loves? Do they (libs/frameworks) support different clojure runtimes ("hosts?") outta the box? Is it easy to write "pure clojure" projects that work for any clojure project?
The one I know about or have heard most about was Datatomic, which always sounded freakin' brilliant, but I don't fucks with non-free databases. Arcadia I just saw and it looks cool but, it also seems like a dumb mountain to climb, if that's how I wanted to start screwing around with Clojure.
[1] Tools like Scala/ScalaJS and RubyMotion (back in the day, heh), were the reasons I ended up a polyglot. They're great tools, if you know the platform, if you don't, you're pretty much still fucked... but once you know the platform it's kind of hard to want to use them.
I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort.
Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form.
Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings.
Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.
Interop with hosts is a core feature of the language so it feels natural to reach for it when you need it and it's easy to write code that handles multiple runtimes but 95% of the time maybe more you don't need explicit runtime features
I don’t actually get the big deal about enforced immutability. Of course, you need to constrain yourself in certain circumstances to do things immutably, but it seems like something that should be contextual (immutably ...), rather than enforcing it. In fact, sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously. Moreover, most serious lisp programmers almost write immutably by default. The only (common) exception being hash tables, but you just don’t use them if you need more control.
What I want to know is where to find a Clojure and/or ClojureScript job. I got a taste of Clojure on a project late last year and became enamored with it. So much so that I would love to find a job where I can use it at least part of the time.
The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language.
If you want fast startup times, just live in emacs, keeping multiple shells alive underneath. You can build yourself a whole clojure repl that just lives there all the time (startup once), and a bash or whatever you like as well.
Clojure is functional to the core and innovates a lot of areas, while other Lisps are more multi-paradigm and slant towards an OOP style. If you want to work universally with persistent data structures in your code and the libraries you use, Clojure is really the only option. Clojure also modernises Lisp syntax slightly (and a bit controversially) by getting rid of lots of parentheses and introducing new styles of parens for the core built-in data structures: ( ) [ ] { } #{ }. There's a bunch of other stuff, but really, Clojure is significantly different from other lisps.
Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves.
For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure. Gerbil Scheme also looks promising.
For me I’m most often writing smallish standalone apps, which I feel are easier to make in Racket than Clojure. But between the two languages, I’d probably take Clojure if I didn’t have the JVM along for the ride. Of course the JVM is also one of Clojure’s biggest strengths. Also, I don’t trust Oracle enough to stop pretending that Graal doesn’t exist.
I don’t think being a lisp is the primary reason for using Clojure, but it’s the added bonus of being a lisp designed for FP, concurrency, and host VM integration.
My personal take: CL is a multi-paradigm rummage bin that demonstrated to the world the greatness of many features (e.g. macros, CLOS), but is also beset by many design flaws--some due to genuine infelicity of conception, and some due to unavoidable limitations of software and hardware at the time. (For one thing, there are approximately 101 ways to test equality). The result is that you could be a career CL programmer and see code written in a style you've never seen before, and that it suffers from design flaws that, if fixed, would result in something that would no longer be Common Lisp. Scheme's problem is kind of the opposite: it's stripped down, but also has not purged all of CL's unfortunate baggage, and very conspicuously lacks an out-of-the-box and full-featured package manager.
Clojure, being just over 10 years old, has gotten to benefit from decades of witnessing other languages' spectacular design disasters, and it was designed by one person in a few years instead of by committee over decades. This results in a language that is much more aesthetically coherent, adhering to a pragmatic flavor of FP, and avoids a lot of gnarly warts: for instance, Clojure has one basic way to test equality irrespective of data type, and all basic data structures are immutable.
I'd like to have a broad view of how many lispers working with one.
the few I know:
- scheme had a coma period due to specs issues (scheme small and large standard)
- commonlisp .. no idea but it seems quicklisp is enough for anybody to work, and there are many libs. Maybe not java/python levels .. but many. It's just out of the radar.
For anyone struggling with dynamic typing in Clojure, thinking it's impossible to manage and even harder to build confidence in your code, please look at Spec and Orchestra. You can easily build predicative contracts for all of your data and know as soon as anything "goes wrong" in terms of your data shapes.
I think everyone using Clojure JVM, ClojureScript, or Clojure CLR should be doing this.
[+] [-] tensor|6 years ago|reply
1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices.
The last point has many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.
This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable.
So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working.
Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.
[+] [-] lgrapenthin|6 years ago|reply
In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired and fired 4. When I left they had 3. All 3 were not experienced in Clojure prior to the project (Java), but by 2018 each knew the entire codebase and was able to modify it and able to step in for each other. They spent less than half of their budget and all goals were met ahead of schedule.
IME learning how to put Clojure and its ecosystem in good use takes more time and effort than other languages, but its effectiveness really compensates.
[+] [-] slifin|6 years ago|reply
I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things
But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting the new one true way because most of us are refugees from other languages where it's already happened
[+] [-] crispinb|6 years ago|reply
On the other hand, to start with just picking something reasonably mainstream (in Clojure terms) is a perfectly good strategy. The choice will be poorly informed, but that's a given if you're a beginner in any case. And such a beginner isn't really in a place anyway to make this choice for a significant project (for any platform/language).
Once an initial choice is made, it seems to me (so far) pretty easy with leinigen templates & plugins just to get started on something. Time from tool setup to coding hasn't been any longer for me than other things I've learned in recent years.
[+] [-] inferiorhuman|6 years ago|reply
The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell.
Ultimately rust (and go to some extent) seemed to fit my use cases better.
If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).
[+] [-] roenxi|6 years ago|reply
Case in point the var/agent/ref system is fantastic and probably critical to how to think about Clojure projects - but the problems being solved by it are a long way away from the concerns of someone at the beginner-intermediate type level. They don't need to solve multithreading right now. They don't see their data model as an urgent priority.
Compare that to Python where most of the core language is (1) call function, solve problem or (2) feature does something you could already do but with a little less typing.
I prefer Clojure but it is easy to see that the lack of an opinionated onboarding process is going to hurt the language.
[+] [-] doglooksgood|6 years ago|reply
[+] [-] billfruit|6 years ago|reply
Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python.
There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job.
Also when exeptions occur clojure does not give an interactive repl like other lisps.
[+] [-] amelius|6 years ago|reply
[+] [-] Goladus|6 years ago|reply
For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead).
> For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.
More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.
[+] [-] mark_l_watson|6 years ago|reply
I think Clojure’s sweet spot is a small team working on a large enterprise project.
[+] [-] DannyB2|6 years ago|reply
If you want to get started, Clojurists will insist you learn emacs. After all it's so great you must learn it.
Now I have nothing against emacs.
But I don't expect to have to invest significant effort to learn a specific editor in order to use a programming language. No other programming language has this requirement.
I was surprised at how many Clojure users took this as an attack upon emacs. It took some careful explaining to make the point that I have better things to invest my time into, such as building more code in Clojure, rather than learning yet another tool, that does something for which I have other tools already.
There were some great IDEs for Clojure. But they have all fallen into disrepair and being unmaintained.
[+] [-] hota_mazi|6 years ago|reply
It's on the wrong side of history in that respect.
I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late.
Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never catch it now.
[+] [-] peferron|6 years ago|reply
[+] [-] vemv|6 years ago|reply
At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time?
I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so.
Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make.
That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there.
I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.
[+] [-] iLemming|6 years ago|reply
That's precisely the reason why Clojure attracts seasoned, experienced, grumpy developers.
Over and over again, they have been perfecting the art of "building things fast." The problem [with the most] programming languages today, that although they provide frameworks, command-line tools, code generators, etc. to build things quickly, the codebases very quickly become difficult to maintain and scale.
So many times, I have seen it myself. I quit jobs simply because I exhausted my mental and cognitive capacity to deal with the code that I wrote myself several months ago.
While Clojure codebases, no matter how messy they can get, they feel very much like gardens - you can slowly and organically keep growing them.
Some may say: "You're talking about Haskell, or Scala, (or some other language)" And in my experience, although you can do pretty cool things in those languages, sometimes simple, dumbed-down solutions are better. Some may argue: "Now you're talking about Python, or Go...". I think Clojure has a perfect balance between "sophisticated, ultrasmart" PLs and Pls with the books titled "X for complete idiots."
I think Clojure is an ideal language for writing business apps and more and more companies starting to see that.
[+] [-] ken|6 years ago|reply
I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
[+] [-] dkersten|6 years ago|reply
[+] [-] kamaal|6 years ago|reply
[+] [-] shivekkhurana|6 years ago|reply
Other languages taught me how to solve problems their way, Clojure taught me how to solve problems.
My biggest hurdle while getting started was lack of Newbie friendly resources. And the language is kinda scary at first, specially if you are like me and have spent 5 years working with Python or JS.
Dr. Fynmann said that if you want to get better at something, teach it.
Following his advice I've published multiple articles [1][2][3][4] and given a talk about Clojure at a js conf [5].
The tooling is steadily improving. I don't think it will be as widespread as JS but I doubt if it aims to be. Clojure seems to attract a certain kind of developers anyways.
---
[1] What I learned after writing Clojure for 424 days, straight https://krimlabs.com/blog/clojure-424-days
Learn Clojure by building a drug dealer api [2] https://krimlabs.com/blog/clojure-drug-dealer-part-1 [3] https://krimlabs.com/blog/clojure-drug-dealer-part-2 [4] https://krimlabs.com/blog/clojure-drug-dealer-part-3
[5] If you are going to transpile JS, why not use ClojureScript? https://www.youtube.com/watch?v=Bs44qdAX5yo
[+] [-] lbj|6 years ago|reply
time java -client -jar clojure.jar helloworld.clj
> system time 0.0001s
The -client param makes all the difference :)
[+] [-] pgt|6 years ago|reply
[^1]: https://github.com/carp-lang/Carp
[+] [-] Random_ernest|6 years ago|reply
My core criticism that is not really mentioned in the article is the error messages. At the beginning I often felt lost and had no idea where to look if something went wrong.
[+] [-] PaulRobinson|6 years ago|reply
Barrier for entry and continued use in that limited experience was:
- Learning curve for new developers is very high in comparison to other languages, so moving existing engineers over sucks.
- Experienced Clojure developers want a job where they can "do Clojure", not necessarily because they're interested in the problems the business was created to solve, so hiring sucks.
- Lots of conversations turn to "the Clojure way" to solve a problem rather than using industry accepted protocols, standards and tooling. I mean, OK, but this makes interacting with the rest of the World a bit sucky.
- Most libraries never get to v1.0. Most people write 0.0.1 and may do some minor updates so you see it get to 0.0.5 and then it stays there. That's probably because it all 'just works', but it scares most devs when they see that and are about to bake it into their next release.
- Deployment is a known quantity and the JVM is useful in this regard, but it doesn't have the pure simplicity that some other runtimes do. Clojure implementations in other runtimes (Joker, Clojerl, etc.), might help or hinder here.
Startup time is a problem on CLI and desktop apps, sure. At my ex-employer, one server deployed app took several minutes to start and that had challenges.
That was not - I think - the reason the team started to look elsewhere or the reason I'm more likely to pick up Ruby, Python, Go or Elixir for my next project. There are lots of rough edges like the ones I identify above - many of them cultural - that need to be smoothed out a little, I think.
I look forward to functional methods becoming mainstream (again?), and Clojure could get there, so I wish the community luck.
[+] [-] ooooak|6 years ago|reply
2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means.
3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem.
4. Error messages. Even after years of Clojure. I still find it hard.
5. Documentation. Most of the packages I use don't have dedicated websites or good documentation.
Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.
[+] [-] anmonteiro90|6 years ago|reply
Interestingly, that's absolutely not my perspective and I don't see any sources for that statement in the post.
[+] [-] maehwasu|6 years ago|reply
It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is.
For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to.
It's non-trivial to set this up (more because of lack of consolidated info rather than time it takes), but it can easily be standardized across machines/envs (I Dockerize all projects in a simple way to allow team members to get started up with REPLs easily).
[+] [-] didibus|6 years ago|reply
It really has great reach, and its only getting better. Similarly, in terms of programming language, you can use it to explore many paradigms and innovative ideas, like CSP, logic, probabilistic, functional, meta, concurrent, dynamic, typed, contracts, data-flow, OOP, condition systems, monads, etc. All this keeps me interested and constantly learning. Never having to wait for features you miss or wish you had.
I can see myself sticking with Clojure for a long time.
[+] [-] rubyn00bie|6 years ago|reply
> The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and backend differ mostly just in the way that the different implementations access the host platform. The functional aspects of Clojure, especially the immutability and focus on referential transparency, ensure that source code is mostly split into chunks of highly portable code, with the host-interop conveniently put aside in its own sections. You can move code between frontend and backend at your leisure.
Is it really that good using Clojure across environments and runtimes?
I ask because I tried all of this with Scala years ago (I loved the language) and Ruby to an extent, but it was pretty miserable or rather there was really no reward but more effort on my part. I.e. I'd spend more time annotating, bridging, and learning how to interact with the different runtime than I would writing actual feature code[1].
Or like what are the killer libraries everyone loves? Do they (libs/frameworks) support different clojure runtimes ("hosts?") outta the box? Is it easy to write "pure clojure" projects that work for any clojure project?
The one I know about or have heard most about was Datatomic, which always sounded freakin' brilliant, but I don't fucks with non-free databases. Arcadia I just saw and it looks cool but, it also seems like a dumb mountain to climb, if that's how I wanted to start screwing around with Clojure.
[1] Tools like Scala/ScalaJS and RubyMotion (back in the day, heh), were the reasons I ended up a polyglot. They're great tools, if you know the platform, if you don't, you're pretty much still fucked... but once you know the platform it's kind of hard to want to use them.
[+] [-] scarredwaits|6 years ago|reply
Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form.
Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings.
Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.
[+] [-] slifin|6 years ago|reply
Interop with hosts is a core feature of the language so it feels natural to reach for it when you need it and it's easy to write code that handles multiple runtimes but 95% of the time maybe more you don't need explicit runtime features
[+] [-] abrax3141|6 years ago|reply
[+] [-] Zelphyr|6 years ago|reply
[+] [-] svnpenn|6 years ago|reply
https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...
[+] [-] reitzensteinm|6 years ago|reply
Leiningen works great on Windows, and Boot is meant to as well (though I don't have first hand knowledge of that).
[+] [-] iLemming|6 years ago|reply
Isn't it always? Basically anything that's not related to .NET has its warts in Windows. Erlang for example.
[+] [-] didibus|6 years ago|reply
It replaces the powershell code with a Clojure based executable.
[+] [-] zerr|6 years ago|reply
[+] [-] abrax3141|6 years ago|reply
[+] [-] gentleman11|6 years ago|reply
[+] [-] simongray|6 years ago|reply
The Rationale page on clojure.org has a pretty good rundown: https://clojure.org/about/rationale
[+] [-] peatmoss|6 years ago|reply
For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure. Gerbil Scheme also looks promising.
For me I’m most often writing smallish standalone apps, which I feel are easier to make in Racket than Clojure. But between the two languages, I’d probably take Clojure if I didn’t have the JVM along for the ride. Of course the JVM is also one of Clojure’s biggest strengths. Also, I don’t trust Oracle enough to stop pretending that Graal doesn’t exist.
[+] [-] hcarvalhoalves|6 years ago|reply
[+] [-] lgessler|6 years ago|reply
Clojure, being just over 10 years old, has gotten to benefit from decades of witnessing other languages' spectacular design disasters, and it was designed by one person in a few years instead of by committee over decades. This results in a language that is much more aesthetically coherent, adhering to a pragmatic flavor of FP, and avoids a lot of gnarly warts: for instance, Clojure has one basic way to test equality irrespective of data type, and all basic data structures are immutable.
[+] [-] agumonkey|6 years ago|reply
I'd like to have a broad view of how many lispers working with one.
the few I know:
- scheme had a coma period due to specs issues (scheme small and large standard)
- commonlisp .. no idea but it seems quicklisp is enough for anybody to work, and there are many libs. Maybe not java/python levels .. but many. It's just out of the radar.
[+] [-] bgorman|6 years ago|reply
[+] [-] armitron|6 years ago|reply
Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.
[+] [-] gumby|6 years ago|reply
[+] [-] Jeaye|6 years ago|reply
I think everyone using Clojure JVM, ClojureScript, or Clojure CLR should be doing this.
[+] [-] unknown|6 years ago|reply
[deleted]