[HN Gopher] Clojure Turns 15 panel discussion video
___________________________________________________________________
Clojure Turns 15 panel discussion video
Author : fogus
Score : 219 points
Date : 2023-02-13 15:21 UTC (7 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| revskill wrote:
| I tried Clojure, but when i look for a good ORM, what i see is a
| paid library.
| dgb23 wrote:
| Typical ORM's are a mismatch for Clojure. Two pretty good
| options to generate SQL are honeysql and hugsql. They both
| attack the problem from two different directions.
| patrickthebold wrote:
| https://www.hugsql.org/ seems pretty nice. Not exactly an ORM,
| but probably does what you need.
| snorremd wrote:
| In Clojure ORMs aren't really that popular considering most
| Clojurists just use the built in datatypes (e.g. maps) to
| represent data. There are no classes as such (unless you use
| Java interop). If you need a query builder the honeysql library
| is really nice.
| rawoke083600 wrote:
| Lol yup ! "It's Maps All The Way Down"
| camdez wrote:
| Expanding on this a bit, Clojure, as a language, is
| fundamentally against the idea of ORMs in its design.
|
| Objects / classes are not so much the problem, per se--it's
| specifically that ORMs fundamentally involve scattering
| uncoordinated mutable state throughout the application. A
| foundational thesis of Clojure is that mutation is a
| tremendous source of bugs, and should be avoided /
| thoughtfully limited.
|
| Once you let the unmanaged mutation genie out of the bottle,
| it's almost impossible to put back in.
|
| More concretely, I used to work extensively with Rails; I
| loved ActiveRecord (ORM) when I first started out--it makes
| basic things so easy.
|
| Later I worked on a large Rails app supporting millions of
| users...we used ActiveRecord extensively, and had a very
| talented team. ActiveRecord worked fine most of the time, but
| I have bad memories of spending hours or even days tracking
| down user-reported bugs.
|
| I'd try to figure out how to recreate the user's state
| locally, even cloning pieces of the production database to
| work with their exact DB data, but whatever state the program
| had gotten into was a large graph of (all!) mutable objects.
| _How was that flag getting set? What code could have done it?
| When?_ And the answer is basically ANYTHING at ANY TIME that
| could possibly get a reference to the object. And web
| applications are far from the worst offenders in this space
| because the request / response cycle is (usually) fairly
| globally stateless.
|
| Clojure is the exact opposite of that experience.
|
| The state of a Clojure program will most likely comprised of
| data literals (think JSON data types, if you don't have
| experience with Clojure / Lisp data). _Printable_ data
| literals. Connect to the errant server, serialize the state,
| read it from your machine, and you 're there. It's coherent,
| stable, serializable, transmittable, simple.
|
| Who can mutate your data? No one. You have an immutable
| reference (maybe others do too, but reading is a
| fundamentally safe operation). How does it change? Only along
| the explicit path of computations you're working through (it
| doesn't change, actually, you _choose_ to hold onto a new
| reference to derived data when you want to).
|
| Or, if you _really_ need a mutable escape hatch (like, say,
| you 're holding a handle to a database), every type of
| mutation in (core) Clojure has defined (and thoughtfully so)
| concurrency semantics. You won't see a bunch of notes in
| Clojure API docs that say things like "not thread safe" like
| you see in JavaDocs.
|
| TLDR: Clojure will happily give you object-like read-only
| views into your database (like Datomic's
| `datomic.api/entity`), or help you write queries with a
| knowledge of your database schema, but most Clojure
| persistence solutions will explicitly coordinate mutation
| into a single 'site' because that's the only way maintain a
| coherent view of state-over-time. And that single-mutation-
| site story is the opposite of what ORMs (as commonly defined)
| do.
| danuker wrote:
| > just use the built in datatypes (e.g. maps)
|
| Well, then, MRM: Map-Relational-Mapper.
| orestis wrote:
| HoneySQL allows you to write SQL via data structures so you can
| compose that. Gives you a lot of power.
| danuker wrote:
| There's this:
|
| https://github.com/metabase/toucan
|
| But beware what you do with it. Avoid DB side effects from
| business logic.
| cammsaul wrote:
| Hi, Toucan library author here.
|
| +1 on avoiding side effects from business logic. This applies
| not just to Toucan, but to database code in general. Toucan
| is there to give you a way to define behaviors when
| interacting with your application database, for example
| transforming certain columns when you fetch rows from a
| certain table from the database. It's that plus utility
| functions for interacting with your database. Not really an
| ORM.
|
| Either way, Toucan 2 is out now:
| https://github.com/camsaul/toucan2 I'm still working on fully
| documenting it but it's already being used in the wild and
| Toucan 1 will probably be archived soon
| chitowneats wrote:
| You don't want an Object Relational Mapping library in a
| language that discourages object orientation.
| rawoke083600 wrote:
| If you really want to melt your brain (in a GOOD way) look at
| XTDB it's a datalog-query-based DB. Like dataomic but free.
| Per_Bothner wrote:
| To toot my own horn: The oldest still-active compiler-based
| language on the Java platform, besides Java, is as far as I know
| Kawa (https://gnu.org/software/kawa). It started Summer 1996, and
| is still actively maintained. (Not as active as it used to be, to
| be true.) Like Clojure, it is a Scheme-like language, but (unlike
| Clojure) it is very compatible with "regular" Scheme (R7RS),
| though of couurse with lots of extensions. With a little bit of
| care (including optional type-specifiers), it is easy to write
| code that is as fast as Java code.
| BaculumMeumEst wrote:
| Oh cool! That language is so fun to use, thank you for writing
| and maintaining it!
| vaylian wrote:
| Clojure is the language that made me understand why Lisp matters:
| We can express ideas and instructions in a programming language
| with just a very basic set of tools. And we can use these tools
| to craft powerful and elegant abstractions. In addition, Clojure
| emphasizes immutable data structures, which, after some learning
| effort, made me write code that is much easier to reason about.
| cfiggers wrote:
| I see some comments in here with the sentiment, "Clojure--What am
| I missing?" Here's an attempt to answer that question. I am just
| a hobbyist and enthusiast programmer with no formal background in
| programming or CS, and no real experience using Clojure (or any
| other language, for that matter) "in anger" in a serious
| production environment. These are just some nobody's two cents,
| take or leave them for whatever they're worth to you.
|
| From what I understand, there are some applications and domains
| that the JVM is highly optimized for--especially long-lived,
| highly concurrent server processes or stream processing
| applications where microseconds matter in order to keep up with
| real-time. The fly in the ointment (for some) is that Java itself
| is Object-oriented, compiled, statically typed, and uses mutable
| objects and data structures by default. Not everybody loves those
| design choices. And even of those who do, not everybody finds
| Java ergonomic (hence Scala and Kotlin, among others).
|
| So, much like Scala and Kotlin do, vanilla Clojure just gives
| access to the JVM (and its _highly_ mature library ecosystem) in
| different trappings. It 's a functional (rather than object-
| oriented), REPL-driven (rather than compiler-first), dynamically-
| typed, and immutable data-oriented language, with Lisp's minimal
| syntax and structural editing experience. Plus, the designers
| have invested a lot of time and their cumulative decades of
| programming experience into making a really solid standard
| library that comes with a lot of smart affordances out of the
| box. That combo really works for some people.
|
| Then, folks who appreciated the conveniences and good design in
| vanilla Clojure started looking for that dev experience in non-
| JVM contexts, which is how you get ClojureScript, ClojureDart,
| ClojErl, Babashka, Scittle, etc. And then, other Clojure-
| _inspired_ languages pop up that don 't purely adhere to Clojure
| conventions, but co-opt significant portions of its well-designed
| syntax and standard library--languages like Janet (compiles to C)
| and Fennel (compiles to LUA) and Hy (compiles to Python).
|
| And then, script kiddies like me come along and discover, Hey
| Wow, I can learn _one syntax_ and suddenly be +80% dangerous in a
| dozen different environments, without having to start learning a
| new language from scratch in each one--from the JVM to the
| browser to mobile apps to native executables, I 've got SOMETHING
| to start building on because I already know how to think in
| Clojure.
|
| At this point, "Clojure" is not just "a language," it's a
| _category_ of languages--just like Scheme is "a Lisp," Janet is
| "a Clojure." I don't think that happens with uninteresting,
| poorly-designed, or irrelevant languages. Clojure scratches a
| specific itch, and not everybody has that itch to scratch. But
| whether Clojure is your cup of tea or not (and obviously for many
| people in this comment section, it's not), I don't think anyone
| can debate that it's a significant project that justifies its own
| existence. That doesn't obligate anybody to use it or even look
| at it twice, but I think it self-refutes a lot of the negativity
| that gets thrown its way.
| eduction wrote:
| I have been using Clojure for a solo project for a while now and
| find it shockingly productive. I initially planned to limit how
| much of the language "surface area" I explored to keep focused on
| solving the problem but was able to productively use much more of
| Clojure than I expected:
|
| -core.async for concurrency that led me speed up some tasks from
| ~1000ms to ~40ms (well, core.async got me to about 100ms, or
| closer to 5x speedup on other tasks, and then other optimizations
| got me the rest of the way). Also using refs for some very
| limited data sharing across go threads (apparently actually using
| refs and dosync, aka mvcc data structures, is rare).
|
| -spec for parsing a dsl and validating input
|
| -macros for a select few syntax and core async optimizations
| (avoiding unnecessary go block usage)
|
| -multimethods for extensibility
|
| -a fair amount of Java interop to use best in class libraries
|
| -transients to help optimize performance in some places
|
| -even transducers a few places (maybe 1 percent of my code if
| that, but still)
|
| -edn for dsl files
|
| I sense that where people have more friction is trying to work
| with other people, in teams and organizations. In the right
| organization this can clearly work, dedicated Clojure shops, but
| there can be resistance in other organizations, and it has to be
| "smuggled in", and people worry about the ability to hire
| (especially for orgs that tend not to train heavily - nubank
| clearly trains a lot of programmers on Clojure but many shops
| don't want to do this level of training). And then people will
| avoid using certain advanced features like macros or even some
| functional conventions (recursion, reduce and map etc instead of
| vanilla loops) because they worry it will make it harder to
| onboard people without Lisp or FP experience.
|
| I honestly think this is Clojure's big challenge, entrenched
| expectations and conventions in the industry and a desire to pull
| programmers off the shelf. In this talk (the one we're all
| commenting on) Rich and others point at the productivity and fun
| of REPL driven development -- finding some way to really grow
| that and somehow take it to the next level -- as a possible
| solution, to offer yet another carrot to encourage people to make
| the leap to Clojure. It sounds like a good idea but I have no
| idea what that looks like exactly.
|
| I honestly think the answer to getting more Clojure penetration
| may be the passage of time, as happened with python. I know
| nubank/cognitect has been funding some open source work with
| small grants on top of Alex and Rich's work (and Stuart's?). This
| kind of basic grunt work can pay off long term. But it's not a
| sexy answer and if it doesn't work you're at a dead end.
| avindroth wrote:
| I have also been using CLJS/Clojure for a solo project. I
| debated between CL and Clojure for the backend, but CL's
| package ecosystem is too weak to be justified. What other
| languages did you consider for your stack and what did you
| think were the tradeoffs?
| garbagecoder wrote:
| For just the right thing, I've loved using Clojure and wish I
| could use it some more, but I rarely find that just right thing.
| beders wrote:
| Lisp has ruined me forever. I'm not sure how I can go back to
| other languages.
|
| I basically started out with Allegro Common Lisp on Sparc's, went
| to Java because it was the shiny new thing, and then in 2017
| finally took the plunge and have been addicted to Clojure ever
| since.
|
| Don't get me wrong: the learning curve can be steep, but the
| steepness - at least in my case - came from un-learning all the
| object-oriented stuff.
|
| Once you understand the value of values and the simplicity it
| brings, it becomes such a joy to code in Clojure.
|
| For the people on here disgusted by the JVM ecosystem: There are
| many alternatives for Clojure.
|
| There's Clojure for .NET, ClojureScript in at least two flavors
| that compile down to JavaScript, there's a fast interpreter
| called babashka for scripting, there's Clojerl for the Erlang VM,
| there's jank - which adds gradual typing on a C++ runtime.
|
| Oh, and there's jobs that pay really well ;)
| runevault wrote:
| How is Clojure for dotNet? I haven't touched Clojure in general
| for years (honestly I think it's been at least a decade) but I
| remember a lot of libraries making calls expecting the Java
| standard library so seems like things would have broken, but
| maybe it is gotten a lot better in recent years.
| puredanger wrote:
| It's been kept up to parity but a complete rewrite is
| currently under way - watch
| https://dmiller.github.io/clojure-clr-next/
| garbagecoder wrote:
| You don't have to be using a lisp to benefit from the different
| way it makes you think about things. In most languages it's at
| least somewhat possible to use some of its good stuff.
| rcarmo wrote:
| Nice to see, but I'm still sad Clojure is a hosted JVM language.
| I find it unwieldy for a lot of things where Go, Python and
| Chicken Scheme shine, and wish someone got ClojureScript to run
| natively in things like Bun or Deno so I could have one fast,
| small runtime.
| orestis wrote:
| Check out Babashka!
| distantaidenn wrote:
| I love Clojure (and have touted such in past comments), but it
| suffers from a glaring problem: every library is half done and/or
| abandoned. What happens is you end up modifying an existing
| library to fit your particular problem space. I needed a web
| framework. None of them just did things in a "simple way". I
| ended up branching an existing one and have altered it (very
| heavily) to fit what I need. It's now my go-to for all new
| projects.
|
| The issue with us Lispers is that we love the language more than
| we do the tooling. Tooling be damned! So we all end up re-
| inventing the wheel for the 1000th time. We will never gain wide
| spread adoption, as such.
|
| With Ruby, I have Rails. With Python: Django. With Clojure...well
| good luck. Every framework does one thing beautifully correct and
| about 10 things wrong. But hey, it's up to you to modify the
| framework! Because that's the Lisp way of doing things!
|
| Maybe I should publish my bespoke framework one of these days...
| danuker wrote:
| Every early ecosystem suffers from lack of mature libraries. It
| is a chicken and egg problem.
|
| I think your contribution would be very welcome, especially
| with a bit of docs or minimal examples.
| yenda wrote:
| I think every clojure dev that sticks long enough and feels the
| need for a framework ends up publishing one. The reason none of
| them stands out much imo is that library composition is pretty
| easy to do and the building blocks libraries out there do their
| thing pretty well. So with a bit of experience even on a new
| project it feels much easier to adopt your known set of
| building blocks, maybe throw a few new ones into the mix or
| replace one and you are good to go. At the end of the day it
| doesn't take more time than learning a framework yet it gives
| you a lot more flexibility.
| gemstones wrote:
| While I like Clojure as a language - I have never seen a language
| that engendered such hatred in PMs, EMs, sales, etc. I don't know
| that it survives long term (in industry, it'll survive for a long
| time as a hobby language.)
| pelasaco wrote:
| I like Clojure, but unfortunately for web development, there
| isn't a great stack and for data science/ML/AI (which is a
| great fit for clojure), python dominates the market. What is
| the niche for Clojure, or why should keep using it in 2023?
|
| P.S: I like it a lot, but either I do golang or ror for web
| dev, or python/pytorch for data sciences/AI stuff, C# for game
| development. I don't think i can get more productive with
| Clojure in any scenario, that I'm exposed too, what I'm
| missing?
| lgessler wrote:
| > I like Clojure, but unfortunately for web development,
| there isn't a great stack
|
| What do you feel is missing? Certainly there are options
| (something as frameworky as Fulcro, something as barebones as
| a React wrapper like Reagent), so there must be some itch you
| can't scratch?
| pelasaco wrote:
| wow, first time seeing Fulcro, and it has a great
| documentation https://book.fulcrologic.com/, definitely
| will play with that, thanks!
| lgessler wrote:
| Yeah, it's too heavy for some things, but it's
| situationally very awesome. Fulcro takes the fantasy of
| "reusable components" very seriously, more seriously than
| any other frontend framework I'm aware of, and designs
| from the ground up to allow for that. Be sure to go to
| #fulcro in the Clojurians slack with any
| questions/comments--it's a very friendly community in
| there.
| Heliosmaster wrote:
| Check Clerk (https://clerk.vision/) for the boundaries
| between data science / data viz / moldable programming
| ARandomerDude wrote:
| It is actually a great choice for unopinionated server-side
| web development.
|
| Frontend development is simply awesome in ClojureScript. Give
| me Reagent + Shadow CLJS over plain React (or React Native)
| any day.
| pelasaco wrote:
| Yes, ClojureScript is definitely on my learning list, we
| however decided to avoid one more transpilation tool, and
| accepted the fact that we have to write typescript.
|
| > Give me Reagent + Shadow CLJS over plain React (or React
| Native) any day.
|
| So that is for heavy js based applications, not for
| something light like rails + stimulus.js, right?
| moonchrome wrote:
| >Frontend development is simply awesome in ClojureScript
|
| Is that still tied to that google closure abomination ?
| I've not been in CLJ ecosystem for >5 years now but last
| time I used CLJS I remember they went all in on google
| Closure and it was a major PITA to use the rest of JS
| ecosystem because of it.
|
| Every time I use React I think how it would be great to use
| Clojure for that, but last time I tried the tooling
| overhead just killed it for me.
| lgessler wrote:
| > Is that still tied to that google closure abomination ?
| I've not been in CLJ ecosystem for >5 years now but last
| time I used CLJS I remember they went all in on google
| Closure and it was a major PITA to use the rest of JS
| ecosystem because of it.
|
| This has been solved now--there's a blessed CLJS
| solution[1][2] as well as a third-party compiler with NPM
| support[3] which many prefer.
|
| [1]:
| https://clojurescript.org/news/2017-07-12-clojurescript-
| is-n...
|
| [2]: https://cljs.github.io/api/compiler-options/npm-deps
|
| [3]: https://shadow-
| cljs.github.io/docs/UsersGuide.html#npm
| simongray wrote:
| Shadow-cljs makes everything very easy these days.
| ndr wrote:
| For you and anyone else with experience, is that the most
| common/battle-tested cljs stack?
|
| What about servers-side, any equivalent Django or FastAPI?
| ARandomerDude wrote:
| No affiliation, but I think this is a great example CRUD
| API.
|
| https://github.com/dharrigan/startrek
| dack wrote:
| The cljs stack I hear about a lot (and use) is ShadowCLJS
| with reagent (https://reagent-project.github.io/) and re-
| frame (https://day8.github.io/re-frame/). ShadowCLJS is
| more of a build tool, but is really well documented and
| easy to use. Reagent is basically react but a simpler
| API, and re-frame is a layer on top of that kinda like
| redux. It's overkill for some apps but I find it's
| actually super easy to work with and not as much
| complexity as I thought.
|
| For backend there is luminus (https://luminusweb.com/) or
| Kit (https://kit-clj.github.io/). They are basically
| project templates that wire together a ton of popular
| solutions for various things - database access,
| migrations, security, html templating, etc. Also includes
| frontend frameworks like re-frame if you want.
|
| edit: forgot to mention fulcro
| (https://fulcro.fulcrologic.com/) which is an interesting
| full stack solution. I haven't used it though so can't
| comment, but it sure seems documented well!
| ndr wrote:
| Thank you. What about leiningen vs boot vs deps.edn? Did
| any of this come ahead as a winner in the recent years?
| It's been a while since I've looked into this.
| gtoast wrote:
| Boot died, sadly. There was some talk of a Boot 3.0 but
| it never materialized. I think deps.edn took all the
| steam out of it. Duplicated a lot of functionality and
| none of the esoteric-ness.
| simongray wrote:
| No one uses Boot.
|
| The choice is between Leiningen and deps.edn AKA the
| official Clojure CLI. Personally, I switched to deps.edn
| back in 2020 and haven't looked back. I like that it's
| simpler/does less out of the box and I also use the Git
| dependency feature all the time (you can reference a git
| sha as a dependency, not just Maven coordinates).
|
| Something like 90% of it is just listing dependencies
| (the same packages as it's all just Maven anyway) and for
| the remaining 10% of configuration there's plenty of
| resources available for both. They can also interop to
| some extent.
|
| Other ecosystems have it much worse than Clojure in this
| regard.
| dgb23 wrote:
| If you want a complete, integrated "stack" that stitches
| some of the most common libraries together in a uniform
| structure you might have a look at kit:
|
| https://kit-clj.github.io/
| dgb23 wrote:
| Clojure is not a hobby language.
| taeric wrote:
| I'm intrigued, why do the PMs and such care? (I'm assuming EMs
| is Engineering Manager?)
| gemstones wrote:
| Clojure is really good at self-selecting for people that
| really care about innovation in programming languages. The
| other jobs in a tech company care about innovation in their
| domain. They rarely align.
|
| So for every weird, cool innovation you see, the productivity
| is immediately lost because people equally care about how you
| deal with state on app startup, or routing, or database
| interaction. And since none of those other things move the
| needle much in how you compete in your business domain,
| competitors who are not concerned wind up eclipsing you.
| While you're arguing integrant vs. mount, people are just
| running dotnet new and bikeshedding over things closer to the
| business domain.
|
| PMs/EMs/QAs/etc. may not have technical knowledge, but they
| smell something off about programmers arguing about what
| library to use for routing. Why didn't people complain about
| this at their past jobs? Surely if it was important, it would
| have come up. They just perceive you as having hired a bunch
| of senior people who are incredibly slow relative to their
| past companies. It really breeds resentment.
|
| I have seen clojure-first companies creatively hive off parts
| of their engineering org to have a separate org that is
| allowed to use a different stack. They're not super
| transparent about it to avoid a big exodus of people, but
| I've personally seen it happen more than once.
| fulafel wrote:
| Sometimes with time SW based companies seem to migrate
| towards "easy to hire maintenance devs" style stuff once
| the products mature and slow down. It seems to happen to
| Ruby and Python projects too. But you might not have gotten
| it built in the first place if you started that way.
|
| (Though I don't think Clojure is really "innovation in
| programming languages" stuff, it's a rather straightforward
| Lispy language and has changed much less than eg Java, C#,
| JS in the last 15 years, and is simpler too)
| dgb23 wrote:
| > Clojure is really good at self-selecting for people that
| really care about innovation in programming languages. The
| other jobs in a tech company care about innovation in their
| domain. They rarely align.
|
| To me it seems people typically like Clojure because of its
| simplicity, stability and productivity with the REPL. There
| are innovations in Clojure (its data structures,
| transducers...) but overall it is a pretty conservative and
| minimal language with laser focus on pragmatism.
|
| Also in terms of slowness it seems the opposite is the case
| from my limited knowledge. OS authors and contributors seem
| to be extremely productive and creative. There are some
| notable Clojure shops (see: OP) that have been growing at
| an incredible pace.
|
| Maybe I see this differently because I come from a [insert
| two very popular languages] background where everything
| breaks every couple of months and the culture is severely
| fad driven. To me Clojure is refreshing, calming and more
| powerful on top.
| [deleted]
| eduction wrote:
| This is a reasonable comment, even as a Clojure fan, I think
| this fits with how the community thinks of itself to some
| extent. I can't provide a specific citation but I know there is
| at least one talk (maybe Simple Made Easy but don't quote me
| lol) where Rich Hickey talks about the fact that one reason
| "easy" tools -- which in his view provide fast uptake but more
| problems down the line due to being "complected" in how they
| deal with various concerns of the underlying problem -- are so
| popular is that people who manage programmers (like some of the
| positions you mentioned) want to be able to easily put butts in
| chairs, to readily replace engineers like they are cogs in a
| machine, so they are very willing to make this trade of short
| term ease for long term pain because less training is required
| to get to a near term deliverable.
|
| It's also clear (see Hickey talk Effective Programs, 10 Years
| of Clojure, where he surveys the room) that Clojure programmers
| tend to be senior (real senior not 5 years experience "senior")
| and a little grumpy about the state of the art, opinionated,
| and don't want to be cogs. This may also explain the allergic
| reaction among people who manage programmers/engineers.
| Managers as a rule (especially at certain orgs) tend to want
| people who are more compliant and less free thinking and likely
| to push back.
|
| Anyway I think you make a good point except I disagree about
| its survival long term. I think there's something to be said
| about the value of being more popular among older more seasoned
| programmers vs PMs. How many PMs in the 90s foresaw the rise of
| Linux (vs proprietary unix and Windows), how many go overboard
| on "agile", how many were into ruby on rails before it picked
| up among programmers, etc. Managers tend to be a lagging
| indicator (speaking very broadly).
| munificent wrote:
| My impression is that Clojure (and Lisps in general) are
| about maximizing the productivity of an individual where
| other languages try to maximize the productivity of an entire
| team. There are trade-offs to be made in either direction and
| much of what affects the feel of languages on either side of
| that comes from the choices they make around those trade-
| offs.
| elwell wrote:
| I didn't realize how nice I had it with Clojure until I went
| full-time Java.
| Naomarik wrote:
| I was writing a longer comment and deleted everything after it
| started to look like bragging.
|
| All I'll say is that I'm extremely grateful to Clojure for the
| life I've been able to live and what it's allowed me to
| accomplish. This is truly a language for beating the averages.
| jawadch93 wrote:
| [dead]
| rawoke083600 wrote:
| I've started learning Clojure about a year ago, couldn't say it
| was easy (the fault might be with me and not Clojure)
|
| Clojure has a lot a faults (just look at some of the comments
| here) BUT and it's a BIG BUT for me...
|
| Clojure is SUPER FUN :)
|
| Over the years(15+), I've been coding in PHP (suck it haters),
| Go, Rust,Java,Python AngularJS+, Svelte and I can honestly say
| for me, nothing is more fun that coding in Clojure.
|
| _It 's fun testing a function in "realtime" by just "eval" it on
| the spot. I don't even code "in the REPL" I just use Calva and
| eval inline in VSCode
|
| _Maybe it's cause it's my new toy but it really does bring back
| the "joy of coding" I've been missing in the other languages.
|
| *Learning Clojure became much more easier, once I told myself
| "It's Maps All The Way Down :D" Sure there are stuff like atoms
| that make it possible to code around the "immutability" but that
| is like using a cheat-code to go back to the old ways. Yes there
| are many times when mutable-data-structures are required, but
| while learning, don't grab for them as a first solution !
|
| Anywhoo YMMV but once you get over the warts (many there are),
| much fun and insights awaits :)
| kelseyfrog wrote:
| Clojure user here since 2010(my earliest Clojure project on
| Github), and while I agree with the fun point, the iceberg wart
| for me at this point is the inelegance of the interface
| hierarchy and its structure behind the scenes.
|
| Clojure's forward-facing interface (a hundred functions that
| operate on one data structure) ended up breaking down for me at
| some point and became 10 functions on 10 data structures and
| those data structures became AFn, APersistentSet,
| APersistentMap, APersistentVector, IFn, IPersistentSet,
| IPersistentMap, IPersistentVector, ITransientMap,
| ITransientVector, IndexedSeq, LazySeq, &c, &c, &c.
|
| Maybe I started writing code wrong. Maybe I dived too deep into
| the internals, Maybe it was something else. But at the end,
| there wasn't one data structure, there were dozens and dozens
| each with justifiable differences, but even so, that's not what
| was advertised. It took a decade to reach that point and
| perhaps the vast majority of folks never will.
|
| The sad part is that I know none of it is up for change without
| creating a Clojure2, and that highlights the problem. Why
| should changing the internals need to break backwards
| compatibility? There is one unspeakable reason: the illusion
| wasn't complete and they weren't really internals to begin
| with.
| rawoke083600 wrote:
| Right ! But you still had fun the last decade correct /s ? :P
|
| My "real response" to is, I haven't seen this
| complaint(concern) to this extend that you describe in the
| wild or in my own life. I've definitely not coded in Clojure
| long enough to have seen any of that like you have, thus far
| my experience has been good with 'just' using maps.
|
| I do feel my next "step-up" would be to incorporate something
| like SPEC or Mali to "define/check" the fields/structure of
| said maps.
| yenda wrote:
| Do you have some os projects out there to share where you had
| to do that? Makes me curious, I think the only time I've
| ended up making a specific data structure in clojure was for
| a library for perf reasons. In application code basically
| never.
| [deleted]
| kelseyfrog wrote:
| Specifically it was using GraalVM to interop Clojure on one
| side with React running on GraalJS on the other. It
| definitely pushed the limits of what is or even ought to be
| possible, but at the same time highlighted those very
| issues. I'll be the first to admit that this is an extreme
| edge case, but that doesn't take away from the fact that
| the case is still there.
| lenkite wrote:
| Lets say that someone wants to improve on Clojure and make a
| better functional, immutable LISP! What should they start
| with ? Some things I miss is type support (for easy
| refactoring, auto documentation and performance), (small)
| native compilation, support for mobile platforms and their
| UI's, first-class web-assembly support, real structs and misc
| things like performant implementations for `first`, `last`
| and other clojure functions, light-weight concurrency like
| Go, data-flow analysis and pipelines, etc.
|
| An example of clojure performance issues covered here:
| https://tech.redplanetlabs.com/2020/09/02/clojure-faster/
|
| All that stuff above should be fixed at the language/stdlib
| level.
|
| But what is your take on what needs fixing ? What would have
| been your solution for the N data-structures/ M algo problem
| you mentioned above ?
| kelseyfrog wrote:
| > But what is your take on what needs fixing ?
|
| I appreciate that it's a bit frustrating to have someone
| vaguely identify an area of concern and clarification and
| actionable suggestions are much more valuable.
|
| There's two things. One is that the data structure
| ontology[1] is difficult to internalize because of its
| complexity. When I write Clojure code, I consider the
| capabilities of the data structures being passed to the
| function. I think we have some implicit understanding of
| this early on. You expect the type of such and such to
| support seq-ing or deref-ing or something else. You're
| thinking in terms of capabilities and that's good. But if
| you want to be exacting, at some point you'll have to be
| able to point to an interface or several in the diagram and
| say, "yes, I really do expect something that conforms to
| IPersistentVector or IMeta or something else. In order to
| preserve backwards compatibility, this is more confusing
| than it needs to be. Moreover, at that point, you're not in
| Clojure-land anymore.
|
| My second point is that at this step in the narrative,
| you're reading Java code and the illusion of 100 functions
| is broken. I ask myself, "Why, aren't Clojure data
| structures implemented in terms of protocols?" There's a
| perfectly good way of abstracting functionality that seems
| good enough for users, but not good enough for standard
| library implementers? It feels like the answer is, "We
| don't want to break Clojure1.x and we don't want to deal
| with the Python3 problem." Which is fair, admirable even,
| but it still leaves me left wanting. I think there's a
| simpler, more consistent Clojure hiding in there, waiting
| to be let out.
|
| Apologies for the awkward way this reads; I simply wanted
| to get it out before lunch time.
|
| 1. https://raw.githubusercontent.com/jafingerhut/clojure-
| classe...
| bcrosby95 wrote:
| If you want an easy win, one thing Rich mentioned in a talk
| is - if he had to do Clojure all over again today - he
| would put transducers at the 'bottom'. For data
| transformation this makes the underlying collection type
| largely immaterial.
|
| > real structs
|
| I'm not even sure if value types are conducive towards
| immutable, persistent data structures. I'm certainly
| excited for project Valhalla but I'm not sure if Clojure,
| nor any Clojure-like JVM language, written in an idiomatic
| fashion, would really benefit from it.
|
| > light-weight concurrency like Go
|
| Project loom is already in preview mode. Lightweight
| concurrency is nearly here for any JVM language, and once
| it's fully released I will likely have zero reason to use
| core.async.
|
| > type support
|
| Static typing is A Thing you can choose to do, but I doubt
| you would get many daily Clojure users agreeing that it is
| "better". I think it's different and better in some
| circumstances but not necessarily others. It definitely
| feels trendy these days, sorta like how dynamic typing felt
| trendy 15 years ago.
| fiddlerwoaroof wrote:
| Yes on the type support not really attracting Clojure
| users. If you wanted to enable better refactoring, the
| thing to do would be to take more pages from other lisps
| and use the compiler to add more metadata to the runtime
| (in development mode at least) so that you can get better
| tracking of the language constructs.
| seancorfield wrote:
| I've been programming with Clojure since 2010 and using it in
| production almost as long and I hardly ever care about the
| internal types so I'm really curious as to how you went down
| that "rabbit hole"? What sort of problems were you solving
| that necessitated delving into the implementation details
| behind the abstractions?
|
| I've only needed to dig into that occasionally for a handful
| of specific situations (for example, in next.jdbc, where I
| create a hash map like abstraction over the (mutable)
| ResultSet object from Java -- to paper over some nasty
| interop issues).
| roenxi wrote:
| An interesting complaint. What problem domain(s) do you work
| in? It sounds like you've found something that Clojure isn't
| a great fit for.
|
| The mix of interfaces would be a huge pain if you needed
| their specific behaviours, but in my experience they've never
| mattered and lings like LazySeq just act as performance
| optimisations.
| dack wrote:
| Yeah I think the hype cycle with Clojure looks like this:
|
| Stage 1: Confused by parens/the lispiness. early uncertainty
|
| Stage 2: learn the REPL and library functions and fall in love.
| irrational exuberance
|
| Stage 3: build an unmaintainable mess and can't refactor.
| trough of sorrow
|
| Stage 4: figure out how to decouple appropriately and evolve
| the codebase rather than refactor all the time. live happily
| ever after!
| rawoke083600 wrote:
| Stage5: All other languages and their syntax now looks ugly
| and wrong. I'm mean for heavens sake put the parens on the
| outside ! We are not heathens.
|
| Lol only half joking. It really did surprise me how can
| something I _hated_ some much in the beginning of learning
| Clojure (all the parens) has now become one of the things I
| most adore about the language (all the parens)
| pjmlp wrote:
| ML (via Caml Light), Lisp, Smalltalk and Prolog did it for
| me, each on its own way.
|
| Nowadays I am happy to see a bit of them on the languages I
| actually get to use.
| nickpeterson wrote:
| This is the worldview of all apl developers.
| agumonkey wrote:
| Last time I listed my resume I added "prolog or apl
| please"
| yogthos wrote:
| It's really hard for me to see any justifications for a
| syntax that's not based around s-expressions. The benefits
| of being able to trivially transform any code as data and
| have powerful structural editing facilities outweigh any
| perceived downsides in my experience. I also find that
| s-exps act as a visual diagramming tool making your code
| more scannable because you can visually see the
| relationships between statements by looking at the nesting.
| yogthos wrote:
| I've been working with Clojure for the past decade, and it's
| still the most enjoyable development experience I've had. Once
| you experience using an interactive workflow where you can see
| the results from the code you're writing live, it's really hard
| to go back.
| agumonkey wrote:
| I physically suffer when I go back to systems like django,
| where there's no principled underpinnings, no 'protocol' and
| only a thin way to interact with the system live.
|
| Curse of good languages.
| yogthos wrote:
| indeed
| atdt wrote:
| Can you recommend a good YouTube video that demonstrates
| this? I'm used to writing code incrementally in Python via
| the IPython REPL. I've also used Twisted's Manhole to get a
| REPL inside an already-running Python server process. But I
| believe you're referring to something substantially richer
| than that.
| phforms wrote:
| Same here, started using Clojure pretty much exclusively about
| a year ago and never looked back. It was rough to get to that
| comfortable state where I am now, having to find out how
| Clojure CLI tools work, what Java Classpaths are, how to
| properly set up my editor (Neovim), how to make sense of
| Clojure internals like "seq" and when to use which collection
| type (and when not to care), etc.
|
| But it has also been a fun and liberating experience, after I
| went down the static type route for some years. I feel like
| Clojure just doesn't get in my way and doesn't force me to
| follow a certain style or paradigm; it provides many different
| choices ("providing more" instead of "taking away") and treats
| you like an adult who can make responsible decisions on their
| own.
|
| Although I missed the linguistic art of domain modelling
| through type definitions, spec gave me some of that back and
| even provides stuff like generative testing, which is pretty
| awesome. Of course, it is not meant as a replacement for static
| typing and has a different philosophy (see Rich Hickeys talks
| about it), but for me it is the best of both worlds.
|
| The dynamic development style is something that I experienced
| before through learning Lisp/Scheme and it is also one of the
| thing that I enjoy most about Clojure. Coding "experimental",
| building functions from individual pieces that I iteratively
| design using the REPL as my assistant (which actually means -
| as parent wrote - communicating with it from the editor itself,
| which we mostly do), feels so natural and I would miss it now
| that I am so used to it.
| jjnoakes wrote:
| > treats you like an adult who can make responsible decisions
| on their own
|
| I have to disagree with this characterization. It also seems
| a bit patronizing.
|
| Having more choice can be good in some cases, and having
| fewer choices can be good in other cases. One isn't treating
| you less like an adult than the other.
| munro wrote:
| I could be reading the energy wrong, but damn it looks corporate
| bullshit sucked the life out of Rich
| olah_1 wrote:
| Rich Hickey's talks may outlive Clojure itself.
|
| In some sense, the principles he taught and aimed for were the
| ideal. Clojure today wasn't necessarily the ideal.
|
| I think there could be room for a better Clojure than Clojure, so
| to speak
| danuker wrote:
| Based on my analysis of Rosetta Code samples, Clojure is the
| most popular language with its compactness.
|
| https://danuker.go.ro/programming-languages.html#non-math-ma...
|
| Also, it has a low frequency of bugfix commits (which may or
| may not be related to bugs also). (but it might be the dev
| experience, I have not adjusted for it).
|
| https://danuker.go.ro/frequency-of-bugfix-commits.html
|
| In addition, the JVM gives it great performance, and it has
| actual CPU multithreading (while Python or other scripting
| languages have a GIL). This makes it relevant in today's
| environment where Moore's law continues through number of
| cores.
|
| Therefore I don't think Clojure will die too soon.
| brundolf wrote:
| One of the things that stands out to me in this video is seeing
| devs who are much older than the average dev I encounter, who
| have continued to grow deeper in their skills and form deeper
| insights, sharing some of those insights. It's something I don't
| get to see very often and it's encouraging
| college_physics wrote:
| Clojure fans seem quite taken to hyperbole. If the language is
| such a "joy", "ultra-productive" etc I would have expected after
| such a long period of existence some major open source project to
| be showing off what the language attributes allow you to do.
|
| Happy to stand corrected if there is such a slam-dunk showcase
| that I've missed, I am actually interested to dig into clojure,
| if nothing else as a way to deepen my understanding of functional
| programming.
| maxfurman wrote:
| There is something about the language and/or community that
| leads folks to build their own X instead of collaborating on a
| common open-source version of X.
|
| Perhaps the lisp learning curve is high enough to dissuade
| those who want to contribute to a project but don't yet know
| Clojure?
| doubleg wrote:
| To name a few: https://github.com/xtdb/xtdb,
| https://github.com/nextjournal/clerk,
| https://github.com/penpot/penpot,
| https://github.com/metabase/metabase
| college_physics wrote:
| Thanks. I don't know to what extend its "better-because-of-
| clojure" but I also found overtone
| https://github.com/overtone/overtone which should be good fun
| (though the underlying synthesizer is supercollider/C++).
| runevault wrote:
| Overtone is interesting because the guy who really kicked
| it off went on to make Sonic Pi which is Ruby based[1].
|
| [1] - https://sonic-pi.net/
| jgoodhcg wrote:
| Clerk is amazing!
| heyzk wrote:
| I hadn't really though about it until your comment, but
| Metabase really is a joy to work with.
| mvc wrote:
| I guess it's impossible to know what you've seen before and
| dismissed as not having sufficient
| features/attributes/popularity. Or what types of project would
| cause you to dig in but here are a few innovative projects
| using clojure that represent a fairly diverse set of interests.
|
| - https://github.com/overtone/overtone - https://xtdb.com/ -
| https://github.com/kennytilton/matrix -
| https://github.com/metasoarous/oz
| fulafel wrote:
| Clojure is associated with the JVM platform, Java and Scala and
| Kotlin end user open source apps are also underrepresented
| relative to dev population. There are lots of OS Clojure
| projects but they are mostly tooling, libs, databases, etc.
| There are a lot of business and data stuff most of which isn't
| open source.
|
| Come to think of it are there many TypeScript open source apps
| either?
| jgoodhcg wrote:
| I think the Roam Research style backlinked knowledge management
| apps are directly enabled by datascript.
|
| Two "copy cats" (not meant to be derogatory) of Roam that are
| open source are: https://github.com/logseq/logseq
| https://github.com/athensresearch/athens
|
| The underlying in memory datalog style database that can run in
| the browser that enables these apps
| https://github.com/tonsky/datascript
| orestis wrote:
| Obligatory shout out to Babashka [0] which is interpreted
| Clojure. You just download a simple binary and you can get going.
| Widely used for quick-running scripts, with a lot of batteries
| included.
|
| [0]: https://babashka.org/
| BaculumMeumEst wrote:
| I love Clojure the language but I've never seen a more fragmented
| ecosystem.
|
| There seems to be a pattern in the language of "a problem emerges
| > a community solution gains traction > Cognitect develops their
| own solution but its weird and undocumented", like deps.edn over
| leiningen, spec over malli, pedestal over ring, etc.
|
| Many prominent clojurists recommend deps.edn over leiningen and
| socket repl over nrepl, but I've seen very little guidance on how
| either actually work or how to use them.
|
| Spec seems kind of weird and not well thought out either.
|
| And Clojure CLI tools also seem like a total shitshow compared to
| go or rust's tooling.
|
| As a result working with Clojure feels puzzling and unpleasant,
| and I feel hesitant to use any community library or project in
| the language.
| djblue wrote:
| I think most programming communities experience fragmentation
| as they grow. I would say the javascript ecosystem has had an
| order of magnitude more fragmentation at every layer: package
| management, server, client, module specification. IMO this is
| the cost of progress.
| adlpz wrote:
| True, but the JS community is _huge_. Sure, not by its own
| merit, but because of browsers. Still, can afford to be
| fragmented.
|
| For smaller languages like Clojure the consequences are way
| worse.
| bcrosby95 wrote:
| I think the docs are pretty good, but the main "problem" is the
| same problem as anything else in Clojure: you have a lot of
| options, and maybe even documentation, but not a lot of
| guidance. Which I don't think the community _broadly_ views as
| much of a problem, but it does make it difficult for new people
| getting into the language.
|
| There are some within the community working on this but unless
| it becomes a blessed solution it can still be kinda difficult
| for new developers to onramp into the language.
|
| E.g. compared to something like Elixir, the road is much more
| arduous with Clojure.
|
| The problem with things like spec is it kills interest in other
| libraries solving the same problem. Note that Malli released
| _after_ spec, and after spec all but killed off a few spec-like
| libraries, my general observation seems to be that many in the
| community have moved on from spec.
| bm3719 wrote:
| Been using Clojure professionally for 9+ years now and while
| I'm thankful that I can make a living writing the language and
| using Emacs all day, I've found these points to be spot on.
|
| These issues have added noise/confusion to what used to be a
| much simpler ramp-up for new developers. For those who've been
| around for awhile, the overall experience definitely felt
| cleaner previously, with more obvious best paths. While it's
| hard to argue against more options, the effect on the ground is
| that it's also needlessly divided the already small community a
| bit too.
| kbuchanan wrote:
| I think the bottom line with Clojure is it's not an ecosystem
| well-suited for non-veteran programmers. For as simple as the
| language is, effectively using Paredit, navigating partially
| documented libraries, diving into source code to see how things
| interact--it's tough as a new developer. I don't believe
| Clojure is overtly hostile to newcomers; it's just crafted by
| veterans, for veterans. And this is the result.
| adlpz wrote:
| I don't agree.
|
| I consider myself something akin to a veteran. I've been
| coding for over two decades. Not sure if that qualifies, but
| anyway.
|
| My point is: it's been with experience that I've come to
| value ergonomics the most.
|
| And that for me includes having a thriving and focused
| ecosystem, extensive industry penetration, good and stable
| tooling, lots of well known codebases learn from, etc.
|
| It was when I was young and inexperienced that I didn't see
| those as the important bits. I was happy hacking on any half
| assed editor exploring undocumented APIs and trying to
| discover patterns and idioms by myself. I was happy to
| _waste_ time.
|
| I'm not anymore. That's why, while a _love_ Clojure as a
| language, I don 't really use it that much nowadays.
|
| Too much friction.
| garbagecoder wrote:
| If only time served makes you a veteran, I guess I'm one
| too, but a lot of it was mediocre time.
|
| I still like hacking on things, but only on hobby projects.
| When it has something to do with work, I agree. Clojure
| reminds me of why I liked coding in the first place and I
| like the way LISP-type languages make me think differently
| about what I'm doing.
|
| But "in the real world," yeah, I don't want those things. I
| want something I can build and maintain and be done.
| eduction wrote:
| I think your pattern is right _except_ for "its weird and
| undocumented" - I have found the maintainers are superb at docs
| -
|
| e.g. deps.edn -
|
| there is a "Guide" https://clojure.org/guides/deps_and_cli
|
| there is a "Getting Started"
| https://clojure.org/guides/getting_started (it's branded as an
| overall Clojure getting started but the core of deps is just
| the clj/clojure command line tool you would use to install
| clojure)
|
| there is a deep "Reference" with a "Rationale"
| https://clojure.org/reference/deps_and_cli
|
| spec
|
| Spec Guide - https://clojure.org/guides/spec
|
| Spec Rationale https://clojure.org/about/spec
|
| Spec API reference https://clojure.github.io/spec.alpha/
|
| Spec resources (brief)
| https://clojure.org/community/resources#spec
|
| (Rich Hickey also gave a couple of spec talks that are on
| YouTube)
|
| Also, for my money, deps.edn is way more composable than lein,
| does not feel weird to me at all. Ditto for spec vs prismatic
| schema which preceded it. I think the latter case is one where
| people were more miffed that the official solution displaced a
| community beloved tool, but to me it genuinely seems really
| well thought through. There are some flaws discussed in the
| Rich Hickey talk "Maybe Not" which led to an experimental
| (still beta) spec2 but spec1 I still find miles ahead of what's
| available for the languages I've worked with.
| roenxi wrote:
| "Superb" is not the word for deps.edn documentation. It is
| certainly documented but the gap between most Clojure
| documentation and the deps.edn documentation page is big. I
| suspect Rich wrote most of it but left the deps.edn page to
| someone else.The deps pages have a knack for includng pages
| of waffle that doesn't help to solve the current problem.
|
| If a newbie is trying to debug {:deps
| {ring/ring-devel {:mvn/version "1.9.6"}} {ring/ring-
| core {:mvn/version "1.9.6"}}}
|
| => Error building classpath. Error reading edn. Map literal
| must contain an even number of forms
|
| They have to notice that while they got 80% of their maps
| right, the file itself if a map with 3 forms. This is
| compounded by the fact that there are no examples of a multi-
| dependency project in the getting started page! If you know
| Clojure, this is an easy puzzle. For rookies, they didn't use
| (map) so the error message will probably trick some percent
| of them.
|
| I don't think the deps documentation has been validated to
| provide what people actually want to know. Technically it is
| probably thorough, but "Superb" is a high bar it does not
| reach.
|
| Probably the proper approach is learning deps by copying
| other people. Trying to learn it from the docs didn't work
| for me (it did for the rest of Clojure, so that was an
| unpleasant change).
| puredanger wrote:
| These are useful comments and issues are welcome at
| https://github.com/clojure/clojure-site/issues
| e12e wrote:
| Out of curiosity - what is the correct form in this case?
|
| Ed: I'm guessing a key => list of deps, maybe?
| grumpyprole wrote:
| I think you might be asking for a type :)
| jdminhbg wrote:
| Not really. This is a syntactic error, not a type error.
|
| To expand, this is the equivalent of something like {"a":
| 1, "b":}. The type checker in something like Typescript
| wouldn't ever come into play, because it's not legal
| syntax to begin with.
| rch wrote:
| Excellent doc references, and FWIW I share your perspective
| on the tools.
| dgb23 wrote:
| > deps.edn
|
| Deps is well documented.
|
| The issue I personally found is that I needed to look at a
| bunch of OS project's deps.edn to see how people commonly
| structure things. Other than that it is a simple tool.
|
| > socket repl over nrepl
|
| I personally use Calva (VSCode) which just starts an nrepl
| based on deps.edn. When writing babashka scripts I start the
| repl manually and connect to it. Very pleasant experience so
| far.
|
| > Spec seems kind of weird and not well thought out either.
|
| I didn't like it at first, but once I got that everything is
| bottom up I had an AHA moment. Function specs and
| instrumentation are very powerful. Conform is basically a
| parser, which can give you a lot of leverage.
|
| What bothers me about spec is that it is still not released
| though.
| BaculumMeumEst wrote:
| > Deps is well documented.
|
| > The issue I personally found is that I needed to look at a
| bunch of OS project's deps.edn to see how people commonly
| structure things. Other than that it is a simple tool.
|
| This seems like a contradiction, because if it was well
| documented you wouldn't need to look at other people's
| configs to see how to use it.
|
| My experience with deps.edn is that every time I start a
| project and make a deps.edn file, I immediately draw a blank
| and don't know how to structure it, so I open ones from other
| projects to start lifting stuff out of them.
|
| I still don't know how to reliably configure a project to use
| nrepl or socket repl without just using an editor plugin. I
| definitely have no idea how to use those in conjunction with
| a tool like reveal.
|
| To me, none of that is simple. Simple would be like Emacs'
| use-package. With that I know how to add dependencies,
| specify keybinds, and do initialization and configuration off
| the top of my head knowing only the name of a package I want
| to use. And it has really nice documentation with tons of
| examples.
|
| https://github.com/jwiegley/use-package
| sokoloff wrote:
| The C language is extremely well-documented. It's still
| helpful to see other people's C code to understand
| common/useful patterns.
| BaculumMeumEst wrote:
| I don't know. I saw tutorials mixing clj -A, -X and -M
| flags, but what's the difference between them? When do I
| use each? What's the -r flag do and how do I use it? How
| do I update my dependencies? How do I build a jar and
| deploy it?
|
| It just always felt like I was running into things that
| felt basic and the docs didn't have an answer for them. I
| would see so many elaborate deps.edn files in people's
| configs and when I tried to look up how they worked I
| couldn't find anything.
| ReleaseCandidat wrote:
| > I saw tutorials mixing clj -A, -X and -M flags, but
| what's the difference between them?
|
| That depends how you define your build targets (called
| aliases) in deps.edn. And there is also -T to call
| (public) functions in a namespace (file/program), e.g.
| when using build.clj - that's for building your jar.
|
| -X calls a function that you can define using :exec-fn,
| :exec-args has it's arguments (usually a map) -M calls
| the main function ('executes a program', if you will),
| it's 'normal' (command-line) arguments are passed using
| :main-opts
|
| And btw. `clj` is just a wrapper around `clojure` that
| runs `clojure` in rlwrap. No need to use this if you do
| not use the REPL.
|
| Here is a (big) template I've just finished yesterday:
| deps.edn: https://github.com/Release-Candidate/Clojure-
| Template/blob/m...
|
| and it's usage: https://github.com/Release-
| Candidate/Clojure-Template#build-...
|
| build.clj - build a jar and run mkdocs
| https://github.com/Release-Candidate/Clojure-
| Template/blob/m...
| wirrbel wrote:
| Deps.edn is a bit strange but build.Clj was the thing that
| really felt like Setup.py writing in 2010
| redpenguin101 wrote:
| > My experience with deps.edn is that every time I start a
| project and make a deps.edn file, I immediately draw a
| blank and don't know how to structure it, so I open ones
| from other projects to start lifting stuff out of them.
|
| My new project deps file is always literally "{}". I love
| that that's all I need to do to start doing stuff. I add a
| couple libraries as needed. Maybe at some point an alias or
| two.
| billfruit wrote:
| Deps may be well documented, but lots of introductory
| material seems to use lein. Having two systems is more
| confusing.
| seancorfield wrote:
| Because a decade ago there was only Leiningen -- so all the
| books and tutorials (and videos) created in the early days
| of Clojure had to use it. At work, we started with lein
| (back in 2011 for our production code), then we switched
| completely to Boot in 2015, and then we switched completely
| to deps.edn in 2018. build.clj (tools.build) is a "recent"
| addition (less than two years since the very first 0.0.1
| commit).
|
| More and more introductory material is appearing these days
| featuring deps.edn but given there was a decade of
| Leiningen usage out there before deps.edn even appeared,
| the current state of affairs shouldn't surprise anyone.
|
| As for more than one system, lots of languages have that
| situation: consider make -> ant -> maven -> gradle etc.
| puredanger wrote:
| How do we ever move the world forward if we are only
| allowed to have one thing?
| sokoloff wrote:
| I have only used Clojure for side/hobby development, which
| admittedly makes this a shallow observation.
|
| I've found working with Clojure to be extremely pleasant/joyous
| and when I've had the need to bring in someone else's code,
| it's been an overwhelmingly good experience, even if the
| library is 5 years old and untouched for the last 4. (Find a
| random node package that's last changed 4 years ago and it
| might as well be toxic waste. Find a clj lib in that condition
| and it's probably going to work smoothly.)
|
| I do agree the prevalence of lots of examples of leiningen and
| fewer examples using tools.deps/deps.edn and clojure cli makes
| it hard for me, as a beginner, to know the "right" patterns to
| use.
| logistark wrote:
| I have the feeling that after Nubank bought Cognitech, Clojure
| has gone to stagnation. I mean, i feel that promoting and
| improving Clojure is no longer a priority. And another think that
| stinks me everytime Cognitech talks about Clojure they have to
| bring to the table Datomic. They tried to push Datomic on my
| company long time ago when they do some consultancy job at my
| company. You can skip all the talk, because is all about how good
| Clojure is and that is. No any eta about future features,
| improvements and fix problems of current Clojure users.
|
| Lot of open source contributors have leave the community, because
| there is any plan on Clojure. I guess that Rick Hickey is happy
| with Clojure as it is now, and this is the way is going to stay.
| And still no Java 8 support for CompletableFuture, lambdas
| interface, Stream api, java.time, no pattern matching, java
| records, this group feels like a group of old programmers stuck
| at Java 6 that cannot move forward.
| Zak wrote:
| It seems to me that these things are a big deal if you're doing
| a lot of JVM interop and not so much if you're primarily using
| Clojure-native libraries.
|
| Clojure has futures, lambdas, streams, a community-maintained
| java.time library, core.match, and Clojure records. I'm sure
| there would be benefits to adopting the newer JVM-native
| equivalents, but I'm not as sure they're worth the costs.
| mrichman wrote:
| I tried getting into Clojure (I have an undergrad Lisp
| background). I just couldn't become productive, and the tooling
| seems fragmented. Been moving many of my workloads from Go to
| Rust.
| agumonkey wrote:
| Can't say I'm not happy to hear Rich Hickey talk again.
___________________________________________________________________
(page generated 2023-02-13 23:00 UTC)