This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-08
Channels
- # babashka (9)
- # beginners (43)
- # biff (4)
- # calva (11)
- # cider (6)
- # clerk (1)
- # clj-kondo (4)
- # cljs-dev (6)
- # clojure (82)
- # clojure-berlin (1)
- # clojure-europe (42)
- # clojure-nl (1)
- # clojure-norway (182)
- # clojure-quebec (1)
- # clojure-uk (19)
- # clojurescript (6)
- # datahike (1)
- # emacs (30)
- # fulcro (5)
- # honeysql (6)
- # hyperfiddle (12)
- # lambdaisland (8)
- # malli (11)
- # off-topic (36)
- # pathom (26)
- # pedestal (1)
- # portal (25)
- # practicalli (1)
- # rdf (29)
- # re-frame (17)
- # reitit (1)
- # releases (1)
- # sci (37)
- # shadow-cljs (15)
- # vim (10)
- # xtdb (13)
This is so cool
JEP 442 is what I’m most interested in
“Generational ZGC” is funny to me because I vividly remember a few years back ZGC proponents saying lack of generations was a good thing… and like most generation-less GCs… eventually they end up getting generations 😄
@U0L91U7A8 doing victory rounds?
Not really. This is quite different than what I teach in my book
It is in some way the exact opposite of the Clojure approach to data, yet with the same name :)
It is this idea that if you specify concretely every single type and choice you can verify every aspect of your code by cases. Whereas Clojure’s approach is to make data as light and malleable as possible, to make all of your data and cases open and amenable to extension and change. It is concrete vs water.
Having spent decades of career in both worlds, give me water every day
you have probably built only simple services; if you were modelling complex entities then you would want concrete! 🤕
The more complex an entity is, the more I know it will change. To paraphrase Perlis, if you have 20 parameters to your function, you probably missed some.
IMO most people that become obsessed with types and typing system forget that the whole point is that you need to model a system in such a way that is easy to evolve - not to be a static artifact
what makes sense is to set clear boundaries to your inputs and validate them. Anything else that happens within the system is controlled. From that point inwards, setting explicit types for everything, does not help.
IMHO it all depends on the kind of system you are working with, what trade-offs are more important to you. Like, a micro-processor emulator with a well defined spec that isn't going to change much is not the same as a classical company information system
Clojure is born of and squarely targeted at the latter
But so is Java (in the main)
yeah, IMO the Clojure approach is much better for information systems, but I can understand people liking the static typing when having other kinds of systems and problems in mind
Having worked on actual processors, the static world assumption is great for proving things work It's awful when you find a bug
https://brazilian.report/liveblog/politics-insider/2023/06/07/nubank-layoffs-restructuring/
I wouldn't exactly call 296 "closed" positions a "mass layoff" given they have well over 8,000 staff.
That's less than 0.4% of the workforce...
Ah, yeah, my math is off there... but, no, I don't consider 4% "significant", to be honest.
(the US Department of Labor actually defines "mass layoff", by the way, as at least 500 people in a large company or at least 33% in a smaller company, such that 33% is 50-499 people)
The previous two were a tenth the size of this one. It all still seems like a very small adjustment for a large company in a fast-moving space, as it evolves.
I mean, it obviously sucks that people are laid off -- and it particularly sucks if it happens to you or your friends/family -- but adjustments in staffing are happening all the time in a lot of companies in a lot of industries. What I'm complaining about here is the overly-dramatic headline of the piece -- I think that's poor journalism.
