4 ms·

I would wonder: is there any person with (enough of) experience with both Clojure and Kotlin to say how these two compare together as Java alternatives? Couple

I would wonder: is there any person with (enough of) experience with both Clojure and Kotlin to say how these two compare together as Java alternatives? Couple of years ago I was looking for "Java.next" and back then I chose Clojure. Needless to say I have been sooo happy with the language... Now for past year or so I have heard so much praise on Kotlin - it always came from Java devs and it seems like a great language with great support from IntelliJ and I am very enticed (but sadly have not enough time to play with it). So I'd wonder how this language is perceived by fellow people from Clojure community...

poe876 8y ago
Kotlin is bullshit.
swsieber 8y ago
I'm somewhat familiar with Kotlin, but not really with Clojure. My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.
yogthos 8y ago
Kotlin is basically a flavor of Java that cleans up some syntax quirks, and adds some new ones. I think it's overall a cleaner language than Java, but it's not fundamentally different from it. I certainly wouldn't view it as a next generation language. I think it's important to step back and consider the history of programming languages to understand why mainstream languages look the way they do. Hardware was very limited in the 70s. The Intel 4004 CPU that came out in 1971 clocked in at 740 kHz, and it was coupled with a few kilobytes of memory. So the language had to be optimized to squeeze every last possible bit of performance from this limited hardware. You didn't have to worry about concurrency, there weren't any consumer grade multicore CPUs, and networking wasn't prevalent at the time. C solved that problem very well. It was effectively portable assembly allowing you to write extremely efficient code that could be compiled across different architectures. Meanwhile, advanced languages like Lisp required super computers at the time, and only a small number of people was lucky enough to work with them. So, a whole generation of programmers grew up on C, and they went on to design languages that look like C. The problems we face today are completely different from those we solved in the 70s. We work with much larger codebases, we often work in teams, we have multicore chips, and networking is prevalent. Things like managed runtimes, GC, and threading that were absurdly expensive in the 70s are common today, but C family of languages aren't optimized to take advantage of that. Raw performance is no longer a priority because developer time is far more expensive than hardware. This means that we need to optimize for clean and maintainable code that's concurrency friendly. Languages like Clojure and Haskell are a new breed of languages that are designed to solve modern problems, and that's the fundamental difference between Kotlin and Clojure in my opinion.
- lispm 8y ago
  LISP was implemented on the PDP-1 in the early sixties - originally it was implemented for the IBM 704 in 1959. C was implemented on a larger machine, the PDP-11 in the early 70s. There were LISP implementations for the PDP-11 - Richard Stallman himself wrote one. One of the problems was that LISP was not friendly to timesharing, since a LISP program could take over the whole RAM and something like GC would walk over lots of memory, which meant lots of slow memory swapping in machines with virtual memory. It was then best to use LISP when alone on such a machine.
  - yogthos 8y ago
    I'm well aware of the origins of LISP, but reality is that C model is much closer to hardware architecture used in commodity hardware at the time. C made a lot of sense under the constraints, and that's the reason it became popular.
    - lispm 8y ago
      Other than what you wrote, LISP did not need 'super computers'. It ran on the same and smaller machines as the original C. A PDP-1 was never a 'super computer', neither were the other PDPs. They were 'minicomputers' or 'mainframes'. Actually super computers (CDC, Cray, ...) were not a particular popular target for LISP implementations, ...
      - yogthos 8y ago
        Fair point, you didn't actually need super computers to run LISP.
iammiles 8y ago
I'm by no means an expert in either language, but for two years I learned / tinkered with Clojure as my main language for personal use. In 2015 I started a new job which required me to learn Kotlin. I've found that Kotlin has not only been a joy to work with ergonomically, but that its seamless interop with Java and the tooling make me far more productive than I could hope to be with Clojure. I love Clojure and enjoy solving puzzles with it, but I can't seem to get anywhere near the level of productivity out of it like I can with Kotlin.
- slowmovintarget 8y ago
  Kotlin is a Honda Accord. Good, solid, little fuss, more pleasant than you'd expect from the outside. Closure is an Alfa Romeo. Amazing, beautiful, frustrating, satisfying, and like nothing else when you get it going.
pdpi 8y ago
Kotlin is fundamentally a nicer Java. Clojure is a Lisp-like language on the JVM. They fulfil very different roles and promote wildly different styles. If you're genuinely happy with either, the other is unlikely to offer what you're looking for.
- edem 8y ago
  It is a LISP.
