7 ms·

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decis

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on. I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-like script replacement. It's not the only language I use of course, and Go is a strong second place most of the time especially if I need something compiled to a single binary. But Clojure is where I generally feel most at home thanks to the irreplaceable REPL based development flow which is more like a dialogue with my program than your typical write compile run loop. Combine that with it running on the JVM and you have a wonderful set of tools to get things done in a pleasant way. I strongly encourage anyone with even a passing interest in Lisp and functional programming to give it a try. If you're using VSCode there is the excellent Calva plugin to help you out.

nine_k 2y ago
As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things in less expressive languages, like shell scripts, or small C functions to help performance or FFI, or, well, tiny Go utilities.
- ReleaseCandidat 2y ago
  I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).
  - nine_k 2y ago
    That's cool! How do you manage? E.g. the `if err != nil { return err; }` stuff?
    - ReleaseCandidat 2y ago
      Well, in the context of Lisp, `err != nil` is equivalent to Lisp's parens: if somebody complains about that, chances are their critique is superficial (and there are enough "real" problems when using Go, especially when using goroutines and channels). The amount of low abstraction Go code I write is compensated by the amount of "abstraction boilerplate" like implementing type classes by myself or letting the compiler derive, implementing newtypes, adding GADTs, adding Pattern Synonyms and Type Families to be able to comfortably use the GADTs without much boilerplate and so on. Rust adds for example the need for associated types and is generally more verbose than Haskell. I do not see a significant difference in the amount of boilerplate needed for catching exceptions, pattern matching or branching on the existence of an error value. Nobody can stop you from implementing `bind` in Go for your error (which I did in some places), but of course Rust "wins" with its `?`.
- kubb 2y ago
  Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning. There's a population of people that don't like this kind of abstraction, because to understand the code you first need to understand the problem, the data flow and how it's expressed. They prefer to look at the issue "bottom up" than "top down", and for them Go is perfect, because instead of reasoning about what the module does, how the data flows, what the algorithm does, they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable. There's no better or worse here, just two types of people. Some like to look at the whole bridge, some like to examine the individual nuts and bolts and joints.
  - ReleaseCandidat 2y ago
    > There's no better or worse here, just two types of people. No, two types of solving a problem. I like writing both (Haskell and Go) - for _myself_ - but the tooling and standard library and ... of Go is orders of magnitudes better.
    - kubb 2y ago
      I would refrain from comparing Haskell - a research language intended for academia and created in universities, to Go - a pragmatic industry language intended for production and created in a megacorp. Why would Haskell's tooling be better? It's not reasonable to expect that.
      - ReleaseCandidat 2y ago
        I'm actually surprised Go's tooling as as good as it is _although_ it is made by Google. But to be fair, GoogleTest is OK too.
        2y ago
- a_wild_dandan 2y ago
  I must use PyTorch for ML, but badly wish I could use TypeScript instead. Its type system demolishes anything else I've used. Writing anything from SPI communications, to server logic, to rich GUIs is a breeze. Then I work in Python and have to fight `Any`s, ambiguous arguments, more verbose code, and bizarrely slow run times. It makes me sad.
  - nine_k 2y ago
    While I agree with you, Python is getting better in this regard, as is mypy. Making historical interfaces well-typed is another kettle of fish. For instance, Python's range() is actually two overrides with incompatible signatures. I bet PyTorch has more of such examples.
    - pjmlp 2y ago
      If it only had a V8 class JIT in the package as well.
