This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-17
Channels
- # announcements (8)
- # babashka (27)
- # beginners (60)
- # biff (7)
- # calva (3)
- # cider (10)
- # cljs-dev (69)
- # clojure (18)
- # clojure-europe (12)
- # clojure-hungary (1)
- # clojure-korea (2)
- # clojure-new-zealand (12)
- # clojure-nl (1)
- # clojure-norway (80)
- # clojure-uk (9)
- # clojurescript (55)
- # cursive (69)
- # data-science (16)
- # events (5)
- # helix (11)
- # hyperfiddle (23)
- # jobs (1)
- # lsp (5)
- # malli (14)
- # matrix (1)
- # missionary (2)
- # off-topic (40)
- # portal (31)
- # re-frame (17)
- # reitit (11)
- # releases (11)
- # shadow-cljs (4)
- # squint (4)
- # tools-deps (5)
- # yamlscript (4)
Hva er egentlig greia med YAMLScript? Er det en spøk? Jeg skjønner ikke hvorfor noen vil kode i yaml?
Jeg kan anbefale å ta en titt på denne videoen: https://www.youtube.com/watch?v=GajOBwBcFyA
YAML er et faktum. Hvis du bruker CircleCI eller Ansible eller Github Actions eller en mengde andre verktøy, er det YAML du bruker for å konfigurere dem.
yamlscript er også et turingkomplett programmeringsspråk forkledd som yaml. Så i stedet for å ha hauger på hauger av yaml for å styre kubernetes, kunne man hatt (skrik) kode. Så jeg ser litt på yamlscript som en bakdør for å snike inn en clojure-interpreter i prosjekter der man har sjukt mye yaml.
jeg tror også yamlscript-interpreteren er skrevet så den starter veldig fort (ala babashka)
Denne intervjuen synes jeg er god å lytte til også: https://www.listennotes.com/podcasts/the-repl/52-coding-in-yaml-with-ingy-ISqZjAnXl_W/
Jeg håper akkurat at YamlScript blir en anledning for utviklere til å ta en nærmere titt på Clojure.
Jeg hadde likt å vite om YAMLScript når jeg jobbet med 400+ microservices som kjørte via Kubernetes i flere miljøer. Det var syyykt mye YAML. Vi brukte https://kustomize.io/ for å gjøre "inheritance" av ting som gjentok seg ofte. YAMLScript hadde gjort en del ting enklere.
Jeg har nå praktisert UI-komponenter som rene funksjoner i et par uker er jeg fullstendig solgt. Dette kommer jeg til å fortsette med! Utrolig deilig at UI-komponentene ikke har avhengigheter med tilstand. Anbefales! 😁
foreløpig har vi ikke trengt mer interaktivitet enn det vi får av ren HTML. Dette er en internapp, målet er å vise riktig informasjon. Hvis statisk HTML ikke holder, er HTMX en spennende kandidat!
@U07FCNURX Det er jo en uke til?!?! Hvor usmidige er dere? Har dere lagt femårsplaner?
@U0ETXRFEW obs! Dette er ikke samme dato som jeg ser for meg at det blir babashka-meetup! (jeg har siktet på tirsdag 14. mai for babashka-meetup)
Ingen femårsplaner, men ja, jeg har ting i kalenderen min en uke frem i tid 😱
Vi gir oss ikke på én lunsj, vi inviterer til TO LUNSJER PÅ EN GANG (på forskjellige datoer) https://www.meetup.com/clojure-oslo/events/300467318/
Alt ser vel ut på Jaipur 😊 https://smilefjes.mattilsynet.no/spisested/oslo/jaipur_indian_restaurant.Z2003271519041382025IMNVQ/
Urelatert, men http://matvaretabellen.no må være en av de mest snappy norske nettsidene jeg har sett på lenge.
av hva jeg har hørt fra folk som jobber i mat/service industrien så er ingen steder helt innafor.
Jeg har CTO-en på gli vedrørende Clojure som backend-språk. Hans bekymringer er 1. rekruttering - tilbud av utviklere - kostnaden av disse utviklerne (Han har fått med seg at Clojure-utviklere er godt betalt) 2. at det finnes få offisielle client-biblioteker for "standard"-programmer som Redis, SendGrid o.l. som vi jo sannsynligvis kommer til å ønske å interagere med. 3. at Clojure/Java kjører på en VM Jeg vet ikke helt hva han tenker på vedrørende punkt 3, og jeg tror ikke at rekruttering vil bli problematisk; jeg tenker i de baner at vi kanskje får flere kapable søkere, at folk som er interesset i nisjeteknologi, har høy verdi og mye driv (som @slipset var innom i https://pca.st/tzcf8v2i med @augustl), og prisingen er vel uansett ikke så ekstrem. Men hva synes dere om punkt 2? Er det vanskelig for dere? Han er negativ til interop, for jeg nevnte at med Clojure har man tilgang til hele Java-verdenen, men jeg tror at han ikke er klar over at Clojure er designet for interop, og at om man trenger å gjøre det, så flyter det mye bedre enn han kanskje forestiller seg. Jeg har ikke noe særlig erfaring med interop selv, så det virker en smule skummelt sammenlignet med så å si alltid ha tilgang til biblioteker om man f.eks. velger Node.js.
Det virker som at han ser på Java som gammel teknologi, kanskje som er på vei ut på et vis. Han liker veldig godt JavaScript/TypeScript-verdenen, nok hovedsakelig fordi det er hva "alle bruker".
Punkt 2 er ren FUD. Det er få platformer som har flere SDK-er enn JVM-en. Ja, Java er et utdatert språk, men JVM-en er en utrolig polert plattform. Viktig å ikke blande.
I tillegg finnes det masse Clojure-sdker også, så her tviler jeg på at han har gjort noe ærlig research.
Finnes Clojure-bindinger for Redis feks. Eller nats, som dere like gjerne kan bruke 😎 😄
Clojure utviklere er godt betalt fordi de er flinke. Det er mulig å skaffe seg billige og dårlige utviklere, men anbefales ikke. YMMV 😹
Synes det blir litt feil og si at Java er et utdatert språk. Det er veldig mye brukt rundtomkring og det øses fortsatt penger inn både språket og jvmen. At Java er på vei ut tror jeg heller ikke helt stemmer, mange som går bort fra java går til kotlin f.eks, så språket java har fått konkurranse fra andre språk på samme platform. Clojure er veldig stabilt, ikke samme churn og deprecation mas som i javascript land (ikke språket sin skyld, mer kukturen rundt). Og at det er knyttet til java og jvm er et stort pluss.
La meg prøve med et “på lengre sikt” argument. Clojure er behagelig fritt for rammeverk. Dette er litt drit når du bare vil komme igang, og der noe som f.eks spring-boot ville fått deg opp å kjøre fort. Men pay-off’en er sinnsykt stor over tid. Fordi vi benytter oss av biblioteker og ikke rammeverk, får vi et par fordeler: 1. Vi slipper den store skumle oppgraderingen fra rammeverk Vn til rammeverk Vn+1 der potensielt store deler av kodebasen må tests. Vi oppgraderer bibliotekene ettersom de kommer i nye (bakoverkompatible) versjoner og slipper massiv tilpassning av vår egen kode 2. Kodebasen er mindre bundet til et rammeverk. Som regel når du koder i et rammeverk, blir din kode “infisert” av rammeverkskoden, og det å gå fra spring til noe annet er minst like vanskelig, om ikke vanskeligere enn å bytte database. Med en biblioteks approach er det enklere å bytte ut de enkelte bibliotekene over tid. Vi har byttet routing, skjema-verktøy og json serialisering over tid, null stress Jeg sier vel ikke at dette er umulig å gjøre i Java eller andre språk, men det er vanskeligere, fordi de har rammeverkene og du skal være ganske rakrygga for å ikke velge dem.
Jeg har nok av anekdoter om kolleger i forskjellige prosjekter som har månedslange "oppgradere Spring Boot" busywork-prosjekter
Huff, for ikke å snakke om hvis man på ett eller annen tidspunkt trenger a debugge ting i spring.
@U9CU2PQPM jeg vil gjerne høre hvordan dette går til slutt - når dere er ferdig med å snakke!
@U3X7174KS, det ble ikke Clojure i selve backenden, men jeg skal nok få lov til å parentesere i diverse services som måtte dukke opp. ☺️
Så VM var ikke så viktig i valget? (V8 er vel en VM) > 3. at Clojure/Java kjører på en VM
Jeg vet ikke, de er vel forskjellige nok til at noen vil si at den ene er VM, mens den andre er ikke det. Jeg tror ikke det veide så tungt, egentlig; det var nok hovedsakelig bare enda et punkt som ble presentert for ikke å velge Clojure, som han var motvillig til.
Det kan jo være greit å skrive js/ts på Node også! Mener at @U050B88UR selv har sagt at han verdsetter et godt team høyere enn teknologivalg som matcher hans smak 100 %.
Personlig ville jeg vært skeptisk til JS/TS på backend, men det er mulig jeg er utdatert. Det jeg virkelig setter pris på med jvm’en er at det er et godt stykke engineering, med sinnsykt gode verktøy for monitorering, performance tuning, og alle de greiene du skulle ønske du hadde da du plutselig trengte dem.