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

A Clojure learning journey

stuttaford.me

Post reply on HN
Print view View original

61–70 of 72 posts

Re: A Clojure learning journey

#61

Post by fro0116 »

james-mcelwain wrote: post #42
Scarbutt wrote: post #30

Earlier quoted context omitted.

But does Clojure/C really makes you more productive than Python/Javascript/C? which I guess is the point the GP was referring to, although, you mentioned it makes you happy (which is a good of enough reason as any). Don't get me wrong, I think learning Clojure is helpful for lots of developers, even if they won't use it for work/side projects, and I think that's exactly what happens in the Clojure ecosystem and the r…

It sounds like you're suggesting that Python/Node have better libraries, which couldn't be further from the truth. Most "abandoned" Clojure libraries either (a). aren't abandoned and "just work" due to their limited scope or (b). are wrappers to Java libraries that are trivial or unnecessary. Most people would rather to interop directly.

To offer one small piece of anecdote to the contrary: We use Clojure for most of our server-side code and picked Lacinia from Walmart Labs [0] to implement our new GraphQL API. It does most of the basics just fine, but its pace of development lags extremely, painfully far behind GraphQL server implementations in more popular languages such as the ones in Node and Python. To this day it still doesn't have support for custom directives [1], not to mention any of the other more bleeding edge developments in the GraphQL community such as schema stitching and live queries, all of which we would really have liked to experiment with along with the rest of the GraphQL community. We ran into similar issues initially when trying to use gRPC with Clojure.

We love writing Clojure and still use it everywhere where appropriate, but the size of its community and ecosystem is definitely holding back its ability to compete for adoption with other languages on the bleeding edge of new technological trends.

[0] http://lacinia.readthedocs.io/en/latest/

[1] http://lacinia.readthedocs.io/en/latest/directives.html

Re: A Clojure learning journey

#62

Post by jtmarmon »

scardine wrote: post #12

I just got rejected in a hiring process at Nubank (a sexy fintec from Brazil that uses clojure a lot) because I used a database for the take-home code challenge they sent me (writing a REST API). Since I'm a Python developer who knows little about concurrency in clojure and I would not like to use locks, I thought it would be better to delegate these things to the database. Apparently I was supposed to use a global s…

That’s pretty funny. Did they really not mention anything about using an atom when they sent you the assignment?

Maybe if you had used datomic as your database it would’ve been fine (/s)

Re: A Clojure learning journey

#63

Post by metaobject »

james-mcelwain wrote: post #42
Scarbutt wrote: post #30

Earlier quoted context omitted.

But does Clojure/C really makes you more productive than Python/Javascript/C? which I guess is the point the GP was referring to, although, you mentioned it makes you happy (which is a good of enough reason as any). Don't get me wrong, I think learning Clojure is helpful for lots of developers, even if they won't use it for work/side projects, and I think that's exactly what happens in the Clojure ecosystem and the r…

It sounds like you're suggesting that Python/Node have better libraries, which couldn't be further from the truth. Most "abandoned" Clojure libraries either (a). aren't abandoned and "just work" due to their limited scope or (b). are wrappers to Java libraries that are trivial or unnecessary. Most people would rather to interop directly.

To what extent does the Python GIL hold it back from performing multithreaded tasks as compared to Clojure? I'm mostly a Python programmer but I've experimented with Clojure a few times for some small projects, and I've noticed the multithreading options with Clojure to be more plentiful and capable.

Re: A Clojure learning journey

#64

Post by ajmurmann »

platz wrote: post #55
whalesalad wrote: post #4

Not sure why the excitement around ditching Lein when it looks like there is little or nothing to be gained at this time? The author describes a handful of other tools that are necessary to do things Lein does out of the box (uberjar) The Clojure ecosystem (specifically through the lens of this post) reminds me of the Linux desktop ecosystem. Lots and lots of tweaks and knobs and dials for the sake of having tweaks a…

> Lots and lots of tweaks and knobs and dials This is the case with all big-tent, "community-driven" PLs that have a high expressiveness, and attract contributors that have a multitude of preferences: Ruby, Javascript, Scala, Clojure, Haskell, Racket Alternatively, are the 'prescriptive' cultures, that tend to select for predictability and high cohesion: C#, Elm, Go, Python (circa-2007).

