Clojurians Log v2

Good Morning

👋

!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

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 🙉

Morn'

strong opinions... negatively?

Hear! Hear!

Morning All!

negatively, but about the aesthetics of the syntax rather than anything functional i think...

Does anyone have an opinion on core.async these days?

and the lux syntax certainly looks very different to other lisps

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

:) It's been too many years since I last looked at lux to remember much about what I thought about it

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