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

Clojure 1.13 adds support for checked keys

clojure.org

Post reply on HN
Print view View original

11–20 of 50 posts

Re: Clojure 1.13 adds support for checked keys

#11

Post by embedding-shape »

swannodette wrote: post #10
moomin wrote: post #7

This is actually great, and I predict that fans of nil-punning will rapidly discover the joys of actually having errors trigger where the error was introduced rather than propagating through the program. Any news on ClojureScript gaining the feature?

Working on it :)

Amazing! What are the most interesting areas for ClojureScript in the future, if you don't mind me asking for some casual semi-serious prediction?

Thanks for everything you've done for Clojure and ClojureScript, I'd surely have dropped programming as a whole if I didn't discover Clojure and ClojureScript at the time I did.

Re: Clojure 1.13 adds support for checked keys

#13

Post by fnordsensei »

moomin wrote: post #7

This is actually great, and I predict that fans of nil-punning will rapidly discover the joys of actually having errors trigger where the error was introduced rather than propagating through the program. Any news on ClojureScript gaining the feature?

Well, kind of. This is the kind of problem that you might throw schemas (eg. Malli) at pre 1.13.

It’ll be nice to have it at hand in the base language though.

Re: Clojure 1.13 adds support for checked keys

#15

Post by swannodette »

embedding-shape wrote: post #11
swannodette wrote: post #10

Earlier quoted context omitted.

Working on it :)

Amazing! What are the most interesting areas for ClojureScript in the future, if you don't mind me asking for some casual semi-serious prediction? Thanks for everything you've done for Clojure and ClojureScript, I'd surely have dropped programming as a whole if I didn't discover Clojure and ClojureScript at the time I did.

Honestly what's mostly at the forefront of my mind is greatly improving the documentation around ClojureScript as well as our fork of Google Closure Library (GCL). At work we've switched to DataStar (a single JS include) and coupled that with ClojureScript/GCL - we no longer rely on anything from NPM, to call this a simplification would be a gross understatement. Bundle size is 30K gzipped and we spend no time thinking about our build or JS tooling/dependency tomfoolery.

So less about ClojureScript specifically, and more generally how I think we're well situated for people looking for a way out. The current mainstream practice dead end is bigger than the one that made React (also originally just a script tag include) appealing to me back in 2013. There are of course many ways forward that don't involve CLJS, but I think ClojureScript/GCL and the new crop of NPM-dep free pure CLJS solutions like Replicant are well situated for folks who can see that accepted practices are not delivering enough value even with AI assistance.

Re: Clojure 1.13 adds support for checked keys

#16

Post by akkad33 »

moomin wrote: post #7

This is actually great, and I predict that fans of nil-punning will rapidly discover the joys of actually having errors trigger where the error was introduced rather than propagating through the program. Any news on ClojureScript gaining the feature?

What is nil-punning?

Re: Clojure 1.13 adds support for checked keys

#17

Post by kevincox »

slifin wrote: post #2

This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…

The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case.

I have seen multiple major production outages in Golang code because people accidentally read a non-existent map key and used the default value. As a funny bonus in one of those cases we were stumped when debugging because this code had tests, but the tests were also reading the default values out of the map and asserting that "" was in fact a valid textproto (it always is!) so silently testing nothing.

So even if defaults are useful 9/10 times that 1/10 is so painful and expensive that it isn't worth it in my experience. The time spent responding to, debugging and fixing those outages far, far outweighed the time saved by the convenient default values in the 9/10 times.

Re: Clojure 1.13 adds support for checked keys

#18

Post by xoxolian »

slifin wrote: post #2

This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths This adds a throwing codepath which is quite drastic s…

For me: documentation at the "front door" of an interface, especially in that long moment before you decide to add a spec or Malli schema.

Re: Clojure 1.13 adds support for checked keys

#20

Post by codemonkey-zeta »

rads wrote: post #5
ndr wrote: post #3

Is it only me or this sounds a bit counter to clojure philosophy?

The maps are still open to new keys even if some keys are checked. I think that fits in with how clojure.spec and Malli work already, but in a lighter syntax.

The maps haven't changed at all, this is a feature at destructuring sites.
Post reply on HN