[HN Gopher] Clojure 1.11 is now available
___________________________________________________________________
Clojure 1.11 is now available
Author : simongray
Score : 162 points
Date : 2022-03-22 16:35 UTC (6 hours ago)
(HTM) web link (clojure.org)
(TXT) w3m dump (clojure.org)
| timgilbert wrote:
| Juxt had a recent blog post covering the new Clojure (iteration)
| function in depth, which is useful for abstracting over sequences
| that require some state management to access, such as a paginated
| API.
|
| https://www.juxt.pro/blog/new-clojure-iteration
| lbj wrote:
| The contributor list is shrinking :(
| fogus wrote:
| The contributor list is append-only. :)
| jjtheblunt wrote:
| that's a pretty great comment!
| mswift42 wrote:
| The contributor list is expanding :)
| iLemming wrote:
| The contributor list ain't list at all. It's an immutable
| collection.
|
| I am so happy to see that not one but a couple of those
| names are my colleagues. They send patches to clojure.core.
| I send comments to HN :). I'm proud of them, I hope they
| proud of me too.
| Decabytes wrote:
| Glad to see Clojure continuing to improve. Racket borrows a lot
| from Clojure^1,2,3 so its success fuels ours as well. With the
| other post on here about Java 18 including Pattern Matching, I'm
| glad that good ideas continue to cross pollinate between
| different languages. Programming is still a young field compared
| to other professions, and there is still a lot of good things
| left to discover!
|
| 1. https://docs.racket-lang.org/collections/index.html 2.
| https://docs.racket-lang.org/seq/index.html 3.
| https://docs.racket-lang.org/threading/index.html
| zitterbewegung wrote:
| A lot of clojure has been borrowing from main stream
| programming languages that lisp users don't think of using at
| all which is great.
| agumonkey wrote:
| Interesting to see racket and clojure cross pollinating. I
| wonder what other non mainstream language is part of this game
| (julia, factor, ..)
| kbuchanan wrote:
| It doesn't just keep on improving, but stays backwards
| compatible with every new release!
| silver-arrow wrote:
| So thankful to be programming in Clojure the past few years.
| Thank you, Clojure Team, for all you do!
|
| My favorite things about using Clojure: 1. Runs on the JVM.
| Battle tested, tons of libraries, and well engineered. 2.
| Immutable Data Structures. I wouldn't want to live without this
| safety ever again. 3. LISP syntax - so simple to remember and
| just basically code functions! I also find reading Clojure code
| very simple vs other procedural languages. 4. REPL development.
| 5. Transducers - not unique to Clojure, but just love them so
| listed it.
|
| Great language.
| jakebasile wrote:
| Much love to all the people that make Clojure such a wonderful
| language to use.
|
| I'm particularly happy with the new keyword args semantics, which
| solves a long standing pain point.
| buzzwords wrote:
| I do wonder what has to happen for greater adoption of Clojure.
| jdminhbg wrote:
| Maybe a fuller understanding of its applicability to
| discussions like this one from yesterday?
| https://news.ycombinator.com/item?id=30753127
| phtrivier wrote:
| - ease the onboarding. Every few months I try to give clojure
| another shot, and every few months _some_ part of the setup has
| changed and / or is broken.
|
| - compile to small binaries that run fast. I get what the
| langage gets from the JVM, but those 5,10 seconds I get before
| _anything_ runs, even after I had everything compiled ?
|
| - show me an example of how having 'spec' is going to help me
| refactor the code that I got wrong the first time, as easily as
| what a proto-ML-like static type checker does. It's not a
| question of "types are bad vs types are good thing". It's a
| question of "this property was called 'name', but now I need it
| to be 'names', and I really need to know every possible place
| of my code base that uses it so that I can recursively change
| all code paths to handle the fact that it's a list, now." I
| read the spec doc a dozen times, and I don't think it does help
| in this simplest of simple case.
|
| Also, I make typos all the time, and caml / typescript / rust
| catch them before I waste a run cycle. Dynamic langages can't
| know if 'names' and 'name' coexist - Let me tell the compiler
| what I mean once.
|
| - promote an "obvious" gui lib. It's not obvious what I need to
| use to do an hello world window (but that's really not specific
| to clojure, in all fairness...)
| phtrivier wrote:
| Also, about the 'name' -> 'names' thing ; I get that maybe
| the idea should be that I should keep the 'name' property
| around and just accrete the 'names' thing, and API should be
| immutable and all, but, just, 'No'.
| [deleted]
| jdminhbg wrote:
| > show me an example of how having 'spec' is going to help me
| refactor the code that I got wrong the first time, as easily
| as what a proto-ML-like static type checker does. It's not a
| question of "types are bad vs types are good thing". It's a
| question of "this property was called 'name', but now I need
| it to be 'names', and I really need to know every possible
| place of my code base that uses it so that I can recursively
| change all code paths to handle the fact that it's a list,
| now." I read the spec doc a dozen times, and I don't think it
| does help in this simplest of simple case.
|
| For this, I think the way to go is to use `fdef` to annotate
| the arguments to each function. This is a lot more explicit
| keyboard-typing on the programmer's part, but then so is a
| statically-typed language.
|
| Where I think Clojure will still come up short is in tooling
| to support finding each reference in a better way than
| grepping your project for `:user/name`. All the information
| you need is in there, as you can see from this proof-of-
| concept tool[0], but it's not implemented seamlessly into the
| workflow.
|
| [0]: https://github.com/clj-kondo/inspector
| nanomonkey wrote:
| GraalVM has made creating Clojure binaries with quick launch
| times much more possible. I suggest checking out babashka
| (Closure bash scripting) as an example and as a means.
| amelius wrote:
| Does that also work on embedded platforms with limited
| resources?
| [deleted]
| iLemming wrote:
| Nothing. It is still growing. Slowly, steadily, systematically.
| Clojure evolves strategically, not tactically. Besides, no
| matter what happens - Clojure would stay a niche language.
| There are certain benefits to that. Those who tie business
| worth and technical advantages to language popularity, often
| ignore them.
|
| My unit (just like many other Clojure teams) has been building
| numerous solutions for many years now. Our employer loves us
| very much. As long as we keep making money; maintain our
| codebase aiming for expansion rather than [quartely] renovation
| - investors won't care what we use to achieve the results. If
| other companies prefer hiring new devs and rebuilding
| everything every two years - well, that's their money.
| newlisp wrote:
| Companies seeing some value in it and pushing it but that won't
| happen. Most companies today want static typing and don't want
| to rely on discipline for stuff like maintaining
| documentation/more tests and having them up to date.
|
| If it's true that engineers leave after one/two years then I
| can't blame them. Whatever cost static typing brings, it's
| worth it to them. Just look at how typescript usage has
| exploded.
| mixedCase wrote:
| I would never use it under any circumstance of my choosing,
| since it's a dynamically typed language and I don't have any
| further need for any more of those at the moment; in fact only
| looking to cut down on my usage of them.
|
| But from my experience working with it on real projects:
|
| - Good tutorials, combined with library and build tooling
| integration for usage with GraalVM. Startup times make it a
| horrible fit for anything other than long-lived daemons.
|
| - Speaking of build systems: more ecosystem coalescing around
| tools.deps, there's a lot of resources around Leiningen, not
| too many around the blessed native tooling (I know, I know,
| it's fairly new for Clojure standards, but it is a problem).
|
| - More and better linters for popular libraries. Without good
| types, you need something to guide you when you're misusing an
| API; the team where I worked with Clojure lost a lot of time
| getting Reagent patterns wrong.
|
| My final complaint is something that I don't think can't ever
| be fixed without undoing what makes Clojure, Clojure:
|
| REPL-driven development combined with dynamic typing, in the
| same way as its cousin: debugger-driven development, often
| leads to write-only code that works but good luck using it or
| modifying it if you don't have good automated tests to tell you
| how it's supposed to be used and more importantly how it's not.
|
| It doesn't help that tests are de-emphasized by the community
| precisely because of REPL-driven development. "Just put it on
| the REPL and see what it does" is not a good way of reasoning
| about code, and makes it easy and convenient to just pile on
| more hacks that may or may not break something instead of
| promoting understanding. "Just write good code and have
| discipline, you're doomed if you can't do that anyway" does not
| excuse that other languages have radically different tools and
| practices that lead to far fewer footguns.
| Jonovono wrote:
| ..... you realise clojure has one of the most powerful ways
| to 'type' your language? Like 100x more powerful than the
| typescript or whatever type language you are using now ;p
|
| https://www.youtube.com/watch?v=VNTQ-M_uSo8
| mixedCase wrote:
| Clojure.spec is runtime analysis, not static analysis. They
| aren't solutions in the same space.
| iLemming wrote:
| When I was working for a fintech company, we built a
| suite of specs for a ledger. Based on those specs, we
| could generate data. And it wasn't just some set of
| key/value pairs with completely randomized numbers. It
| would generate "a proper" ledger, where every number in a
| transaction depends on other transactions.
|
| We used that generated data to render UI locally and on
| the non-prod environments.
|
| Using the same specs we built data validators, we re-used
| the specs to validate data in the input fields in the UI,
| which is totally bonkers. How the heck do you achieve
| code re-use between completely incompatible ecosystems -
| in our case, JVM and Javascript? Even Nodejs doesn't
| always let you re-use code between the backend and the
| front. Clojure does.
|
| Using the same specs, we've built property-
| based/generative tests.
|
| Before, I never experienced the joy of creating such
| robust, predictable, and reliable software with any other
| (statically typed or otherwise) language.
|
| I'm not saying you cannot build a similar thing (or even
| better) with Scala or Haskell (or some other PL). The
| simplicity of how Clojure allows you to write stuff like
| that - is just incomparable.
|
| Once again, I'd repeat the point I made in the parent
| thread: Clojure has an excellent price/quality ratio for
| building software. ROI from hiring Clojure devs, in many
| cases notably higher.
| mixedCase wrote:
| I'm glad you found great uses for clojure.spec. We need
| more tools like it.
|
| If you ever find yourself writing TypeScript I'd
| recommend you try io-ts, which fullfills the same role as
| clojure.spec but is also able to auto-generate types from
| the runtime codecs, which you can then use in your
| functions to make sure they are only used with data that
| passed decoding. Not having to rely on discipline or
| "pinky promising" that you have decoded data is a huge
| boon when changing code later, or understanding the full
| scope of a function.
|
| This isn't unique of course to Clojure or TypeScript as
| you mentioned, but there aren't too many good libraries
| built on the concept, and it doesn't work well in all
| languages.
|
| > How the heck do you achieve code re-use between
| completely incompatible ecosystems - in our case, JVM and
| Javascript?
|
| Just to point it out, Clojure does this the same as
| everyone else and has the same issue: So long as you
| don't call runtime-specific non-portable functionality,
| you should be good. Plenty of Clojure libraries targeting
| the JVM do not work on ClojureScript and viceversa.
|
| > Clojure has an excellent price/quality ratio for
| building software
|
| I agree that Clojure is fairly competitive, so long as
| we're talking initially building software. I just find it
| that specially once maintenance, rapid requirement
| changes, junior engineers, and staff rotation is taken
| into account, either developer productivity or the
| robustness of the software falls off a cliff.
| iLemming wrote:
| > either developer productivity or the robustness of the
| software falls off a cliff.
|
| So, I once worked on a project for the retail industry.
| And the requirement changes weren't just crazy, sometimes
| they felt legit grotesque. Like for example: "hey guys,
| we have a new program - everyone in Nebraska and Ohio
| gets 20%, except these particular vendors. The discount
| should work only for their customers if they are buying
| these specific items. We're going to need to unveil this
| in four days. Get to work." And then on the day of the
| release: "oh, remember about specific items? They want to
| expand it to a specific category of items. Can you make a
| quick change?" An hour later: "actually, we need to keep
| both, marketing thinks we need to A/B test this..."
|
| And it was like that all the time. We had numerous
| discussions within the team, each of us had rich
| experience working with multiple other languages before.
| I'm not gonna lie - a few times we've said: "if we had a
| static type system...", but in the end, we all agreed -
| it would've been challenging to maintain the system the
| way we did if we had to use something else than Clojure.
|
| In any case, all this remains a personal opinion. Yes,
| Clojure isn't perfect, but right now, it's quite suitable
| for my needs.
| mattmein wrote:
| >> other languages have radically different tools and
| practices that lead to far fewer footguns
|
| Can you share any examples of these different tools and
| practices?
| mixedCase wrote:
| "Advanced" (read: decades old) type systems. They provide
| tools like algebraic data types, generics, interfaces, row
| polymorphism and many others, but just those four allow
| expressing a gargantuan amount of invariants in the type
| system without sacrificing flexibility. Invariants that can
| be proven once and be maintained throughout years of code
| churn without repetitive runtime checks, heavy discipline
| or overly repetitive automated tests that attempt to poorly
| reimplement a type system.
|
| They can be used not only as a way to let the compiler help
| you out in not making mistakes but also as an exploratory
| tool to test out many edge cases with quick feedback and as
| an informational aid to help quickly introduce new
| developers into a codebase with its own business domain
| explained in a language that allows conveying "this is
| possible" and "this isn't possible" much more quickly than
| reading tons of procedural code until the reader
| comprehends all the implicit rules laid down by the
| program's behavior.
| iLemming wrote:
| Well, respectfully (while not disagreeing with you), I
| have to say that you seem to live in some idealistic
| utopia of software crafting. Between the crazy world of
| gazillion lines of shitty Python or Javascript, and some
| incredible proof assistants, I think Clojure finds itself
| in a quite pragmatic, practical, and cozy niche.
|
| Notably, Clojure "speaks money". Money necessitates
| reliability and requires defect-free software. At the
| same time, modern, digitized money management desires
| flexibility and efficiency in fixing bugs and adding new
| features; Clojure very often fits perfectly for it.
|
| That is why it is so prevalent within fintech startups.
| If someone pays you to play around with advanced type
| systems, and you love that, what can I say? You are a
| lucky one. I get paid to build something that works. I'm
| not a zealot; I use Clojure because it makes sense (for
| me). But some people prefer Python and Javascript. And
| that's fine.
| mixedCase wrote:
| I believe fintech is mostly a functional hub. There's an
| above average amount of Haskell, F#, and Scala in it.
| Most of the Clojure influence I believe comes from Nubank
| initially starting out as a Clojure shop IIRC.
|
| Unfortunately I also happen to not get paid to play
| around with languages, although I'm open to such a
| position if you know of any available one. I get paid to
| write robust software and to work with engineers that
| don't always have 10+ years of experience. I get paid to
| deal with requirements that change every bloody week
| because we have quick customer feedback, customers that
| are very vocal about wanting things a certain way and
| highly intolerant of software crapping the bed when they
| go and try their "super normal, and expectable" extreme
| edge case.
|
| I've dealt with those cases across many languages across
| the years, and you could easily guess that I would be
| very desperate for the money if you find me in another
| job working in a dynamic language dealing with constant
| changes.
|
| By the way, it's okay if you're not familiar with the
| concepts I brought up by name, but if you have worked
| with Rust, TypeScript, Haskell, Scala, Kotlin,
| PureScript, Elm, F#, Swift or one of many others, you're
| probably familiar with them. They're everyday tools to
| programmers using those languages, not some strange
| academic tool.
| lukashrb wrote:
| > I get paid to deal with requirements that change every
| bloody week because we have quick customer feedback
|
| In my experience this is something where clojure is
| exceptionally good at.
| iLemming wrote:
| Yep, just like I said in the adjacent thread:
| https://news.ycombinator.com/item?id=30771964
| iLemming wrote:
| >I get paid to write robust software and to work with
| engineers that don't always have 10+ years of experience.
| ... > I've dealt with those cases across many languages
| across the years
|
| I'm not trying to denigrate your experience, and I'm not
| pretending that we work in different industries and deal
| with very dissimilar problems. But if anything I learned
| from the years of writing software - there are no silver
| bullets. Every single tool has cons and pros. You can't
| just look at any instrument, framework, library, language
| through a tiny keyhole and make assumptions. And I'm not
| saying you have. Perhaps you have rich experience using
| Clojure that led you to the conclusions you made. From my
| perspective - I have the opposite of that. And again,
| it's not because I have not seen what you have. Clojure,
| in my opinion, compensates for the lack of static typing
| with a plethora of other features. Features that many
| other languages can't offer but are essential for me.
| joshlemer wrote:
| If you have ideas on how to improve Clojure adoption, there's a
| #growth channel on the Clojurian slack server.
| pjmlp wrote:
| Nice to see it keeping to improve.
|
| Which happens to be the favourite alternative JVM language from
| Brian Goetz,
|
| https://youtu.be/GedrGWu16_I
| brtmr wrote:
| Sweet, variadic maps sound really useful, I am always having to
| take a moment when mixing functions that take keyword arguments
| vs. option maps. Also, some of those functions added to core show
| up in my code as convenience functions - Glad I can now just make
| use of core.
| jdminhbg wrote:
| I definitely have random-uuid defined in a half-dozen of my own
| projects that can go away now.
___________________________________________________________________
(page generated 2022-03-22 23:01 UTC)