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

Clojure's machine learning ecosystem

codewithkira.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Clojure's machine learning ecosystem

#71

Post by BaculumMeumEst »

cess11 wrote: post #70
roenxi wrote: post #38

Earlier quoted context omitted.

I spot 6 points in that comment and most of them strike me as fair. But two I think are not: 1) The language evolving all the time is an anti-feature. Clojure is an oasis for the people who are tired of having their knowledge obsoleted by constant change that doesn't really improve anything. People can build whatever weird and wonderful features they want using macros in their own library. 2) deps/edn - the design se…

Racketeers also typically use the macro system, which is exceptionally robust and sane, for new features. The base language has been very stable for a long time. That's how the typed dialect is implemented, which you can use with ease on a per-file basis in your project where performance is important, and it also supports at least a couple of Scheme standards in the same way. Another thing that's nice with Racket is…

Yes! The binaries and gui-easy are both great!

And I just love how easy it is to do everything in Racket. Creating an executable, adding a package, including a module, even spinning up a new file and putting it in SICP compatibility mode - all of these things require 0 memory or reference with a manual because they're so straightforward. Everything is very nicely designed.

Re: Clojure's machine learning ecosystem

#72

Post by BaculumMeumEst »

pjmlp wrote: post #62
BaculumMeumEst wrote: post #12

For web server stuff, I still think Clojure is extremely solid. But I’ve come to really prefer Racket for general purpose programming. I really like the package manager, I like that there’s an IDE with a visual step debugger (seriously, why do almost no lisp people value this?), that it’s multi paradigm, and that the language continues to improve and evolve. Clojure just has so many finicky or annoying things about i…

> why do almost no lisp people value this? We do, that is why Cursive exists. The problem are the folks educated in SBCL + Emacs that never used anything else Lisp related, including the survivors of the Lisp hype wave like Lisp Works and Allegro Common Lisp.

IME Cursive has been very jank. Debugging intermittently fails to trigger on my web projects across multiple machines. It has not been as positive experience as I've had with Racket's IDE (or LispWorks! I love LispWorks!)

The other issue with debugging is perhaps a "me problem", but it's not uncommon for me to have to re-discover where laziness is present in Clojure's ecosystem while debugging. I don't like laziness being implemented on core functions - I think they should be explicitly named alternate functions. Laziness everywhere + "super stable language" = forever annoying. I guess this is only an issue for others who seldom use Clojure as a hobby language - I'm sure people who use daily are able to cope better.

Re: Clojure's machine learning ecosystem

#73

Post by BaculumMeumEst »

djtango wrote: post #55
BaculumMeumEst wrote: post #52

Earlier quoted context omitted.

> The easiest way to run and learn FlowStorm with ClojureStorm is by running the repl tutorial, like this : ;; on Linux and OSX clj -Sforce -Sdeps '{:deps {} :aliases {:dev {:classpath-overrides {org.clojure/clojure nil} :extra-deps {com.github.flow-storm/clojure {:mvn/version "RELEASE"} com.github.flow-storm/flow-storm-dbg {:mvn/version "RELEASE"}} :jvm-opts ["-Dclojure.storm.instrumentEnable=true" "-Dclojure.storm.…

What do you hate about it? You can run a project with a library in a repl with a one liner - seems handy. Don't even need to create a file

Because these god forsaken strings are how you do everything in Clojure CLI. When you start a new project, you write them by hand. You flip and fiddle with plain text flags and weird nested hash tables to change tool behavior, and you have to remember so many little stupid things. It makes actually doing stuff feel horrible. There should have been a high bar for supplanting Leiningen and this should not have cleared it.

Re: Clojure's machine learning ecosystem

#74

Post by djtango »

BaculumMeumEst wrote: post #73
djtango wrote: post #55

Earlier quoted context omitted.

What do you hate about it? You can run a project with a library in a repl with a one liner - seems handy. Don't even need to create a file

Because these god forsaken strings are how you do everything in Clojure CLI. When you start a new project, you write them by hand. You flip and fiddle with plain text flags and weird nested hash tables to change tool behavior, and you have to remember so many little stupid things. It makes actually doing stuff feel horrible. There should have been a high bar for supplanting Leiningen and this should not have cleared…

But wasn't the example in question for a tutorial repl setup for you getting up and running with no config? That seems like a nice user experience for someone who wants to get up and running by just copy pasting a one liner...