- cess11 2y ago
  Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions. To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm most fluent in too. Either that or the problem is trivial and likely to be in most common programming languages.
  - nine_k 2y ago
    Java 7 is already pretty pleasant, and it has been improving ever since then. (Say what you want about Oracle Corporation, but as the wardens of Java they're doing a pretty good job.)
  - fiddlerwoaroof 2y ago
    I’ve been writing a lot of Java 11 recently, and I find it to just be a very pleasant environment to work in: the IDEs still are best in class, afaict; the newer APIs avoid a lot of the boilerplate I used to have to write out and there are generally mature libraries to interact with just about any system you might need. Where Clojure really shines is that it’s a really well thought-out layer that can leverage this ecosystem and adds its own well-designed tools on top for my preferred more-interactive development style.
  - ErikCorry 2y ago
    These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane. If you are making JavaScript look good you are failing as a language.
    - cess11 2y ago
      Typically I can use a forEach in such cases, and when I can't it's probably an incrementer and the IDE just switches out my int as an automatic solution to its complaint. I think its OK to be reminded that the context is mainly immutable when chaining on a stream. Method polymorphism to achieve default parameter values is a much worse nuisance, but not particularly hard to get used to when one decides to focus on the problem rather than the inevitable warts of a broadly useful programming language. Edit: Also a pretty weird complaint in a thread about a programming language where pretty much all the basic data structures are immutable. Maybe take it to the top and make the quip about worse than JavaScript with regards to Clojure?
- jakebasile 2y ago
  I won't tell you there aren't stumbling blocks and impedence mismatches but most of them are relatively minor syntactical things. The faux-AST in my head gets typed out in the wrong format and I have to backspace and correct it (think function declaration differences). The biggest workflow difference is undoubtedly the lack of a REPL in Go, but that is somewhat made up for by Go's lightning fast compilation and testing tooling (probably its second strongest attribute after the excellent standard library). After a day or two of writing in one or the other my neurons seem to get used to it only to cause the same problem in reverse when I switch back. Overall, it's not too bad and a case of just accepting the tools available for what they are. I don't try to force Go to be Clojure or Clojure to be Go.
- pjmlp 2y ago
  We get used to being yet another work related chore.
- harrison_clarke 2y ago
  i find i flip between different languages when i'm thinking about the problem in a different way an expressive language (clojure, python, C#, etc.) is good when you're iterating "what problem am i even trying to solve?" a less expressive language is typically better when you more or less know a high level solution to your business problem, and you're iterating on "how do i make the machine actually do it". like "how do i reduce my AWS bill" or "how do i render it in 16ms?" for something like gamedev, enough of the problem is in the second category that you might not even reach for the expressive language. (many do, though. with lua, or artisanal lisp dialects)
  - voidUpdate 2y ago
    If you're counting C# as an expressive language then a lot of gamedevs will reach for one, judging by the market share of unity, me included :P
- fire_lake 2y ago
  Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.
  - gpderetta 2y ago
    Lack of multiline lambdas is infuriating, but nested named functions partially make up for it.
- BaculumMeumEst 2y ago
  Writing Go is less fun but the language has far better tooling, dead simple deployment, lower memory usage, generally higher performance, and is easier to onboard new developers. Also I find it way easier to read old projects after time away. You can get incredible mileage out of Go using just the stdlib, built in tools, and the pure go port of SQLite. With Clojure it feels like I have to stitch a million random libraries together to get anywhere. Writing Clojure is delightful but the ecosystem and tooling pale in comparison, and at the end of the day I think that’s what matters. If Clojure had great built-in tooling, better error messages (and maybe some SBCL-esque type checking features), and if Datomic was open source and less rough around the edges, I think the language would have been far more successful.
- gpderetta 2y ago
  As a C++ programmer, I definitely like my languages with extra legs nailed on. But sometimes limitations can spur creativity.
- dgb23 2y ago
  Expressiveness has many dimensions. It depends on what you are trying to express in the first place. C++ or Rust are expressive in both directions, towards the metal and upwards in terms of abstractions. But those languages are not easy to reason about. They come with lots of stuff, hard to grok abstractions, ceremony and so on. Small languages like Scheme or Lua are expressive in that they don't force you to write a lot of stuff to get the job done. But those languages don't typically let you express what the computer should actually do at a lower level. C or Zigs let you do those things and are also relatively small languages. But their facilities for abstraction are limited and they force you to express more computational details. Go frees memory and schedules goroutines for you, but lets you express a lot more about how you lay out memory than other managed languages, so you can actually think in terms of bits and bytes. It has a great std lib so you can get stuff going quickly and reliably.
- Fire-Dragon-DoL 2y ago
  It's like looking at two very different people and realizing you are attracted by both: each one has their quirks and perks, so you like both. Might still end up marrying only one though!
dheera 2y ago
The "j" is always what put me off from learning Clojure. I've had too many bad experiences with JDKs and JVMs that I stay a thousand kilometers away from any thing that has "J" in it unless it's referring to JavaScript.
- rads 2y ago
  Check out Babashka. It's a single binary that runs Clojure without a JVM. It also starts up really fast and has a much lower base memory requirement: https://github.com/babashka/babashka https://github.com/babashka/babashka It's pretty easy to switch to writing JVM Clojure if you're familiar with Babashka. Most of the libraries written for Babashka are designed to work in either environment. That said, there are reasons you may want to use the Clojure on the JVM later on. It might be interesting to read the replies to another poster with similar concerns about the JVM: https://news.ycombinator.com/item?id=40445415 https://news.ycombinator.com/item?id=40445415
- KingMob 2y ago
  Interesting. Usually the reluctance comes from people confusing Java the language with JVM the platform.
- ertucetin 2y ago
  You can also try ClojureScript, which runs on JavaScript. If you're developing frontends.
- kaba0 2y ago
  Well, there aren’t too many more stable platforms out there, so your experience elsewhere couldn’t be all that cloudless either.
elwell 2y ago
> It went away for a while for reasons I'm unclear on. The creator, Anthony Grimes (https://github.com/Raynes https://github.com/Raynes), sadly passed away seven years ago: https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_open_source_contributor_anthony_grimes/ https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_ope...

nine_k 2y ago

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18). To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express. Maybe the key thing is to only write small things in less expressive languages, like shell scripts, or small C functions to help performance or FFI, or, well, tiny Go utilities.

