[mistersys]

Sure, but having used static vs. dynamic languages extensively on gnarly problems, it’s pretty clear what they’re saying. There comes a point where dynamic languages can be quite hard to debug compared to language with well deigned types, especially when working on tricky problems with many constructs and elements. Less rules does not equal greater productivity.

[burnthrow]

No it's not clear, this is another rehash of the static vs. dynamic debate, and you're welcome to your side. It's ludicrous to claim that highly complex systems cannot be written in a maintainable fashion with a dynamically-typed programming language. Anyway this gets to what bugged me about the post, the author is plainly not comfortable with Clojure and wants it to be Haskell-y. So of course they're going to be happy in a language like Rust.

[tracker1]

I think it comes down to the specific codebase for the Clojure version vs. the Rust version. In this case, after rewriting the code into Rust it was easier for the author to understand and reason with.

Not that you can't do it in Clojure or any given language.

In the end, they're happy with Rust. I really like what little Rust I've done. I still reach for JS/Node first only because I can get something working faster often because of what's in the box and in npm. It's far from the most performant, but often fast enough. C# tends to be my second level, though as I become more familiar with Rust, it may displace this.

You can't be an expert in everything and sometimes a given language will lend itself to the way you think in idiomatic terms.

The article is an anecdote on a personal experience, not an assault on Clojure or the ecosystem. Even if it is critical at a couple points.

[fulafel]

This is prone to the usual bias that rewriting the code generally makes it easier for the author to understand and reason with :)

[mistersys]

Okay, why is there this attitude about dynamic typing vs. static typing that we can't have debates about it? As if it's an inherently subjective debate, not worth discussing? How is it ludicrous to say that for big programs, rules that allow the computer to automatically verify things for you can never be proven useful?

Modern statically typed languages are not the abtrusive, verbose dinosaurs of yesteryear. They can be used without type annotations quite often, and have almost no expressiveness limitations compared to dynamic languages.

I love clojure. It's almost my favorite language, the syntax is amazing and the experience of using paredit and the many bespoke control flow structures that make your problems easy to model make it feel like God's language. But yeah, debugging is massively painful. Stack traces are useless, and the lack of types makes errors pop-up in places you wouldn't expect.

That's not a subjective thing. It's a weakness of the language. There's no drawback to having optional static guarantees. Can we stop pretending this debate is not worth having?

[harperlee]

I love clojure and I wholeheartedly agree with what you say, if that serves anything.

I don't understand, for example, why stacktraces do not fold by default everything from clojure.core. Can't we assume that the language implementation is right for 99.999% of the world's stacktraces, and only show functions in other namespaces? In case some day someone finally triggers an error in clojure, you toggle a parameter and get the full stack.

[fulafel]

The tooling does support customizable stack trace filtering pretty well I think (at least in Calva and CIDER, probably Cursive too?).

I wouldn't want to filter out clojure.core frames because you can click on those and see the line of code in the stdlib that is calling back into your code when you use higher order functions, it's useful.

[harperlee]

This should be a default at the language level, not require tooling to filter out verbose noise.

Apart from the principle of the language being not dependent on external tools, on practical terms: if you get a stacktrace in a production log, or on a terminal, you don't have that tooling available, for example.

This is precisely what mistersys was denouncing. This is an objective issue, that pushes newbies away, that consistently gets discussed in the annual survey, in HN, and in basically every conversation about clojure. Spec has improved somewhat the error messages, but still core functions are not specced officially, and still the error messages are hugely verbose and expose implementation details that should not be visible. We should at least acknowledge it instead of pretending it's solved, or not an issue due to tooling workarounds.

On your point about seeing the clojure.core stacktrace: the implementation of a core function shouldn't be something that you need to inspect to know how it's working, that should be clear from the public interface. That's part of the clojure philosophy, have small functions that are obvious and compose easily in your head, so you understand every piece easily. In any case, I've been using clojure on all my side project for about 8 years now and I've never had to do what you discuss, could you give an example of when would you need this?

[fulafel]

I agree the default filtering should be better, but disagree strongly about showing what the standard library is doing in debugging contexts.