<ljharb>
ec: i'm not the progenitor but i've taken it over
<ljharb>
ec: there's tons of open issues, but the biggest one is probably performance right now
<ec>
ugh I'm the worst person to ask to do that
<ec>
you must be new here.
<ljharb>
lol ok there's other things
<purr>
lol
<ec>
I'm notorious for being an idiot who thinks performance is meaningless
<ec>
have you *seen* my programming language
<ec>
it takes like two minutes to run hello-world
<ljharb>
do you know anything about zsh?
<ec>
;)
<ec>
quite a bit, actually
<ec>
well hm
<ljharb>
oh-my-zsh sets all kinds of options that break nvm in all kinds of ways
<ec>
more than anybody else I know personally, but I don't feel like it's that much
<ljharb>
so i have tons of crappy code that detects the options i know about, unsets them, and re-sets them as applicable after an affected operation
<ja>
nice
<ec>
oh lord really?
<ec>
yeah that's zsh for real. omz is kinda the worst.
<ljharb>
but i'm sure there's a better way to say "for the scope of this function, disable all the stupid things omz does"
<ec>
hm
<ljharb>
the catch is that nvm isn't run in a subshell, it's sourced in the current shell
<ec>
yeah I noticed
<ljharb>
so i have to leave the opts as nvm found them
<ec>
was going to say ‘wouldn't a subshell solve that’
<ljharb>
also being a separate binary would solve it
<ec>
can you reduce all the current-shell code to a wrapper that invokes a subshell containing the rest?
<ec>
that reduces your compatibility surface-area
<ljharb>
but refactoring nvm to be 1% shell 99% subshell/binary is a massive project
<ljharb>
yeah that's what i'd have to do
<ljharb>
if i did that, i'd be able to write the 99% in bash instead of posix, which would be dreamy
<ljharb>
but that seems very overwhelming
<ec>
okay, why refactor it *all* now, instead of writing a wrapper *now*, that leaves the rest of nvm as-is
<ec>
hm
<ljharb>
i'm open to suggestions
<ec>
I'd say don't do a separate *binary*, so to speak. Still invoke in the current shell.
<ljharb>
ok
<ec>
If *nothing else*, that keeps language features / conventions consistent across the entire codebase
<ljharb>
the main requirements are: 1) works on ksh/dash/sh/zsh/bash, 2) can be installed with git, curl, or wget. 3) doesn't have any wonky permission issues
<ec>
if you **do** do so, either do it in Node (since it's freaking nvm), or do it in Go or something blazing fast.
<ljharb>
(off the top of my head)
<ljharb>
the problem is that nvm has to work in an env with no node
<ljharb>
because it's used to install it in the first place
<ec>
yeah, go gives you widely-compatible, standalone binaries, so that's nice
<ec>
I hate go, personally, but, seems ideal for this sort of thing
<ljharb>
i'm not stoked on the idea of writing it in go
<ec>
lol ditto
<purr>
lol
<ljharb>
i'd prefer shell, or JS
* ec
nods
<ec>
okay so this is getting ridiculous, but,
<ec>
can you pre-package node with some Node code into a single universal package / binary, use that to install, and then wipe it out?
<ec>
like 0.10 lts or something
<ec>
I've never tried to package node, so I genuinely don't know how pain-in-the-ass it'd be
<ljharb>
that's a nonstarter i think
* ec
nods
<ec>
just examining all the options.
<ljharb>
nvm also powers all of travis-ci's node tests
<ljharb>
so it has to be easy to deliver to their docker images
<ljharb>
and ideally lightweight
<ec>
short of that, I think the best option *is* to write a wrapper that invokes the rest of nvm inside the same shell the wrapper's running in, but with sh-compatibility options enabled
<ec>
basically, not looking for a new binary, but trying to get sh-world anyway.
<ec>
yeah lol dealing with that rn actually
<purr>
lol
<ljharb>
:-p PRs and suggestions welcome whenever you're in the mood
<ljharb>
it's relatively stable right now and the big things i need to work on for it aren't terribly pressing
<ec>
nuck: you should look at zgen; it's very similar to your impl, maybe a tad bit more robust … and is somebody else's code, so you don't have to maintain it thereafter :P
<ec>
imo ‘Somebody else already wrote the thing I wrote a while back, but a bunch of other people now actually *maintain* it!’ is one of the happiest feels you can get as a programmer
<nuck>
Yeah!
<ec>
and also you can come in here and yell at me if it doesn't do what you want, because I'm now intimately familiar with it :P
<nuck>
I think when I wrote zilsh it was pretty much just Antigen or OMZ
<nuck>
And Antigen was all kinds of weird
* ec
nods
<ec>
ditto
<nuck>
I'm pretty proud of how clean the zilsh code turned out
<nuck>
And yeah, deleting code you wrote and adopting somebody else's is amazing
<nuck>
On HB's ongoing rewrite, just a couple days ago I replaced my custom deserialization + controller/helper framework with a gem
<ec>
ruby )'=
eligrey has joined #elliottcable
<nuck>
Ey, it's popular and we can build things really fast with it
<nuck>
Like, I've got probably a fifth of hte site done in 200 LOC
<nuck>
I expect the final site will be about 600 LOC
<ec>
goddamnit
<ec>
STILL no snow here
<ec>
Chicago, you are not yourself this winter
<ec>
I looooove Ruby
<nuck>
How's the polar vortex looking
<ec>
that was sad because I miss it, not sad because it's bad
<nuck>
hah
<nuck>
I'm debating whether to try deploying on Rubinius too
<ec>
rubinius <'3
<nuck>
Real threads, lack of GIL
<nuck>
Could really make our server *scream*
<nuck>
The big question for me is... how long before it gets that sexy safe-call operator
<nuck>
&.
<nuck>
We're gonna use that so much
<ec>
what?
<ec>
oh lol like cd's ?.
<purr>
lol
<ec>
drives me nuts that they went with &.
<ec>
that's the ugliest, dumbest one, ugh
<nuck>
It kind of is
<nuck>
But
<ec>
can't remember if I posted in that thread? I think I did?
<nuck>
It could be worse
<ec>
but nobody listened to be if so, as usual
<nuck>
I mean, it could be ->
<nuck>
Like PHP
<ec>
I think I'm not loud enough to contribute to proglang design, maybe that's why I just work on my own
<ec>
it's like Node and the globals-in-modules thing ಠ_ಠ
<ec>
or CommonJS
<ec>
geeze, I'm still butthurt over that
<nuck>
I'm still waiting for Node to switch to ES6 stuff
<nuck>
It's hard to take it seriously when it's now got so many "losing team" parts. sure, it was the cause of the creation of most of the "winning teams"
<ec>
what
<nuck>
But CommonJS has now lost to ES6 modules, callbacks are losing to promises
<ec>
… has now lost? wat
<nuck>
Not saying the new winners are better, just that it's clear they're winning now
<ec>
promises are used extremely heavily in nodeworld; CJS require has *completely* won (almost everybody hates ES6 modules, unfortunately),
<ljharb>
nuck: what do you mean "switch to ES6 stuff"
<ec>
clear to who, where, wtf
<ljharb>
ES6 modules don't exist yet.
<ljharb>
they aren't a thing, and nobody is using them
<ljharb>
they're just using import/export and using magic fairy dust to change them into require()
<ec>
AMD is dead, 6-modules are a toy at the moment, basically
<ljharb>
AMD is definitely dead
<ec>
require() and browserify has Won™, at least for the near future
<nuck>
ljharb: It's true, everybody is compiling them
<ljharb>
right
<ljharb>
the loader spec isn't finished
<ljharb>
so there's literally nothing else you could do yet
<nuck>
But I'd say that ES6 module syntax is pretty much taking over
<ljharb>
somewhat. once the loader spec is finished we'll see how babel adapts.
<nuck>
It's guaranteed a decisive win once the spec is finalized
<ljharb>
well. not necessarily.
<ljharb>
but it's likely, especially if the community tends to avoid named exports
<nuck>
Both the Ember and React communities have latched onto ES6 modules
<ljharb>
true
<ljharb>
but react already latched onto "class" and is now moving away from it
<ljharb>
to functional stateless components
<nuck>
Really? Didn't know they were moving away from it already
<nuck>
Ember is planning to adopt the ES6 class syntax, they just have to slowly dial back their own class system
<nuck>
I'm excited to see decorators likely happening in ES2016, that'll be useful
<nuck>
Ember also adopted Promise really well, and to what you said about "used heavily" ec
<ljharb>
embers core maintainers are on the committee with me, and were big advocates of "class", so naturally they'll be using it
<nuck>
The entire stdlib needs a wrapper to put it in Promise mode
<ljharb>
like what?
<ljharb>
the language has no concept of async prior to promiess
<ljharb>
*Promises
<nuck>
The callback stuff?
<ljharb>
that's node, not JS
<nuck>
Yeah I meant for node
<ljharb>
but yeah node core is unlikely to use promises anytime soon.
<nuck>
He said "promises are used extremely heavily in nodeworld"
<nuck>
And I'm like "Yeah but they're a second-class citizen"
<nuck>
How hard would it be for them to just do if (!callback) use promises
<nuck>
:/
<nuck>
I understand they're being cautious and the stdlib wrappers are pretty mature now so they have less motivation
<nuck>
But honestly it's just going to lead to fragmentation
<ec>
soon / ever
<ec>
Node is fine and doesn't need to change.
<ec>
it's *tiny*, and *stable*, and that's *good*.
<ec>
I'm worried about streams, in fact; I think they're too big and bloated. I wish they weren't in Node at all, and were a big, commonly-used framework/library that wrapped low-level Node primitives.
<ec>
I'm *happy* that all the FS primitives took a very simple, efficient pattern and stuck with it; letting us do all the work of wrapping or mutating it.