What projects are you working on where you are using nested hash tables passed in as strings to the CLI that couldn't be written as data in a deps.edn?

What tools do you miss from lein (genuine question) moving to deps.edn was mostly painless for the teams I've worked wit

Re: Clojure's machine learning ecosystem

#75

Post by neonsunset »

banashark wrote: post #57
Capricorn2481 wrote: post #43

Earlier quoted context omitted.

For me it's not that using Asp.net from F# is bad, but the little things that add up. Like I said, if you want to use Microsoft Identity, you need to either write your own backend that doesn't use EFcore or use .NET 6 instead of 8. Why? EFcore is essentially a scaffolding library. You can't use it from F# without EFcore.FSharp. EFCore.FSharp doesn't support anything higher than .NET 6. So now we have a scenario where…

I understand where you're coming from on these 100%, but I believe some of the conclusions might be more dire than they are in practice. Both identity and efcore both work fine with F#. What _doesn't_ work is the EF Core design-time support (having models auto-create your schema) and scaffolding razor pages with F# (razor pages just doesn't work in general). Calling these APIs (authing your users, and interacting wit…

The temptation to whine, cry and complain is too high in developer communities, as always.

It's either "just the way I want it exactly" or "unusable", any smallest and most accessible but slightly different option from preferred way to make things work be damned.

I'm really sad to see a part of F# community being persistently vocal against .NET which makes F# viable and possible in the first place.

Re: Clojure's machine learning ecosystem

#76

Post by kmclean »

zmmmmm wrote: post #61
esrh wrote: post #46

> Smile 3.x Avoided due to licensing > Smile 3.x is GPL-licensed, which poses some potential conflicts for some end users...The community consensus is converging around moving away from Smile due to the GPL-relicensing issue, focusing instead on Tribuo... (tribuo is developed by oracle) It's a really great thing that the java community has a high performance and well accepted (~5x stars than tribuo) ML package that's…

> I don't think it's right to recommend that new users move away from the package because of licensing issues I was going to chime in to agree but then I saw how this was done - a completely innocuous looking commit: https://github.com/haifengl/smile/commit/6f22097b233a3436519... And literally no mention in the release notes: https://github.com/haifengl/smile/releases/tag/v3.0.0 I think if you are going to change lic…

Yeah.. I have all the respect in the world for Haifeng's talent and I totally understand (and agree!) that open source developers need to be compensated one way or another, and I don't want to get into a debate that could lead to accusations by people who don't know the full story, but there are definitely some sour grapes over the whole situation and some of the pull away from smile has more to do with feelings that not everyone involved is acting in good faith more than issues about GPL exactly.

Re: Clojure's machine learning ecosystem

#77

Post by Capricorn2481 »

neonsunset wrote: post #75
banashark wrote: post #57

Earlier quoted context omitted.

I understand where you're coming from on these 100%, but I believe some of the conclusions might be more dire than they are in practice. Both identity and efcore both work fine with F#. What _doesn't_ work is the EF Core design-time support (having models auto-create your schema) and scaffolding razor pages with F# (razor pages just doesn't work in general). Calling these APIs (authing your users, and interacting wit…

The temptation to whine, cry and complain is too high in developer communities, as always. It's either "just the way I want it exactly" or "unusable", any smallest and most accessible but slightly different option from preferred way to make things work be damned. I'm really sad to see a part of F# community being persistently vocal against .NET which makes F# viable and possible in the first place.