ReleaseCandidat 2y ago
I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).
- nine_k 2y ago
  That's cool! How do you manage? E.g. the `if err != nil { return err; }` stuff?
  - ReleaseCandidat 2y ago
    Well, in the context of Lisp, `err != nil` is equivalent to Lisp's parens: if somebody complains about that, chances are their critique is superficial (and there are enough "real" problems when using Go, especially when using goroutines and channels). The amount of low abstraction Go code I write is compensated by the amount of "abstraction boilerplate" like implementing type classes by myself or letting the compiler derive, implementing newtypes, adding GADTs, adding Pattern Synonyms and Type Families to be able to comfortably use the GADTs without much boilerplate and so on. Rust adds for example the need for associated types and is generally more verbose than Haskell. I do not see a significant difference in the amount of boilerplate needed for catching exceptions, pattern matching or branching on the existence of an error value. Nobody can stop you from implementing `bind` in Go for your error (which I did in some places), but of course Rust "wins" with its `?`.
kubb 2y ago
Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning. There's a population of people that don't like this kind of abstraction, because to understand the code you first need to understand the problem, the data flow and how it's expressed. They prefer to look at the issue "bottom up" than "top down", and for them Go is perfect, because instead of reasoning about what the module does, how the data flows, what the algorithm does, they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable. There's no better or worse here, just two types of people. Some like to look at the whole bridge, some like to examine the individual nuts and bolts and joints.
- ReleaseCandidat 2y ago
  > There's no better or worse here, just two types of people. No, two types of solving a problem. I like writing both (Haskell and Go) - for _myself_ - but the tooling and standard library and ... of Go is orders of magnitudes better.
  - kubb 2y ago
    I would refrain from comparing Haskell - a research language intended for academia and created in universities, to Go - a pragmatic industry language intended for production and created in a megacorp. Why would Haskell's tooling be better? It's not reasonable to expect that.
    - ReleaseCandidat 2y ago
      I'm actually surprised Go's tooling as as good as it is _although_ it is made by Google. But to be fair, GoogleTest is OK too.
      - 2y ago
a_wild_dandan 2y ago
I must use PyTorch for ML, but badly wish I could use TypeScript instead. Its type system demolishes anything else I've used. Writing anything from SPI communications, to server logic, to rich GUIs is a breeze. Then I work in Python and have to fight `Any`s, ambiguous arguments, more verbose code, and bizarrely slow run times. It makes me sad.
- nine_k 2y ago
  While I agree with you, Python is getting better in this regard, as is mypy. Making historical interfaces well-typed is another kettle of fish. For instance, Python's range() is actually two overrides with incompatible signatures. I bet PyTorch has more of such examples.
  - pjmlp 2y ago
    If it only had a V8 class JIT in the package as well.
