This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-27
Channels
- # admin-announcements (1)
- # announcements (11)
- # babashka (17)
- # beginners (26)
- # calva (6)
- # cider (2)
- # circleci (1)
- # clojure (41)
- # clojure-dev (1)
- # clojure-europe (31)
- # clojure-france (2)
- # clojure-italy (10)
- # clojure-nl (7)
- # clojure-norway (5)
- # clojure-spec (15)
- # clojure-uk (42)
- # clojurescript (4)
- # code-reviews (12)
- # conjure (10)
- # datalog (2)
- # datascript (15)
- # datomic (37)
- # emacs (1)
- # events (5)
- # fulcro (19)
- # jobs (1)
- # jobs-discuss (9)
- # kaocha (2)
- # luminus (14)
- # meander (4)
- # membrane (39)
- # off-topic (26)
- # other-languages (2)
- # re-frame (13)
- # reitit (6)
- # rewrite-clj (39)
- # sci (6)
- # shadow-cljs (33)
- # test-check (15)
- # vrac (17)
- # xtdb (7)
!mรฅningยก
Morning ๐
morning
@mccraigmccraig yeah that's one thing that's irking me about typescript atm
the fact i have to write types, then data validation and maintain both
makes the language feel toy-like since a lot of errors/ user data issues are ofc runtime
and both typescript and purescript (the latter to a lesser extent) have this problem big time cos at runtime, it's just minified JS so all bets are off if you don't have any runtime checking
last time i looked, lux had a nice typesafe library for automatically producing encoders/decoders from types ... not sure whether that's something that can be replicated in other hm-typed langs, or if it depends on some features of lux, like types being expressed as regular datastructures or the full compiler state also being a regular datastructure and available to macros https://github.com/LuxLang/lux/blob/master/stdlib/source/poly/lux/data/format/json.lux
and the decoders return an error-handling type, so runtime errors are catered for
ah I thought lux was dead
but it looks moderately active
i think i'm back to my regular 'why don't people just use lisp' or at least a data oriented lang frustration
all we do with line of business apps is shuffle around data, so why do we spend so much time messing around with things that aren't that
viva la revolucion
very noticeable that that's not an issue i have when working in clj
i don't think lux is dead, eduardo still seems to be pretty focused on it, and from the look of it he's achieved quite a lot - but it's also been changing massively (which may be a good thing), so i wouldn't try writing any real code on it yet
also @bronsa has some quite strong opinions about lux syntax ๐
strong opinions... negatively?
negatively, but about the aesthetics of the syntax rather than anything functional i think...
and the lux syntax certainly looks very different to other lisps
:) It's been too many years since I last looked at lux to remember much about what I thought about it
Morning All!
Does anyone have an opinion on core.async these days?
prediction: at least one person prefers manifold streams
lol, i have my issues with both core.async and manifold, although i've used manifold a lot more heavily
we're considering using callbacks for an internal API as it will probably be sufficient and simpler, but core.async is also being considered
i think core.async makes for a poor promise abstraction, but is good for co-ordinating streams of things
for an API call returning a single result a promise is a better fit i think
for an API returning streams of things (like a websocket) then core.async is a good fit
i prefer the promise for the API because [1] promises compose easily and [2] error-handling is built in and also composes well
core async's killer feature is backpressure If you need backpressure then its a good choice If not, then it isnt
er, or if you are using cljs in a browser, thats a killer feature too (might be out of date on that one)
for cljs api calls from a browser i'd go with promises over core.async too - funcool/promesa
wraps them nicely
but for websocket messages and streams of events in the browser - core.async is a good fit there
also if you do have a thing that core.async
does work well with, combining abstractions like transducers etc is a breeze
imo a little easier to handle lotsa stuff using that (like you say w/ the example of a stream) vs promises/promise chains
unless you get deep into craig's world of streams & monads