Live data from Hacker News

Clojure's machine learning ecosystem

codewithkira.com

61–70 of 87 posts

Re: Clojure's machine learning ecosystem

#61
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 license, especially in a way that makes it less permissive, you need to be super open and clear about both the fact you are doing it and your reasons for that. This is done so silently as to look like it is intentionally trying to mislead and trick people.

So maybe I wouldn't say to move away because of the specific license, but it's legitimate to avoid something when it's so clearly driven by a single entity and that entity acts in a way that isn't trustworthy.

Re: Clojure's machine learning ecosystem

#62

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.

Re: Clojure's machine learning ecosystem

#63
post #35

If Clojure compiled to native code by default, instead of relying on the JVM, it'd be much more attractive to me. I know many people don't care about this...

You could probably achieve that via GraalVM I would think.

And OpenJ9.

Eventually ART, although here the process would be more convuluted.

And if one is willing to give away a couple a big piles of money, PTC and Aicas are still in Java town.

Re: Clojure's machine learning ecosystem

#64

Earlier quoted context omitted.

And imagine if F# had an alternative native "runtime" (i.e. not married CLR and dotnet) grafted onto Fortran. Resistance is futile, indeed.

I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with. - Giraffe do…

What you describe is a very good example, why I seldom rely on guest languages for production code.

Communities can't control themselves, always try to create an ecosystem on top of the ecosystem, some of them even are quite vocal against the platform that made their beloved language possible in first places.

Thus as the platform moves under their feet, everyone fails to keep up, to make anything usable one has to master now two stacks instead of one, and spend even more time tracking down issues.

Clojure's approach to embrace the host is a much better way to handle this.

Re: Clojure's machine learning ecosystem

#65

Earlier quoted context omitted.

And imagine if F# had an alternative native "runtime" (i.e. not married CLR and dotnet) grafted onto Fortran. Resistance is futile, indeed.

I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with. - Giraffe do…

Suave does not depend on Asp.net

Re: Clojure's machine learning ecosystem

#66
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…

The most unexpected place I’ve encountered Clojure “in the wild” is the Defold game engines editor.

Re: Clojure's machine learning ecosystem

#67
post #20

Earlier quoted context omitted.

Good luck getting academics to adopt anything they don't know about, and all they know about is Python.

This is a strange comment that probably reflects the sliver of academics you're familiar with. Who do you think wrote and continues to develop R and all those packages? There are actually many types of software in use by academics.

Probably true.

Re: Clojure's machine learning ecosystem

#68
post #20

Earlier quoted context omitted.

Good luck getting academics to adopt anything they don't know about, and all they know about is Python.

Academics is much older than Python. At some point, they adopted that .

Academics (the mass noun, meaning something similar to "academia") does indeed learn and progress. Academics (the worker bees in the academic hive) can be super intransigent and in my experience learn a couple of tools in their younger days and never again. As they say, science advances one funeral at a time. I've found that new ideas and technologies are almost always brought in by new students, and not old academic dogs learning new technological tricks.

Re: Clojure's machine learning ecosystem

#69
post #54

Earlier quoted context omitted.

And imagine if F# had an alternative native "runtime" (i.e. not married CLR and dotnet) grafted onto Fortran. Resistance is futile, indeed.

Isn’t this effectively OCaml? Minus the Fortran part but it doesn’t need any other runtime.

Sort of I guess, but there are things like how they look very different and that F# is very very fast, has static types and OCaml is not exactly slow but not fast exactly fast, either.

Re: Clojure's machine learning ecosystem

#70
post #38

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…

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 that it can produce binaries, and while the cross-compile story is kind of messy the language as such is actually, really, multi-platform. Even the GUI-library, which is quite nice, especially with gui-easy additions.

Post reply on HN