That's an extremely uncharitable take of my comment. I wouldn't call the many days I've spent investigating and opening issues that the F# community didn't even know about (because it's on life support) to be whining about small things. I can't tell you how many times things just don't work and the community kinda shrugs it off and says "use C#".

If you look in the database section of F# websites, maybe 20% of those libraries work. If you bring it up to people online, they'll say "yeah use Dapper, it's the only thing that works".

This just isn't the case in Clojure and I don't think the expectation is that it should be.

Re: Clojure's machine learning ecosystem

#78

Post by Capricorn2481 »

banashark wrote: post #57
Capricorn2481 wrote: post #43

Earlier quoted context omitted.

For me it's not that using Asp.net from F# is bad, but the little things that add up. Like I said, if you want to use Microsoft Identity, you need to either write your own backend that doesn't use EFcore or use .NET 6 instead of 8. Why? EFcore is essentially a scaffolding library. You can't use it from F# without EFcore.FSharp. EFCore.FSharp doesn't support anything higher than .NET 6. So now we have a scenario where…

I understand where you're coming from on these 100%, but I believe some of the conclusions might be more dire than they are in practice. Both identity and efcore both work fine with F#. What _doesn't_ work is the EF Core design-time support (having models auto-create your schema) and scaffolding razor pages with F# (razor pages just doesn't work in general). Calling these APIs (authing your users, and interacting wit…

But EFcore and Identity are documented assuming you'll use scaffolding. They set up a bunch of models for you representing users and roles. You wouldn't know how to set this up if you tried to do it in F#. You'd have to set it up in C# first to see what it would look like, and then you might as well just use C#

Re: Clojure's machine learning ecosystem

#79

Post by lispm »

pjmlp wrote: post #62
BaculumMeumEst wrote: post #12

For web server stuff, I still think Clojure is extremely solid. But I’ve come to really prefer Racket for general purpose programming. I really like the package manager, I like that there’s an IDE with a visual step debugger (seriously, why do almost no lisp people value this?), that it’s multi paradigm, and that the language continues to improve and evolve. Clojure just has so many finicky or annoying things about i…

> why do almost no lisp people value this? We do, that is why Cursive exists. The problem are the folks educated in SBCL + Emacs that never used anything else Lisp related, including the survivors of the Lisp hype wave like Lisp Works and Allegro Common Lisp.

I own LispWorks, I have Symbolics Genera. I've used MCL. I almost never found a stepper to be particular useful to my problems. The other debugging tools were more useful.

Re: Clojure's machine learning ecosystem

#80

Post by clusterhacks »

dustingetz wrote: post #17
yawn wrote: post #9

Earlier quoted context omitted.

> but there are certainly domains where Clojure is the best fit Honest question: what domains?

clojure is everywhere in fintech - nubank, guaranteed rate, kroo bank, griffin, pennymac, two sigma, dividend finance, treasury prime, gravie. Other big areas are healthcare and midmarket adtech. And of course startups outside of SF/NYC with smaller seed rounds looking for tech advantage - midwest USA, Europe/UK, Latin america The further you get from silicon valley the more clojure you see — anyone with a network at…

Doesn't this ignore the reality on the ground that Clojure is a niche (but wonderful) programming language that offers very few career opportunities? It simply isn't big in any specific domain.

I also don't buy that you see more Clojure the "further you get from silicon valley ..." without some actual (or even anecdotal) data to support that claim.

I'm not saying there are zero instances of Clojure in production systems. But it is hard for me to think that it represents a large number of professional employed software engineers. The 2023 StackOverflow survey show 1.38% out of 67,053 respondents in their "most commonly used programming language" section naming Clojure. That is less than 1,000 developers. The public university I work at graduated 500+ CS undergrads in 2023. I would bet $100 that zero of those got a first job that paid them to write Clojure professionally. I would bet $1000 for less than ten grads. I would bet $50,000 for less than 25.

I'm not trying to be cute but don't you think there are less than 10,000 software engineers in the US (maybe the freaking world) who primarily write Clojure code in their day job?

Because I'm curious, job searches at the company site of your list for 'clojure':

  Nubank - enhum resultado com a palavra "clojure" encontrado (no results)

  Guaranteed Rate - no results

  Kroo Bank careers page - no tech listings currently

  Griffin - open listing for software engineer (London or Remote within the UK, Germany, Sweden or Ireland) - description: Our backend stack is Clojure, FoundationDB, Kubernetes and AWS. Our frontend stack is CLJS, Reframe, Reagent, React, Stitches, Storybook, and Playroom.

  Pennymac - Sorry, no jobs were found that match your search criteria. 

  Two Sigma - No jobs found

  Dividend Finance - 0 JOBS FOUND

  Treasury Prime - There are no current openings. (for software engineers)

  Gravie - Lead software engineer position - description: Advanced programming experience in multiple programming languages ( Java, Kotlin, Groovy/Grails, JavaScript/TypeScript or Python) along with Clojure/ClojureScript or another functional programming language
Indeed.com returns 15 jobs posted in the last two weeks (US) for the Clojure keyword. LinkedIn returns 34 job posting in the last month (again, in the US).

I love Clojure - it has always "worked" in my head as a language to solve problems in. I was at the first Clojure/conj. I have deployed production code that I wrote in Clojure. Clojure made me a better developer in other languages.

But in the big picture for professional software engineers, Clojure might as well not exist.

Post reply on HN