cess11 2y ago
Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions. To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm most fluent in too. Either that or the problem is trivial and likely to be in most common programming languages.
- nine_k 2y ago
  Java 7 is already pretty pleasant, and it has been improving ever since then. (Say what you want about Oracle Corporation, but as the wardens of Java they're doing a pretty good job.)
- fiddlerwoaroof 2y ago
  I’ve been writing a lot of Java 11 recently, and I find it to just be a very pleasant environment to work in: the IDEs still are best in class, afaict; the newer APIs avoid a lot of the boilerplate I used to have to write out and there are generally mature libraries to interact with just about any system you might need. Where Clojure really shines is that it’s a really well thought-out layer that can leverage this ecosystem and adds its own well-designed tools on top for my preferred more-interactive development style.
- ErikCorry 2y ago
  These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane. If you are making JavaScript look good you are failing as a language.
  - cess11 2y ago
    Typically I can use a forEach in such cases, and when I can't it's probably an incrementer and the IDE just switches out my int as an automatic solution to its complaint. I think its OK to be reminded that the context is mainly immutable when chaining on a stream. Method polymorphism to achieve default parameter values is a much worse nuisance, but not particularly hard to get used to when one decides to focus on the problem rather than the inevitable warts of a broadly useful programming language. Edit: Also a pretty weird complaint in a thread about a programming language where pretty much all the basic data structures are immutable. Maybe take it to the top and make the quip about worse than JavaScript with regards to Clojure?
jakebasile 2y ago
I won't tell you there aren't stumbling blocks and impedence mismatches but most of them are relatively minor syntactical things. The faux-AST in my head gets typed out in the wrong format and I have to backspace and correct it (think function declaration differences). The biggest workflow difference is undoubtedly the lack of a REPL in Go, but that is somewhat made up for by Go's lightning fast compilation and testing tooling (probably its second strongest attribute after the excellent standard library). After a day or two of writing in one or the other my neurons seem to get used to it only to cause the same problem in reverse when I switch back. Overall, it's not too bad and a case of just accepting the tools available for what they are. I don't try to force Go to be Clojure or Clojure to be Go.
pjmlp 2y ago
We get used to being yet another work related chore.
harrison_clarke 2y ago
i find i flip between different languages when i'm thinking about the problem in a different way an expressive language (clojure, python, C#, etc.) is good when you're iterating "what problem am i even trying to solve?" a less expressive language is typically better when you more or less know a high level solution to your business problem, and you're iterating on "how do i make the machine actually do it". like "how do i reduce my AWS bill" or "how do i render it in 16ms?" for something like gamedev, enough of the problem is in the second category that you might not even reach for the expressive language. (many do, though. with lua, or artisanal lisp dialects)
- voidUpdate 2y ago
  If you're counting C# as an expressive language then a lot of gamedevs will reach for one, judging by the market share of unity, me included :P
fire_lake 2y ago
Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.
- gpderetta 2y ago
  Lack of multiline lambdas is infuriating, but nested named functions partially make up for it.
BaculumMeumEst 2y ago
Writing Go is less fun but the language has far better tooling, dead simple deployment, lower memory usage, generally higher performance, and is easier to onboard new developers. Also I find it way easier to read old projects after time away. You can get incredible mileage out of Go using just the stdlib, built in tools, and the pure go port of SQLite. With Clojure it feels like I have to stitch a million random libraries together to get anywhere. Writing Clojure is delightful but the ecosystem and tooling pale in comparison, and at the end of the day I think that’s what matters. If Clojure had great built-in tooling, better error messages (and maybe some SBCL-esque type checking features), and if Datomic was open source and less rough around the edges, I think the language would have been far more successful.
gpderetta 2y ago
As a C++ programmer, I definitely like my languages with extra legs nailed on. But sometimes limitations can spur creativity.
dgb23 2y ago
Expressiveness has many dimensions. It depends on what you are trying to express in the first place. C++ or Rust are expressive in both directions, towards the metal and upwards in terms of abstractions. But those languages are not easy to reason about. They come with lots of stuff, hard to grok abstractions, ceremony and so on. Small languages like Scheme or Lua are expressive in that they don't force you to write a lot of stuff to get the job done. But those languages don't typically let you express what the computer should actually do at a lower level. C or Zigs let you do those things and are also relatively small languages. But their facilities for abstraction are limited and they force you to express more computational details. Go frees memory and schedules goroutines for you, but lets you express a lot more about how you lay out memory than other managed languages, so you can actually think in terms of bits and bytes. It has a great std lib so you can get stuff going quickly and reliably.
Fire-Dragon-DoL 2y ago
It's like looking at two very different people and realizing you are attracted by both: each one has their quirks and perks, so you like both. Might still end up marrying only one though!

dheera 2y ago

The "j" is always what put me off from learning Clojure. I've had too many bad experiences with JDKs and JVMs that I stay a thousand kilometers away from any thing that has "J" in it unless it's referring to JavaScript.

rads 2y ago
Check out Babashka. It's a single binary that runs Clojure without a JVM. It also starts up really fast and has a much lower base memory requirement: https://github.com/babashka/babashka https://github.com/babashka/babashka It's pretty easy to switch to writing JVM Clojure if you're familiar with Babashka. Most of the libraries written for Babashka are designed to work in either environment. That said, there are reasons you may want to use the Clojure on the JVM later on. It might be interesting to read the replies to another poster with similar concerns about the JVM: https://news.ycombinator.com/item?id=40445415 https://news.ycombinator.com/item?id=40445415
KingMob 2y ago
Interesting. Usually the reluctance comes from people confusing Java the language with JVM the platform.
ertucetin 2y ago
You can also try ClojureScript, which runs on JavaScript. If you're developing frontends.
kaba0 2y ago
Well, there aren’t too many more stable platforms out there, so your experience elsewhere couldn’t be all that cloudless either.

elwell 2y ago

> It went away for a while for reasons I'm unclear on. The creator, Anthony Grimes (https://github.com/Raynes https://github.com/Raynes), sadly passed away seven years ago: https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_open_source_contributor_anthony_grimes/ https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_ope...