Ask HN: What cool development languages/tools changed your career?

> impossible to debug efficiently without a) understanding everything around it and b) printing everything. Debug statements seem to "ruin the cleanliness" (as well as genuinely ruining threading macro flows.

I've never once had to add a debug statement to my Clojure code, not sure what you are doing honestly. You can easily debug with Emacs + Cider which allows setting breakpoints, inspecting, and evaluating forms while debugging. This is much more than debuggers in many languages. Further, you can also use Cursive + IntelliJ which gives you pretty much the same thing, only more like most people who have done Java, C++, or C# are used to in the various associated IDEs such as IntelliJ, Eclipse, Visual Studio, (or Emacs/Vim for that matter) etc. Given the data you are dealing with most of the time is immutable, things couldn't be clear IMO.

The only time I find myself printing things is in the REPL. A few years ago I did this more often in Chrome in ClojureScript, which mostly goes away now with one or more of nREPL, Nightlight, Figwheel (or the many similar libraries). In fact I'd say the debugging situation here is better than most languages because you can instant eval things as well as live code, and see those changes immediately in the browser.

Regarding threading macros, I assume you're talking about (->, ->>, ->as, and so on). Again, you can just eval these partially in the debugger, and worst case, bind something to a value you set in the debug session as you would in a plain REPL session. I would agree these are harder to step through. If for some reason you meant macros in general, I'll repeat what I always say to new Clojure and Lisp users in general - do not write macros at the start, and when you do, question the reasons why you are doing so. Macros are insanely useful and powerful when you need them, but most of the time you do not for the average app (obviously many exceptions). Worst case, you can macro expand, paste that, and debug or debug the macro expand in an debug eval.

Overall, I've found debugging to be substantially less pleasant in most languages that are popular such as Python and Ruby vs. Clojure but less pleasant than say Smalltalk or a Lisp machine. Like many languages, the situation with Clojure improves over time. People complain about the stack traces but most of the time they don't bother me and each version has improved on that. I came from the assembler, C, Fortran, Lisp world, so in some ways that has made me more keen how to write code that is easy to debug and to not fear debugging.

> Do other companies use Clojure for non trivial web applications? Have these Clojurians ever worked on a properly complex system? A lot seem to do just data analysis with Clojure. More importantly, have they ever worked on a properly complex system that they haven't been involved with from the start where debugging comes back to 'intuition' and 'whack a mole' type debugging?

Yes, there are various lists out there if you Google some. A brief list: Amazon, Netflix, Pivotal, Walmart, Heroku, Factual, Capital One, Roomkey, Spotify, Soundcloud, the list goes on. I think it's fair to say at least one has a complex app and at least one is a not for data analysis. Clojure is quite often used at very large companies that are almost surely building systems more complex than yours (no offense, just basic probability). Saying Clojure seems to be used mostly for data analysis and therefore implying it might not be good for web apps is like saying that about Python, which in fact is used more than Clojure for data analysis.

Regarding, web applications, by nature they are trivial compared to many domains. Of course you can make things complicated by adding a lot of moving parts, but these things are usually complimentary to a web app (ex: stream processors like Spark, Storm, Google Dataflow). You can also make things more complex than they need to be by bolting on frameworks and trying to shoehorn your business and code concerns into it. This is one reason some people like lighter frameworks for some purposes and heavier for others (see Django vs. Flask for instance). Clojure generally spurns heavy frameworks for web stuff because functional programming tends to encourage or even require composition. As such, things already fit together and simply picking well-tested libraries to form your "stack" tends to let you use the right tool for the job more readily. Obviously this is somewhat subjective, but I think other people who insist on heavy frameworks have something to learn here. If their framework was so awesome, we would not need 10 more next week, and yet that is what happens.

Regarding "intuition" and "whack-a-mole" debugging, I would agree that the former is important, while the latter is a sign you've done something terribly wrong. Clojure like many functional or data-first languages tends to push you towards certain tracks that should really not lead you to whack-a-mole debugging. The idea of immutability by default and functional composition in part is that it is harder to screw up your state. This should make debugging very clear at runtime since you can quite often literally dump your entire state and have quite high visibility into what is happening in your application. A good example of this WRT web dev as you mention is ClojureScript (yes, not Clojure but same principle applies) and ReFrame or Om-Next. You have a single representation of your state as an immutable database that you update instead of things scattered about, meaning you can inspect it, query it, access it across threads (if it was on the server), etc. In Clojure and many languages, you need to think in terms of operating on data structures not classes, objects, or potential language construct distractions. This again drives away distractions while debugging that leads to shots in the dark. This of course should feed your intuition too in that if you see something with a weird state, you did something wrong like reset! instead of swap! or used mutability or you're just understanding your own code wrong.

It's not really fair to compare, but like I said, I find the debugging situation to be excellent. The fact that you can also live code with the browser, work directly in a REPL session (I open them for days), and so on means you can potentially write and test your code easily at the same time. This is somewhat like TDD, but instead of just writing a unit test, you actually run the code and get more immediate iteration and feedback. Of course you can still do test-first TDD too and eval those and even run the tests in the REPL. There are some traps here like stupid things you can do in the REPL, but there are many libraries to help you solve this that promote practices that are good regardless of the REPL (ex: Component, Mount).

I'm already writing too much, so I'll say with regard to what Rich says, just read Clojure news groups and JIRA and such. He has said many times Clojure is essentially a pragmatic balance of some of the super powers of Lisp with the practicality but limitations of the JVM. Do you want a perfect language or one that helps you get work done today but maybe better than a lot of what is out there? Moreover, do you want a language you can use in reality or just academia? Clojure solves that via the JVM and a huge existing ecosystem.

Anyway, feel free to ask more and good luck. I am sorry if I sound harsh, but I am trying to give you real answers rather than fluff.

* It's on the JVM (good and bad). JVM is boring, JVM loves crazy config and Java libraries. JVM has legacy baggage. JVM has garbage collection which precludes Clojure from some problem domains or otherwise handicaps it (game dev, real-time) somewhat. The list goes on.

* Core.Async is great, but parts of it can't really be optimized because of the JVM, once again. Go does a better job supporting some of the same constructs at a lower level. Counter-point: I am light years more productive in Clojure than Go because of functional programming, immutability by default, and better/more libraries for my purposes given the entire JVM ecosystem.

* Macro Debugging. Yeah, there's not much getting around this, but I mentioned some tips in my other post.

* AOT. It's there if you need it but it's less than thrilling to work with.

* Multiple versions of Clojure in the same JVM. People are working on it, but it's an issue caused by the JVM once again. Anyone who has used Storm has probably hit this at least once.

* Editors. There's Emacs and IntelliJ/Cursive, but the rest of the pack of popular editors have questionable or more limited support. Fireplace + Vim is decent too. A good example I saw recently was someone was lacking good, bug-free Clojure support thus far in VSCode. This is mostly due to community size.

* Community size. It causes a lot of things. On the plus, the community is more friendly, open, and accessible at all levels. There's no layers between people very much or hierarchy. On the negative side, there is less output because of it, though I feel sometimes this helps with quality control. Ability to use Java libs helps here.

* Null/Nil/Exceptions. I agree with how Rich gave treatment to nil, but I mention it because a lot of people hate it, especially with some ops that return nil. If you are a monad person, this will start to get to you. Exceptions also bubble up sometimes and mess with your beautiful functional compositions because of Java underpinnings.

* Functional purity. I worked in various Lisps, Haskell, and others. I don't buy this argument, but some people would rather burn themselves alive than use an impure pestilence like Clojure.

* Graphics Programming. I mean you have Java and some Clojure GPU libraries, but it's kind of weak. This applies to most languages that aren't C or C++ though.

* Certain domains. I mentioned graphics, I'll also again mention real-time and games. I don't think you should be writing the next Mars Lander in Clojure.

* Garbage. Again, JVM, but it's worth stressing that Clojure generates even more garbage than normal in some cases. You can avoid this if you really care and can shortcut some things by making use of transients.

* Performance. Transients also will help here. Clojure performance is pretty good, but it's not Rust or C good. Like any language, you need to understand where the costs accrue with productivity.

* Legacy core or widely-used libraries. Some of these suck or have some design issues. I personally don't like zipper for example and use 3rd party stuff if I want the same thing. Core.typed for awhile was bothering me too.

* Startup time. It sucks. It's getting better, but it is a hard thing to make progress on. Pixie is one alternative if you want something similar in another language, though I'd personally either stick with Clojure or pick a different language if that was important to my app. Example: not the best thing in the world for shell scripting.

* Pre-existing knowledge. It's not a requirement, but it certainly helps to have other languages under your belt first. Knowing Java and the JVM really helps, especially with debugging if you are that lost.

* Lein/Maven. It's getting better, there are alternatives (boot), and these tools are pretty awesome compared to most (looking at you Go and also Nodejs). Still, there's some rough parts here carried over from maven. For instance, "lein clean" is a thing.

* Size. Heaven help you if you want tiny output of a binary/package (ex: JAR). But then again, you're using the JVM so I assume you didn't believe in such things.

* Lack of tail optimizations. JVM issue again. Clojure works around it, but it would be nice to have had at the start. This angers Lisp purists.

* Namespace issues. Mostly just about blowing up REPL state. Namespacing is actually pretty good, it just has some limitations in the Lisp sense.

* What is broken by design to some degree will be at best patched, not fixed. Rich has stated numerous times he doesn't want to entirely break peoples code, but he will try to patch things. A good example is transducers were an improvement, patch, and built in a way that didn't break existing stuff. This means though some of the rough parts are here to stay.

There's many more, but that's my honest perspective for you. I would never pick 1 language for all projects or even most of my projects. Use the best tool for the job. Clojure sometimes is it for me, hopefully for you too. Good luck.

People really should not discount the importance of having a big ecosystem, at least transitively in some way (ex: Clojure -> Java/Scala/Groovy). Once upon a time I took a break from C and C++ dev to do Smalltalk. It was glorious and productive, but at the same time I had to literally write everything myself. The community, even at the height was relatively small vs. some languages today. The worst was writing low-level stuff that while I could do, gave me the voice inside my saying, "WTF why am I wasting time on this." No one should ever do that if they can help it; it just eats your time.

The only real situation that comes to mind where I personally felt justified reinventing the wheel entirely was game development (ex: custom allocators, custom pipelining, entity systems). That still was time lost I could have been using to make a game and get other things done, but there were very good reasons like performance. Console development in particular was exactly this - it's not like I could go out and ask someone for their NES libraries or even in later years, PS3. Games don't generally reuse much code and certainly not when a generation of consoles is brand new with a new architecture. I could have written code like an idiot, but I chose instead to write stuff against the platform. We did well because of it vs. competitors. You can say Engines handle some of that for my specific cases, but that's discounting that huge chunks of a game are not in fact the engine or that some games preclude the use of an engine for various reasons or engines sometimes end up having the opposite effect (ex: Star Citizen).