Scarbutt 8y ago
I prefer Clojure but if you need to develop for android then theres no decision to make, Kotlin wins. Being able to write the backend code for your android mobile app in the same language also makes Clojure less appealing.
edem 8y ago
I have worked with both professionally for 3+ years so here are my 2 cents: Kotlin is like buying a Volkswagen Passat after having a Golf. Clojure is like buying a BMW. The former is a reliable and solid workhorse, with a bit of charm. The latter is a powerhouse with flaws. If I only evaluate them based on their merits on paper Clojure definitely comes out on the top. The problem is that there are countless other factors. While Kotlin is just a Turbo Java, Clojure has a completely new paradigm. With Kotlin I get an IDE which is superb, I get all the tools Java has. The interop is amazing. With Clojure the only IDE which worked for me was Emacs but even that is a bit flawed. When I used Clojure I always had this mental overhead of fiddling with Emacs, the concepts of Clojure which are not inherent in LISP and so on. In the end, I dumped Clojure for Kotlin because I don't see a future for Clojure. I can't get contributors for my open source projects for Clojure but with Kotlin they just come and do some pull requests. I can't get Clojure programmers in my home country because there are like 40 of them in the whole country and most importantly I can't convert Java programmers to Clojure programmers. Kotlin, on the other hand, is not a big mental leap from Java and a lot of Java developers are excited about it. When I want to hire someone to work on a Kotlin project I can just bring in Java devs who are interested because they get up to speed in a matter of days. The other problem with Clojure is that it has so much baggage over the basic LISP concept. It is not simple enough to pick up for most programmers with 0 FP experience. If I want a LISP I'd rather go for Racket which is actually simple.
- edem 8y ago
  I do have to add that I still miss Clojure and its homoiconicity every time I bump into a limitation of metaprogramming in Kotlin or any other language which is not LISP...
- yogthos 8y ago
  I've been working with Clojure for about 8 years professionally now, and I haven't touched Emacs in all that time. I started with CCW for Eclipse, and later moved to Cursive with IntelliJ. I find the IDE experience for Clojure is quite reasonable now. You get a lot of what you'd expect in terms IDE support such as automatically requiring namespaces on usage, finding usages for symbols, auto-refactoring, and so on. In terms of hiring developers my team hasn't had a problem with that either. We've only hired a single person who knew Clojure ahead of time, and we trained the rest of the hires on it on the job. Our experience is that it takes about a couple of weeks for somebody to start writing useful code with guidance. We start by doing a bit of pairing, and we do code reviews for pull requests where we help make sure new hires are writing idiomatic code. When you have at least one experienced Clojure dev on the team already, onboarding tends to be pretty smooth. One huge benefit we found posting for Clojure is that we get completely different set of applicants than when we posted for Java. There are many excellent Java devs out there, however finding them is like looking for a needle in a haystack and you're competing with many other companies for them. Meanwhile, most people applying for Clojure jobs tend to have genuine interest in learning something new, and they're very enthusiastic about it. We get a smaller pool of applicants, but on the other hands most of the people applying are actually worth considering.

poe876 8y ago

Kotlin is bullshit.

swsieber 8y ago

I'm somewhat familiar with Kotlin, but not really with Clojure. My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.

yogthos 8y ago

Kotlin is basically a flavor of Java that cleans up some syntax quirks, and adds some new ones. I think it's overall a cleaner language than Java, but it's not fundamentally different from it. I certainly wouldn't view it as a next generation language. I think it's important to step back and consider the history of programming languages to understand why mainstream languages look the way they do. Hardware was very limited in the 70s. The Intel 4004 CPU that came out in 1971 clocked in at 740 kHz, and it was coupled with a few kilobytes of memory. So the language had to be optimized to squeeze every last possible bit of performance from this limited hardware. You didn't have to worry about concurrency, there weren't any consumer grade multicore CPUs, and networking wasn't prevalent at the time. C solved that problem very well. It was effectively portable assembly allowing you to write extremely efficient code that could be compiled across different architectures. Meanwhile, advanced languages like Lisp required super computers at the time, and only a small number of people was lucky enough to work with them. So, a whole generation of programmers grew up on C, and they went on to design languages that look like C. The problems we face today are completely different from those we solved in the 70s. We work with much larger codebases, we often work in teams, we have multicore chips, and networking is prevalent. Things like managed runtimes, GC, and threading that were absurdly expensive in the 70s are common today, but C family of languages aren't optimized to take advantage of that. Raw performance is no longer a priority because developer time is far more expensive than hardware. This means that we need to optimize for clean and maintainable code that's concurrency friendly. Languages like Clojure and Haskell are a new breed of languages that are designed to solve modern problems, and that's the fundamental difference between Kotlin and Clojure in my opinion.

