Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

Post reply on HN
Print view View original

61–70 of 209 posts

Re: Six years of professional Clojure development

#61

Post by fnord123 »

joelbluminator wrote: post #11
lukashrb wrote: post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

You're both wrong. If it was dynamicism then why are JS, Python, and Ruby so popular? If it's about being functional then why has Scala got more users?

Languages are driven by the platform. There is no Clojure platform that people want to use, so no one uses Clojure.

If a language isn't bound to it's own platform, it can share a platform and displace other tools like python, go, and rust do with C and C++ (docker is go; docker-compose, dnf is python; etc).

Scala has carved out pat of the jvm platform (spark, kafka). Clojure has not.

A common onramp is command line tools, but Hello world in Clojure takes 670ms to run. This is a total non-starter.

    time clj -M hello.clj
    Hello world
    clj -M hello.clj  1.05s user 0.12s system 175% cpu 0.672 total
Without an on-ramp to take over a platform, Clojure will not gain traction. Language quality is not a significant driver in adoption ; that's why shonky R has so many users. They will suffer a great deal to use dataframes and ggplot2.

If Clojure is so great, where are these cathedrals that people have made that should make it a no brainer to pick up Clojure? Around what are we circling the wagons?

Re: Six years of professional Clojure development

#62

Post by comma_at »

cies wrote: post #33
jeofken wrote: post #22

I loved clojure until working with it for a few years, with some of the famous best teams in Europe and America, including Cognitect people, who ill leave unnamed here. I fell out of love when I realised what the language is - a mutable, imperative, blocking IO by default language with lambdas and zero guarantees at compile time. Effects happen at any time, as it is an imperative language. Just like JS with a better…

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).

Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kernel is a prime example how far can you get if you don't break your users.

Re: Six years of professional Clojure development

#63

Post by dmos62 »

YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

What helps me with this inherent uncertainty is writing in a functional style (simple inputs and outputs, minimal functions) and using runtime tests to check for correctness. The key is to have the tests as far down the abstraction tree as possible. There's a performance hit, but you can use macros to keep it out of production.

Re: Six years of professional Clojure development

#64

Post by comma_at »

fnord123 wrote: post #61
joelbluminator wrote: post #11

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

You're both wrong. If it was dynamicism then why are JS, Python, and Ruby so popular? If it's about being functional then why has Scala got more users? Languages are driven by the platform. There is no Clojure platform that people want to use, so no one uses Clojure. If a language isn't bound to it's own platform, it can share a platform and displace other tools like python, go, and rust do with C and C++ (docker is…

Clojure has reached sustainable traction. There are large companies using it. There are shops that work with it exclusively. There's no need to conquer the world ;) If some users are evangelizing too loudly, well, it happens everywhere. You can choose to ignore it. And if you are curious why you can check it out and decide for yourself. No random person on HN can convince you.

Re: Six years of professional Clojure development

#65

Post by synthc »

jeofken wrote: post #54
Kototama wrote: post #35

Earlier quoted context omitted.

What is mutable by default in Clojure? Nothing. You need to explicitly declare mutable variables with a special notation. Are you talking about the underlying VM? Yes, the Java API are mutable, not surprise here, it's not Haskell. Imperative? What is imperative by default in Clojure? Nothing. It's one of the least imperative Lisp, favoring functional constructs all over the place unlike Common Lisp or even Scheme. Bl…

> What is mutable by default in Clojure? Nothing. All data in Clojure inherits from java.lang.Object. I get what you’re saying, but in real life commercial projects, especially when you use libraries and Java classes, the code ends up with a lot of mutable things. You can never know if any function you call does mutate something without keeping all definitions in your head, and with 20+ people on the project, this is…

Inheritance from java.lang.Object does not make Clojure data mutable. Blocking for IO does not make Clojure imperative, it not a purely functional language, but its still a functional, not imperative, language.

It's possible to build a service in a purely functional language using non blocking IO that also takes minutes to render. No language will save you from a bad design.

I do agree that Clojure is not the most suitable language for large projects with lots of contributers because of it's dynamic nature.

Re: Six years of professional Clojure development

#66

Post by [deleted] »

cies wrote: post #33
jeofken wrote: post #22

I loved clojure until working with it for a few years, with some of the famous best teams in Europe and America, including Cognitect people, who ill leave unnamed here. I fell out of love when I realised what the language is - a mutable, imperative, blocking IO by default language with lambdas and zero guarantees at compile time. Effects happen at any time, as it is an imperative language. Just like JS with a better…

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

[deleted]

Re: Six years of professional Clojure development

#67

Post by cutler »

jeofken wrote: post #22

I loved clojure until working with it for a few years, with some of the famous best teams in Europe and America, including Cognitect people, who ill leave unnamed here. I fell out of love when I realised what the language is - a mutable, imperative, blocking IO by default language with lambdas and zero guarantees at compile time. Effects happen at any time, as it is an imperative language. Just like JS with a better…

So what is your preferred alternative/language/framework?

Re: Six years of professional Clojure development

#68

Post by truth_seeker »

Why is everyone making a big deal out of dynamic nature of Clojure as the main factor to not consider it in enterprise project ?

As if no dynamic language has ever succeeded in creating enterprise application which runs 24X7 !!!

If you don't like maps use clojure records

If you don't want free floating initiation or ambiguous variables and arguments to function in code, use type hints. Type hints may not be exact alternative but are good enough help in reading the code and especially compiling the code to native graal image or just providing enough information to JIT for optimization.

Use spec for generative testing and more detailed documentation. Irrespective of the language you use, tests are much important than types. Types help but they are not commandments.

Multithreading capabilities in clojure through standard library primitives exposed to achieve it are much better and safer than java.

For most of us, cost of immutable data structure is pretty reasonable. But if you think it's not the case, clojure provides mutable alternatives.

Use components like library to large code in depedancy inversion oriented style, if thats what you like. Personally I prefered dynamic dispatch through multimethods when I used to work in clojure 4 years back.

You can always get the library to do your job in the clojure ecosystem. If you don't find it, clojure provides easy integration with java libraries and you might be able to build a wrapper around it in couple of days if it is complex, in minutes otherwise.

To compare Clojure with languages like Haskell and its features, Rust and its features is utterly naive. Instead development team must strive for what actually is needed for job. Flexibility and discipline provided by language compiler and library eco system will always strike some kind of trade-off. Clojure is good trade-off for most applications including mission critical soft realtime application category.

Re: Six years of professional Clojure development

#69

Post by galangalalgol »

truth_seeker wrote: post #68

Why is everyone making a big deal out of dynamic nature of Clojure as the main factor to not consider it in enterprise project ? As if no dynamic language has ever succeeded in creating enterprise application which runs 24X7 !!! If you don't like maps use clojure records If you don't want free floating initiation or ambiguous variables and arguments to function in code, use type hints. Type hints may not be exact alt…

The soft real-time interests me. Are there ways to avoid garbage as with java to minimize GC driven latency.

Re: Six years of professional Clojure development

#70

Post by yogthos »

draklor40 wrote: post #39
YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

My team structures projects by breaking things up into small isolated components that can be reasoned about independently.

We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes.

We'll also often pull out code into libraries when we notice it being generally useful outside the original use case.

I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.

Post reply on HN