ec changed the topic of #elliottcable to: a 𝕯𝖊𝖓 𝖔𝖋 𝕯𝖊𝖙𝖊𝖗𝖒𝖎𝖓𝖊𝖉 𝕯𝖆𝖒𝖘𝖊𝖑𝖘 slash s͔̞u͕͙p͙͓e̜̺r̼̦i̼̜o̖̬r̙̙ c̝͉ụ̧͘ḷ̡͙ţ͓̀ || #ELLIOTTCABLE is not about ELLIOTTCABLE
_whitelogger has joined #elliottcable
Rurik has joined #elliottcable
_whitelogger has joined #elliottcable
Rurik has quit [Quit: Rurik]
Rurik has joined #elliottcable
Rurik has quit [Quit: Rurik]
Rurik has joined #elliottcable
Sgeo__ has quit [Read error: Connection reset by peer]
Sgeo__ has joined #elliottcable
<jfhbrook>
ec: you do reason/bucklescript stuff right? how crazy would it be to choose that stack for a startup?
<jfhbrook>
I'm bouncing ideas off a friend, I really like the idea and I think we would make a good team - I find the timeline scary but it also makes sense and I can get some wiggle room
<jfhbrook>
but we were talking languages and we're both interested in languages with decent type systems and recognize that we can pick something a little nouveau as compared to the super conservative stacks we tend to pick for other people
<ec>
complicated, ‘course
<jfhbrook>
🤔 that sounds bad
<jfhbrook>
we're pretty advanced developers but we would want something that we can teach juniors
<ec>
i’d hop on the Reason discord and ask to chat with people who used it in a startup setting, of course
<jfhbrook>
there's a reason discord?
<ec>
but i’m happy to give 10k-ft view
<jfhbrook>
yeah totally
<ec>
so juniors are actually where it’ll shine most
<jfhbrook>
the "try" panel's example looks pleasant
<jfhbrook>
right - so this to me would be presentation layer stuff
<jfhbrook>
ideally with a mvc framework in place and cowpathed idioms for doing common presentation-y layer things
<ec>
first, exciting toy is great for hiring. lotsa functional nerds out there who will prioritize “omg an ML” over almost any other consideration.
<ec>
second, type-errors are best-in-class, if you stick to “The Good Parts”-equivalent (more on that in a sec); again, this serves very well to onboard newbies
<jfhbrook>
yea, claire said that there'd be a pool for that kinda thing
<ec>
so that’s all good.
<jfhbrook>
yeah, my take on types is not the same as claire's but we have enough overlap that having good typing is a thing we both want
<ec>
final Really Good bit: it’s literally just a better javascript. javascript devs will feel very at home, surprisingly quick, once they get over the syntax — i’m still, daily, shocked how this exotic weird 30-year-old academic lang is just, so conveniently perfect for JS-family stuff.
<ec>
that’s the only Really Good bit that’s not newbie-specific, note.
<ec>
now, medium:
<jfhbrook>
yeah? that would be good, I've been saying that I'd love a language that has the super flexible object creation that js has but with a powerful type system to go with it
<ec>
community’s strong, but no JS or Python or Ruby. you won’t find The Thing You Need every single time, but you’re also not gonna have to write it yourself every single time: it’s a middle-ground-userbase-size language, with everything that comes with that.
<ec>
this is complicated by the fact it’s “Just JS”, so there’s a bit of a pitfall of ‘writing bindings’ to existing JS libraries.
<jfhbrook>
right - the gold standard for existing tooling for me is python/js, but I've worked in deserts before (including early node!)
<jfhbrook>
oh, yeah, I'm confident that we can make bindings when needed
<ec>
on the one hand, you can bind *nearly any task you can imagine* in like, a single day, because the javascript sister community has solved literally every problem fifty goddamn times on npm
<ec>
but that’s not the zomgamazing solution it seems, or that it’ll be sold to you as.
<jfhbrook>
right, that's low lift but not casual
<ec>
because, first, this isn’t TypeScript: the types are not loosey-goosey, it’s *sound*. which means your types will need to very precisely, very correctly, line up with the library — and that’s hard enough when you’re not the library’s author, even harder when you’re trying to keep them updated and maintained
<ec>
and second because a binding is still, well, code to maintain — and what you’ve just done, is expanded *your* internal maintenance-surface, to *the entire surface-area of that external library*, instead of just a small ‘rolling resistance’ surface-area of what your code actually calls
<ec>
so ehhhhhhhhh lotsa JS libraries available but there’s caveats and half the time i’d just honestly NIH the goddamn task in OCaml.
<jfhbrook>
yeah - claire is stoked about having a properly sound type system, me I'm more practical
<ec>
next “smeh”-mediumey point: this is in no way specific to OCaml or Reason — but, yo, you’re talking about choosing a tool designed for *moving slowly and precisely*, for the exact environment where you’d wanna move quickly and imprecisely
<ec>
there’s obviously trade offs — great for hiring, great payoffs down the line if you succeed,
<jfhbrook>
I feel like for a presentation layer we would build a "framework" anyway - like we haven't talked about it but in my head the frontend mostly pulls levers on the backend, collects data and renders something
<jfhbrook>
so once you had the framework stood up it would be pretty straightforward to maintain the Platform
<ec>
but startup / pivoting / whatever is the only place i’d ever consider *not* using something soundly typed. if you opt for the slow, careful option, make sure it’s because “our startup is different for <reason> and needs that because <blah>.”
<jfhbrook>
if our backend language is kotlin then we'll have more flexibility there since kotlin still has the jvm's semantics
<ec>
any questions before i head on to the Objectively Bad?
<jfhbrook>
so funny enough ec I think there's an argument for typing *speeding up* development, especially if you're working with that platform only - since it will help the person working within the framework not fuck up lol
<jfhbrook>
uhhhh actual questions
<jfhbrook>
really appreciate this intel
<jfhbrook>
yeah, that's interesting philosophically - we're both on the types train but I'm like familiar with the javascript is good because there's less typing (being flippant here) argument and in fact believed it completely for a long time
<ec>
i strongly agree re: typing speeding things up — but fast development is not the same as prototyping; with prototyping, there’s a chance of “throw it almost all away”, in which case every second you spent fighting the type-system, at the end of the day, was wasted. that’s worst-case, but it’s a pretty bad worst-case, sooooo.
<ec>
hahah i’ve ended up very much a typing centering
<ec>
centerist
<jfhbrook>
interesting
<ec>
very tired of the arguments lol
<ec>
i consider them all tools useful for different things.
<ec>
anyway!
<jfhbrook>
yeah so what do you think is objectively bad
<ec>
now, i love ML and would choose it for damn near any task at this point; but here’s some really shity shit you’ll end up buying into:
<ec>
1. while OCaml is a great JavaScript, it’s not *literally, actually* JavaScript in every possible way at every possible turn. and (as, admittedly also with BuckleScript, as with ClojureScript or Fable or any “compile existing semantics to JS” system), that’s gonna hurt. often, deeply, and frustratingly.
<ec>
the pain of this bit is _directly_ dependent upon the size of your interface between JS and ML: this is the second half of the reason I tend to avoid “bindings.”
<ec>
that bit you said about typing making *actually pumping out software* a lot faster? that’s extremely true, and frankly, i find NIH’ing a WhateverLibrary clone in pure ML to almost always waste less time in the long run than writing, then maintaining, then *debugging* bindings to a JS-idiomatic API.
<ec>
but in a prototyping environment where you don’t have time to be writing every little thing from scratch, well, you’re gonna be buying into a lot of binding to existing JS solutions … which is gonna *absolutely maximize* the down-the-road pains of “this is almost, but not quite, JS.”
<ec>
i.e. lots of staring at compiled output code in a debugger, and becoming intimately familiar with BuckleScript’s runtime object model or whatever.
<jfhbrook>
yeah, you're definitely convincing me that running ocaml on the backend would be a bad idea
<ec>
won’t be a probably early on, but will grow as you fall back on more and more JS-to-ML surface-area
<jfhbrook>
kotlin's friction w/ proper jvm should be really low
<ec>
huh? I feel exactly the opposite lmfao
<jfhbrook>
why
<ec>
all of these downsides are in the JS-to-ML side
<ec>
pure OCaml suffers none of them
<jfhbrook>
oh I see what you mean
<ec>
ANYWAY HOL’ ON, LAST RELEVANT BIT
<jfhbrook>
bucklescript/node on the backend though :)
<jfhbrook>
oh, yeah - what's up
<ec>
so up until literally two weeks ago, I’d have been like “ignore all of the above, none of it matters because of this one”; though there’s … a recent development
<ec>
but frankly: BuckleScript, the most important component here, has had really opaque, unconvincing development efforts by the author/team.
<ec>
it has tended to lag _really, absurdly, unconscionably far behind_ the OCaml mainline, causing alllllllllllll sorts of compatibility problems;
<ec>
and has always struggled to see the contributions and development effort it needs to survive
<ec>
tl;dr I kinda thought Reason was slowly dying.
<jfhbrook>
thought? or think?
<ec>
now, the lead developer just got hired by Facebook, so i’m not sure how to feel right now
<jfhbrook>
or are you saying reason is pretty good but that bucklescript is having problems keeping up?
<ec>
I *had* thought Facebook had largely given up on Reason
<ec>
but … maybe not, if they hired Hongbo?
<ec>
oh sorry i didn’t do the intro-to-terminology
<ec>
“Reason” basically means the community / cloud of people
<ec>
reasonML, the syntax, is a tiny project, kind of silly, and irrelevant to any of this
<jfhbrook>
oh, I see
<jfhbrook>
so reasonml is a pretty small project since it's a fairly straightforward rewriting of ocaml semantics
<ec>
“BuckleScript” is the compiler, and “Reason” is the community of people and libraries using that compiler to develop npm-universe JavaScript schtuff
<jfhbrook>
ok I see
<ec>
yeah reason is dumb imho
<ec>
imho it’d make learning ocaml *harder* for newbies
<ec>
because you’ve got the tennis/racquetball situation
<ec>
when dealing with both languages, day-in-day-out, the wildly different traditional-ML-flavor syntax is an extremely good semaphore for “okay, brain, switch to functional thinking.”
<ec>
also something something all the books and tutorials and shit are in ML syntax, so, uh, just use that. >,€
<ec>
anyway.
<jfhbrook>
hmmmm
<ec>
tl;dr: cautious recommend, if you care about stability and quality in your software
<jfhbrook>
yeah ok word
<ec>
and i mean that — if you prioritize those things _over other also-important things_.
<ec>
yeah and google the discord
<ec>
but be wary of lots of over-the-moon shilling lmao
<ec>
everyone loves using it, nobody seems to be using it in production. ;)
<jfhbrook>
and yeah, what I got out of this miiiiiight be worth the benefits for the frontend since we can minimize the surface area
<jfhbrook>
ahaha yup
<jfhbrook>
but we're a startup and we can start with any stack we want :)
<ec>
yep a lot of the pain-points go away if you just write as much pure ML as you possibly can
<ec>
relevantly:
<ec>
if BuckleScript dies, there’s always JSOO
<ec>
js_of_ocaml. the much older, more stable, not-going-anywhere ocaml-to-javascript compiler.
<jfhbrook>
why a new compiler then?
<ec>
if your code is pure enough, and you keep BuckleScript-specific stuff to a few modules on the edges, you can use JSOO as a safety net: it will continue to exist and be supported for a long, long time.
<ec>
ehhhhhhhhh complex political stuff
<jfhbrook>
hmmmm
<jfhbrook>
makes me think of brython
<ec>
but boils down to “ewwie, this isn’t npm-y enough, and has cooties”
<jfhbrook>
it's python for bros!
<ec>
JSOO doesn’t have the bindings system, and it’s compiled output is slightly less debuggable/readable
<jfhbrook>
ah, I see
<ec>
whereas BS folx wanted 1. easy interop with npm-community JS stuff, and 2. to be able to publish compiled-BS-output to npm as JavaScript libraries
<ec>
which works! and i love!
<ec>
but they did a poor job of including the existing OCaml community in any of that work, and it’s basically forked. hard. so the OCaml folks want nothing to do with the BuckleScript folks, and vice-versa.
<ec>
i’m pretty sure it’s … just me, one dude, lol, doing all the interop. >,>
<jfhbrook>
hah, ouch
<ec>
lemme know how your exploration goes!
<ec>
very happy to answer any questions you run into; this is near ‘n dear to my heart
<jfhbrook>
gotcha
<jfhbrook>
yeah I have a massive headache today, I think my first migraine in a few years? or severe caffeine deprivation, not clear which
<ec>
<3
<jfhbrook>
so taking it easy today but
<jfhbrook>
yeah, I'll be thinking about this over the next couple of weeks
<jfhbrook>
the power to greenfield something and make slightly risky choices is pretty wild
<jfhbrook>
like making a bet that bucklescript will give us a good frontend, I'd never do that for someone else's company
<jfhbrook>
oh geez I totally forgot the other wrinkle
<jfhbrook>
we've been talking about a *mobile* app and using react *native*
<jfhbrook>
so like *that* might be a little wild
<ec>
I don’t know anything about React; but I would note that someone’s working on all that — there’s a ReasonReactNative or ReasonNative or something, I can’t remember
<jfhbrook>
yup found these libraries
<jfhbrook>
also found a reasonml example in the nextjs repo
<jfhbrook>
but reasonml + react-native could be "exciting"
<jfhbrook>
but also maybe really cool! especially if we actually get 3-way code sharing
* ec
grins
<jfhbrook>
and like if we have hyper-growth (VCs like hyper-growth, me I'm more interested in creating a long term viable business with staying power) then we'd be able to throw it out and write platform-specific apps anyway
<jfhbrook>
what? XD
<ec>
and, incase I didn’t drive the point home hard enough — the more pure-ML logic modules you build, the more you can share
<ec>
;)
<jfhbrook>
can you use react-native without bucklescript?
<ec>
i haven’t the foggiest idea how reactnative works, much less the Reason version presumably layered on top 🤣
<ec>
i’m very much a “write in the appropriate language for the environment” person, so that stuff isn’t appealing to me
<jfhbrook>
it looks like it's a javascript runtime
<ec>
OCaml frontend with as little JS-glue as possible; either OCaml-microservices or OCaml-Node on the server; Swift for iOS, so on and so forth
<jfhbrook>
for a really early stage startup, writing three independent apps (swift, jvm/android and js/browser) is a big lift and versus grabbing something like cordova or react-native and taking on the burden of a weird stack in return for code sharing, well it's a maybe
<ec>
there’s a reason i’m _still_ looking for work. i’m extremely wary of startups, because i’m a terrible fit for that.
<ec>
i only work well when I can work carefully and make the *correct* choices; I don’t do well with what my last CEO tried to explain to me as ‘scrappy’
<ec>
so yeah i’m not the person to ask about ReactyNativey things lmao, i’m just gonna have bad opinions like “uhhhhh, Swift???”
<ec>
having worked in Cordova, stay the fuck away >,>
<jfhbrook>
do you mean correct in an enemy of the good kinda way? or do you mean correct in a confident it's not buggy way?
<ec>
correct in the “won’t have to undo it later” way
<jfhbrook>
oh
<jfhbrook>
yeah no, so here's the thing
<jfhbrook>
all code can be thrown away
<ec>
well, undo isn’t the word
<jfhbrook>
or should be - because software is an iterative development process, you have to get a version of the idea out there without knowing if you did it right the first time
<ec>
removing code; great. removing code to immediately rewrite it because of poor choices (or, yes, sigh, prior constraints), is absolutely not my fucking cup of tea.
<jfhbrook>
test in prod and all that
<ec>
see i’m not sold on any of that
<jfhbrook>
it's the only way to ship
<jfhbrook>
that's not to say you can't, y'know
<ec>
I see that opinion all around, but it always seems to be entrepreneury startupy folks saying it, not the stable, sane developers I respect :P
<jfhbrook>
think about what you're doing, ask useful questions, and plan ahead
<jfhbrook>
I'm not an entrepreneury startupy person, believe it or not
<ec>
‘s why I won’t touch startups with a ten-foot pole
<jfhbrook>
what I believe in is Good Software
<jfhbrook>
if you want to make quality software - and I mean this! not even software that makes people money, software you can be proud of
<jfhbrook>
high software craftsmanship can only happen if you're able to test small ideas in front of real people and then make incremental changes based on real feedback
<jfhbrook>
you literally can not whiteboard for 6 months, come up with the Perfect Architecture, and then spend 3 months writing this thing and expect it to go smoothly
<jfhbrook>
no matter what you do you'll have to adjust it
<jfhbrook>
so you can use your expertise to make flexible design choices and build yourself a platform that will help you ship non-broken things (like say using reasonml)
<jfhbrook>
but you have to go for the gold knowing you're gonna have to make edits
<jfhbrook>
does that make sense?
<jfhbrook>
I fully support you wanting to write things you know won't break, things that are well-considered, things that will probably be considered more good than not
<ec>
mmmmmmmmm complex and subtle argument I don’t want to have on my phone, basically
<ec>
but see none of that is what i’m talking about
<jfhbrook>
understood, feel free to follow up when you get home
<ec>
taking feedback from users and mutating, or removing, something existing — duh
<ec>
but “let’s build this in cordova” followed by “we’re gonna rewrite it in swift”, totally different thing
<ec>
and again for the umpteenth time, i’m not tryna tell you what to do
<ec>
i _explicitly accept_ that you’re in the right
<jfhbrook>
sure I don't think you are
<ec>
and a startup can’t build a swift app
<jfhbrook>
oh I didn't want to like win an argument
<jfhbrook>
I just, I've been thinking a lot about software dev and what I think makes good software lately, it's less that I want to shout you down and more that I had to grab my soapbox
<ec>
but my point is only “ew. icky.” and a personal decision to stay as faaaaaaaaaar the fuck away from such constraints as i can possibly get for the entirety of my career
<jfhbrook>
yeah gotcha
<ec>
because frankly if that’s the requirement, i’m done with programmin’. outsies. gonna go learn machining and make things that last.
<jfhbrook>
I'm imagining you working for jane street
<jfhbrook>
I understand the preference for not having to feel like you have to say "hold my beer" before writing something
<ec>
hahahah
<jfhbrook>
I see what you mean by scrappy now. Yeah, startups specifically depend on moving fast and running lightweight
<jfhbrook>
big businesses depend on moving fast as well but can make heavier investments into the platform and take on less risk
<jfhbrook>
there's 100% something to be said for working with a conservative platform
<jfhbrook>
I feel like you would like the technical environment of a hedge fund like jane street
<jfhbrook>
idk if you'd like the people or the pressure to perform
<jfhbrook>
but like the choice they made with ocaml seems like it was made for the same reasons that you would want to work with it
<ec>
yeah, basically every OCaml team thinks like me
<ec>
I mean look at the legacy of packages: most OCaml stuff was written fifteen years ago, and has seen maybe twelve commits sense
<ec>
‘cuz they wrote it once, and it … just works
<ec>
which to be clear had huge downsides
<ec>
i still prefer my npm-style cambrian explosión of diversity
<ec>
wtf iphone insists on accenting that’s
<ec>
but clearly it’s worked well for like, decades, and clearly there’s something impressive to be said for that
<ec>
and sooooooo many best-in-class pieces of software come out of that community/style, too: Menhir, Dune, BAP — all absolutely spectacular software that would be the crown jewel of most other communities
<ec>
done with half the people, and half the commits … but I’m guessing 10x the time ¯\_(ツ)_/¯
<ljharb>
jfhbrook: i skipped most of this convo, but using any stack for a startup that makes it harder to hire is a bad move