Live data from Hacker News

Clojure is cool

ahungry.com

71–80 of 133 posts

Re: Clojure is cool

#71

Earlier quoted context omitted.

Code-sharing between ClojureScript and Clojure is a killer app

Not really. Although Clojure and Clojurescript are both dynamically typed, Clojure is strongly typed while Clojurescript is weakly typed. Clojure: (+ "1" 1) ClassCastException java.lang.String cannot be cast to java.lang.Number clojure.lang.Numbers.add (Numbers.java:128) Clojurescript: (+ "1" 1) "11" They may be close, but that is all the reason for concern. There are a million ways that small semantic differences li…

You raise a good point. Is there a linter available that would flag such non-portable code?

Re: Clojure is cool

#72
post #58
post #33

Earlier quoted context omitted.

The claims regarding JVM bloat are largely exaggerated, especially now that the JVM introduced modules. However, if it's not your thing it's worth noting that ClojureScript happily runs on Node. Here's an example of how easy it is to get up and running with https://github.com/yogthos/mastodon-bot

I'm working on my first Clojure project and find JVM to be painful (it starts very slowly and eats lots of RAM). I'd appreciate any tips on making JVM non-bloated.

If start time and memory usage is important to you, go with ClojureScript on Node instead.

If you do stick with the JVM, it tends to trade memory for speed, unless you tune it otherwise. For startup speed, start it once, connect a REPL, and keep it running. A started REPL on a JVM instance can be flushed very quickly when you need a blank slate.

Re: Clojure is cool

#73
post #36
post #30

Earlier quoted context omitted.

Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.

I've implemented the Map interface maybe a half a dozen times in my career in Java and many more in Clojure (using reify and friends). It's often very convient to offer a map interface to some remote service or data store as well as situations where I needed very custom caching or a specialized algorithm. The harder the thing I'm working on, the more motivated I am to present its API as something standardized if poss…

Generally at least in Java or similar languages it's better to compose rather than implement or extend, i.e. HashMap works fine for most cases, and you may not really need to implement java.util.Map if you're building something "special" anyway. For frameworks and library authors, I can see more of an argument for it, I just generally have never subclassed collections except in certain cases such as building an LRU map which Java doesn't have.

Re: Clojure is cool

#74

Earlier quoted context omitted.

Not really. Although Clojure and Clojurescript are both dynamically typed, Clojure is strongly typed while Clojurescript is weakly typed. Clojure: (+ "1" 1) ClassCastException java.lang.String cannot be cast to java.lang.Number clojure.lang.Numbers.add (Numbers.java:128) Clojurescript: (+ "1" 1) "11" They may be close, but that is all the reason for concern. There are a million ways that small semantic differences li…

You raise a good point. Is there a linter available that would flag such non-portable code?

you get a warning from the compiler in ClojureScript when type coercion happens:

    cljs.user=> (+ "1" 1)
            ⬆
    WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead. at line 1
    "11"
You can also use Spec and Schema to validate data at the edges, so that you don't end up with unexpected inputs. I highly recommend doing that for any non-trivial projects.

Re: Clojure is cool

#76
post #31

I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages. If you are not working for a startup, majority of the time, you will be maintaining legacy code or bug fixing. I would take easily understandable verbose code over "clever" concise code every time.

I've worked with Java for over a decade professionally. Most of the verbosity in it is just noise, and does not provide any meaningful information. Clojure code is far easier to maintain for a number of reasons. The code is declarative, so it separates what's being done from the implementation details. The first step of code maintenance is to understand the intent, and it's much easier to do that with declarative cod…

> My team moved from Java to Clojure about 8 years ago, and we find that it's much easier to maintain Clojure projects than it was for similar scope Java projects

Could it just be that you are all better developers than you were 8 years ago, and the language doesn't really make a difference?

Re: Clojure is cool

#77
post #20

Earlier quoted context omitted.

Your experience appears to be an outlier. Lots of companies are using Clojure for large scale projects, and my own team has been happily using it for nearly a decade now. The fact that your team struggled to get anything done probably says more about your team than Clojure to be honest. https://clojure.org/community/success_stories

Thanks to the rise of SOA, basically any language no matter how obscure can claim multiple corporate users for for what are ultimately inconsequential projects. But as long as we're using personal anecdotes, I saw several teams using clojure at Amazon when it was more popular. Less than two years later, all of them that I knew of (I was a clojure user too, interested in its use in the company, so I was keeping track)…

Have you run into Nubank? They have around 4 million customers and the company is valued at a billion plus dollars. [1,2]

Apple is hiring Clojure people to work on their ML infrastructure. [3]

What's your definition of an inconsequential project?

1: https://www.reuters.com/article/nubank-creditcards/brazilian...

2: https://en.wikipedia.org/wiki/Nubank

3: https://jobs.apple.com/nz/search?job=114084463&openJobId=114...

Re: Clojure is cool

#78

Earlier quoted context omitted.

Not really. Although Clojure and Clojurescript are both dynamically typed, Clojure is strongly typed while Clojurescript is weakly typed. Clojure: (+ "1" 1) ClassCastException java.lang.String cannot be cast to java.lang.Number clojure.lang.Numbers.add (Numbers.java:128) Clojurescript: (+ "1" 1) "11" They may be close, but that is all the reason for concern. There are a million ways that small semantic differences li…

You raise a good point. Is there a linter available that would flag such non-portable code?

There probably is, but I haven't used clojure for at least 4 years so I'm not the person to ask. Regardless, a linter might flag things like that, but in my experience the most pernicious ways that it hurts wouldn't be found because they exist outside the application due to IO boundaries. Things like API or database calls, etc.

Re: Clojure is cool

#79
post #54

Earlier quoted context omitted.

Are you using core.spec in your codebase? Did that help at all?

No, core.spec does not address the main issues with dynamic typing. It offers some neat stuff, but it is not a replacement for static typing.

Dude, Clojure is a dynamically typed language and always will be. If you don't like it use something else.

Re: Clojure is cool

#80

I really like and use Clojure professionally, but I have become wary of the extraordinary time I spend dealing with runtime issues because of the dynamic typing. I hope the future of core.typed is bright. I know it is being very seriously worked on. It can't come soon enough for me. Nowadays, I prefer to write in any statically typed language even if it is more line counts, just for my own sanity.

If you also add the line count for the additional tests needed to check the behavior of passing not what you expected, then I'm not sure it will be more.
Post reply on HN