lispm 8y ago
LISP was implemented on the PDP-1 in the early sixties - originally it was implemented for the IBM 704 in 1959. C was implemented on a larger machine, the PDP-11 in the early 70s. There were LISP implementations for the PDP-11 - Richard Stallman himself wrote one. One of the problems was that LISP was not friendly to timesharing, since a LISP program could take over the whole RAM and something like GC would walk over lots of memory, which meant lots of slow memory swapping in machines with virtual memory. It was then best to use LISP when alone on such a machine.
- yogthos 8y ago
  I'm well aware of the origins of LISP, but reality is that C model is much closer to hardware architecture used in commodity hardware at the time. C made a lot of sense under the constraints, and that's the reason it became popular.
  - lispm 8y ago
    Other than what you wrote, LISP did not need 'super computers'. It ran on the same and smaller machines as the original C. A PDP-1 was never a 'super computer', neither were the other PDPs. They were 'minicomputers' or 'mainframes'. Actually super computers (CDC, Cray, ...) were not a particular popular target for LISP implementations, ...
    - yogthos 8y ago
      Fair point, you didn't actually need super computers to run LISP.

iammiles 8y ago

I'm by no means an expert in either language, but for two years I learned / tinkered with Clojure as my main language for personal use. In 2015 I started a new job which required me to learn Kotlin. I've found that Kotlin has not only been a joy to work with ergonomically, but that its seamless interop with Java and the tooling make me far more productive than I could hope to be with Clojure. I love Clojure and enjoy solving puzzles with it, but I can't seem to get anywhere near the level of productivity out of it like I can with Kotlin.

slowmovintarget 8y ago
Kotlin is a Honda Accord. Good, solid, little fuss, more pleasant than you'd expect from the outside. Closure is an Alfa Romeo. Amazing, beautiful, frustrating, satisfying, and like nothing else when you get it going.

pdpi 8y ago

Kotlin is fundamentally a nicer Java. Clojure is a Lisp-like language on the JVM. They fulfil very different roles and promote wildly different styles. If you're genuinely happy with either, the other is unlikely to offer what you're looking for.

edem 8y ago
It is a LISP.

Scarbutt 8y ago

I prefer Clojure but if you need to develop for android then theres no decision to make, Kotlin wins. Being able to write the backend code for your android mobile app in the same language also makes Clojure less appealing.

edem 8y ago

I have worked with both professionally for 3+ years so here are my 2 cents: Kotlin is like buying a Volkswagen Passat after having a Golf. Clojure is like buying a BMW. The former is a reliable and solid workhorse, with a bit of charm. The latter is a powerhouse with flaws. If I only evaluate them based on their merits on paper Clojure definitely comes out on the top. The problem is that there are countless other factors. While Kotlin is just a Turbo Java, Clojure has a completely new paradigm. With Kotlin I get an IDE which is superb, I get all the tools Java has. The interop is amazing. With Clojure the only IDE which worked for me was Emacs but even that is a bit flawed. When I used Clojure I always had this mental overhead of fiddling with Emacs, the concepts of Clojure which are not inherent in LISP and so on. In the end, I dumped Clojure for Kotlin because I don't see a future for Clojure. I can't get contributors for my open source projects for Clojure but with Kotlin they just come and do some pull requests. I can't get Clojure programmers in my home country because there are like 40 of them in the whole country and most importantly I can't convert Java programmers to Clojure programmers. Kotlin, on the other hand, is not a big mental leap from Java and a lot of Java developers are excited about it. When I want to hire someone to work on a Kotlin project I can just bring in Java devs who are interested because they get up to speed in a matter of days. The other problem with Clojure is that it has so much baggage over the basic LISP concept. It is not simple enough to pick up for most programmers with 0 FP experience. If I want a LISP I'd rather go for Racket which is actually simple.

edem 8y ago
I do have to add that I still miss Clojure and its homoiconicity every time I bump into a limitation of metaprogramming in Kotlin or any other language which is not LISP...
yogthos 8y ago
I've been working with Clojure for about 8 years professionally now, and I haven't touched Emacs in all that time. I started with CCW for Eclipse, and later moved to Cursive with IntelliJ. I find the IDE experience for Clojure is quite reasonable now. You get a lot of what you'd expect in terms IDE support such as automatically requiring namespaces on usage, finding usages for symbols, auto-refactoring, and so on. In terms of hiring developers my team hasn't had a problem with that either. We've only hired a single person who knew Clojure ahead of time, and we trained the rest of the hires on it on the job. Our experience is that it takes about a couple of weeks for somebody to start writing useful code with guidance. We start by doing a bit of pairing, and we do code reviews for pull requests where we help make sure new hires are writing idiomatic code. When you have at least one experienced Clojure dev on the team already, onboarding tends to be pretty smooth. One huge benefit we found posting for Clojure is that we get completely different set of applicants than when we posted for Java. There are many excellent Java devs out there, however finding them is like looking for a needle in a haystack and you're competing with many other companies for them. Meanwhile, most people applying for Clojure jobs tend to have genuine interest in learning something new, and they're very enthusiastic about it. We get a smaller pool of applicants, but on the other hands most of the people applying are actually worth considering.