It's interesting to see Ruby in there. The language definitely tries to cater to everyone's taste and offers a ton of ways to do the same thing. The community though seems a little more opinionated though. Everyone is set on bundler for example. There are really only two big testing frameworks that compete and the have very different goals etc.

Re: A Clojure learning journey

#65

Post by ajmurmann »

jcadam wrote: post #28
scardine wrote: post #12

I just got rejected in a hiring process at Nubank (a sexy fintec from Brazil that uses clojure a lot) because I used a database for the take-home code challenge they sent me (writing a REST API). Since I'm a Python developer who knows little about concurrency in clojure and I would not like to use locks, I thought it would be better to delegate these things to the database. Apparently I was supposed to use a global s…

I had a similar assignment when I applied for a remote Clojure job at a startup in California. Create a REST API in Clojure (which I can do in my sleep at this point). I decided to use a database (in my case, H2) along with HugSQL because it handled some of the requirements for me (unique constraints, etc.), and I'm comfortable with databases. I could have done it in code using a collection (and used filter/map/reduc…

Not being a Clojure dev I'm curious: Wouldn't a database be the more scalable solution? How would multiple servers share access to the data of it's in memory? What about persistence?

Re: A Clojure learning journey

#66

Post by sk5t »

jxub wrote: post #56
platz wrote: post #55

Earlier quoted context omitted.

> Lots and lots of tweaks and knobs and dials This is the case with all big-tent, "community-driven" PLs that have a high expressiveness, and attract contributors that have a multitude of preferences: Ruby, Javascript, Scala, Clojure, Haskell, Racket Alternatively, are the 'prescriptive' cultures, that tend to select for predictability and high cohesion: C#, Elm, Go, Python (circa-2007).

It would be interesting to study the MBTI psyche types in each of the major language communities.

Would it be fair to say phrenological study of the same groups might be similarly interesting?

Re: A Clojure learning journey

#68

Post by hatchback176 »

sk5t wrote: post #66
jxub wrote: post #56

Earlier quoted context omitted.

It would be interesting to study the MBTI psyche types in each of the major language communities.

Would it be fair to say phrenological study of the same groups might be similarly interesting?

I highly doubt you have a methodology for studying group psychology

Re: A Clojure learning journey

#69

Post by jcadam »

ajmurmann wrote: post #65
jcadam wrote: post #28

Earlier quoted context omitted.

I had a similar assignment when I applied for a remote Clojure job at a startup in California. Create a REST API in Clojure (which I can do in my sleep at this point). I decided to use a database (in my case, H2) along with HugSQL because it handled some of the requirements for me (unique constraints, etc.), and I'm comfortable with databases. I could have done it in code using a collection (and used filter/map/reduc…

Not being a Clojure dev I'm curious: Wouldn't a database be the more scalable solution? How would multiple servers share access to the data of it's in memory? What about persistence?

It was an 'exercise' for evaluation purpose. In the instructions I was told that a database was not necessary (I'm assuming the interviewer didn't want to have to setup a DBMS just to evaluate my solution).

The obvious solution to me in this case was not to eschew the use of a database. Since Clojure runs on the JVM, there are many 'embeddable' databases one can use (H2, Derby, et al) that do not place a burden on the person running your program. Hacking together a poor implementation of an in-memory database myself seemed silly.

Indeed, a major use of embedded databases like H2 and Derby is in prototyping - with the intent of moving to a 'real' database in production.

Re: A Clojure learning journey

#70

Post by james-mcelwain »

fro0116 wrote: post #61
james-mcelwain wrote: post #42

Earlier quoted context omitted.

It sounds like you're suggesting that Python/Node have better libraries, which couldn't be further from the truth. Most "abandoned" Clojure libraries either (a). aren't abandoned and "just work" due to their limited scope or (b). are wrappers to Java libraries that are trivial or unnecessary. Most people would rather to interop directly.

To offer one small piece of anecdote to the contrary: We use Clojure for most of our server-side code and picked Lacinia from Walmart Labs [0] to implement our new GraphQL API. It does most of the basics just fine, but its pace of development lags extremely, painfully far behind GraphQL server implementations in more popular languages such as the ones in Node and Python. To this day it still doesn't have support for…

Fair -- GraphQL seems like something that is particularly well suited to having a Clojure API so that's disappointing to hear it lags behind other implementations.
Post reply on HN