gfxmonk

It seems like a lot of people are interested in fixing this, and would be keen to see a solution. I believe StratifiedJS is precisely that solution (for JS at least), and it has existed in working form for years: http://stratifiedjs.org/ (it's not just an experiment - it's remarkably stable).

StratidiedJS completely eliminates the sync/async distinction at the syntax level, with the compiler/runtime managing continuations automatically. A `map` function in SJS works just like you would want, regardless of whether the mapping function is synchronous or not.

In addition, it provides _structured_ forms of concurrency at the language level, as well as cancellation (which most async APIs don't support).

Disclosure: I work on StratifiedJS, and just wish more people knew about it.

Do you wish nix's syntax were more like jinja? Or do you actually want to use jinja with nix somehow? I don't really know what the latter would mean, since nix is a programming language and jinja is a (string-based) template system.

Discarding the old server and replacing it with a new one is a very brute force way of dealing with the problem. That's not to say it's bad (it will obviously work exactly as advertised), but I don't see it working well for me. In particular, I want something with a quick turnaround.

I very frequently deploy to a virtualbox VM during development. With NixOS this often takes <10 seconds, and that still feels slow. I cannot imagine that you can do immutable deployment anywhere near as quickly or conveniently (but I'd be excited if you can tell me I'm wrong).

That's a fair question. I'll let you know if I find out ;)

My hunch is that it could scale well, but would require some integration work in order to use it nicely with existing orchestration tools. I don't know exactly what that would look like, or if it would be worth the effort of going off the beaten track.

Fair points. I started the post by stating that I (personally) wanted to use NixOS in the future, but admittedly didn't maintain that tone throughout the piece.

I definitely have humble requirements in terms of deployment size, so (for me) any orchestration tool is likely to be way more effort than it's worth. I compared NixOS (not a deployment tool) to those other (small-scale deployment and/or configuration management tools) because that's what I and plenty of developers I know have used, and I think the comparison helps illustrate the issues that NixOS can solve. Hopefully those who _do_ have experience and need for larger orchestration software can tell from reading whether the problems NixOS solves are relevant to them.

OP here. I've heard of terraform, although I've not investigated it much further than that.

It sounds like it's mostly a provisioning tool, and doesn't really help with configuration management once your machines exist. From the "terraform vs chef / puppet" page:

Terraform enables any configuration management tool to be used to setup a resource once it has been created. Terraform focuses on the higher-level abstraction of the datacenter and associated services [...]

So it sounds like like a very nice provisioning tool, but doesn't really compete with NixOS itself. Perhaps you could even use it to provision NixOs machines?

Great :D

Sounds like you already found my vim feed, but yeah, it's at http://gfxmonk.net/dist/0install/vim-custom.xml (it's not on that index page, because nobody else is likely to want it).

I've contributed to both the python & ocaml versions (and I made the logo :)). The ocaml version has not existed for all that long, I've only sent a few patches - I believe the porting itself was entirely done by Thomas, who's done great work.

I am a contributor, and I use it all the time. I publish a lot of my own stuff (mostly small utilities / libraries) at http://gfxmonk.net/dist/0install/index/, as well as a bunch of third-party software. Making distro-specific packages for all of these would be a stupid amount of effort - with a single zeroinstall feed I can run cross-platform code without having to package it N different times.

It is fairly easy to package / distribute portable code (e.g python, ruby, perl, js, etc). Stuff that requires compilation tends to be trickier, unfortunately (both to use and to distribute). Compiled software that is not relocatable (i.e hard codes paths) is sadly not possible to package in ZeroInstall.

It can use system packages (e.g apt, yum, etc) when available. So you can make a simple feed for your code that just depends on system versions of your dependencies, rather than having to "package the world". Of course, this only works on linux (and maybe OSX with fink / ports, but those tend to be less reliable than linux packages).

The big downside is of course that users don't generally know about ZeroInstall, and aren't likely to care why you think it's great. I generally recommend using ZeroInstall whenever I can in my own READMEs, but I have had little feedback on whether this has actually convinced anyone.

It has some definite upsides though, which is why I don't expect to stop using it myself regardless of general uptake:

- end users who aren't comfortable with terminals can use it just fine, yet it's as easy to publish as something like `pip` or `npm` packages.

- Since ZeroInstall feeds don't install anything globally, using zeroinstall dependencies during development means you never have to bother with tools like rvm, virtualenv, etc again.

- The savings that I personally get from having my own software & tools immediately available anywhere I go is already worth the effort of packaging it for ZeroInstall. E.g I have a "tim's custom vim" feed, with dependencies on all my vim plugins and configuration, and running it doesn't touch the host system's .vimrc or anything. That's pretty damn cool, even though it's only useful to me.

- I really like the notion that if you can _run_ some code, you can _modify_ that code. I despise the jump in most software between the "install & run" steps, and the "oh, you have to do these 10 manual and rather invasive steps to set up a development environment for this code". 0compile fixes this, for feeds that make use of it.

These days, if I'm writing something in bash (or batch) it's often because there is nothing better available - like kicking off an installer, or some other wrapper / bootstrap script.

For those kinds of simple tasks, the overhead of fully understanding the nuances of bash _and_ bash is way more trouble than the inconvenience of having fewer features available. This is not for bat/sh lovers, it's for those who have to use bat/sh even if they'd rather not.

Having said that, I wouldn't use batsh myself until it does something sane with errors (at least the equivalent of `set -e` in bash).

This writeup is poorly done, hard to follow, and ad-infested.

The source (http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flas...) is actually interesting though.

The front page is very blank on a large monitor - I got the impression it was waiting for a big chunk of content to load, until I returned some time later to see it still mostly white.

Cool :), glad it's supported, at least for the simple case of line-wise transforms.

Some things can't be done without reading everything. But there are still a number of operations on "all of stdin" that can safely be done lazily. I'm particularly fond of "divide stdin into chunks of lines separated by <predicate>" [0]. Which does need context, but only enough to determine where the current chunk ends (typically a few lines).

`py` seems to be aimed at a single expression per invocation (nice and simple), while `piep` recreates pipelines internally (more complex but also means pipelines can produce arbitrary objects rather than single-line strings). So I'm not really sure how you'd do the above in `py` anyway.

[0] http://gfxmonk.net/dist/doc/piep/#piep.list.BaseList.divide

I wrote a similar tool a while back: http://gfxmonk.net/dist/doc/piep/

Mostly out of frustration for PyP not being lazy (on large inputs it reads the entire file up-front, or at least used to).

But it was quite interesting to implement all the standard python idioms (like slicing) in a lazy way, and it's not that complicated a tool. I still use it a lot whenever I have a nontrivial pipeline to write.

While PureScript looks very cool, if you're interested in solving callback hell without changing the whole language, StratifiedJS is a superscript of JS that adds straightforward sequential-style code which is async under the hood, with a bunch of concurrency constructs built into the language:

http://onilabs.com/stratifiedjs

(Also, not terribly relevant to the discussion, but the fact that almost every line is abruptly broken mid-word without any hyphenation makes the article rather jarring to read)

"Nothing better than JavaScript" isn't a real limitation if JavaScript is a moving target

JS is only a "moving target" in the sense that stuff is being added to it. If you could make a perfect language by just adding things, then we'd be fine.

But the nature of the language itself is not going to change, because that would break backwards compatibility. The type system, prototype inheritance, `this`, type coercions, etc. There are plenty of undesirable things in JS which we're stuck with (unless we break compatibility, in which case it might as well be a different language).

It's not just a best practice - exceptions raised from async code callback simply do not work right (they'll never make it back to the caller). In practice an exception raised from a callback will take a very short trip the wrong way through the stack (whatever happened to invoke your callback is _not_ the original caller, otherwise you wouldn't need callbacks), and end up as a toplevel uncaught exception, killing your entire process in nodejs.

You may find StratifiedJS pleasing: http://onilabs.com/stratifiedjs

You wouldn't even need that one callback, just:

return find_largest(get_stats(read_files(dir)));

Exceptions are propagated as you would expect from synchronous code, despite being async under the hood.

Thanks! We've tried hard to make it understandable for new users (and provide good documentation for users of any vintage). There's quite a lot of _different_ stuff in Conductance compared to vanilla JS, but our belief is that once you get up to speed, it should make programming concurrent apps much more straightforward. Thanks for taking it for a test drive, don't hesitate to jump on the mailing list if you need help down the road - https://conductance.io/community

And yep - today is our first public release of Conductance, although StratifiedJS (the language it's built on) has been evolving for a couple of years now.

One solution is to use a separate storage for salts (or hints, really - it doesn't need to be a complex scheme, since we're hashing it anyway).

I do this myself with supergenpass, for when a site's password DB gets compromised (a common enough occurrence these days).

Importantly, this augmented state is a convenience - it's not irreplaceable. If I find myself _without_ my list of hints, I am not completely screwed - I'll just have a harder time logging into those few sites, and it's quite likely I'll remember the right hint after a few tries from memory if I really need to.

Have you seen SuperGenPass? It's much the same concept, and has been around for years (including browser extensions, etc).

http://supergenpass.com/

For the justifiably paranoid, a web service is not going to cut it (lack of https is just the start - relying on any web service is a _lot_ of trust to put in such an Important Thing). Even if you are as trustworthy as I'd hope, it's foolish to even allow the possibility of you (or your service) being compromised to affect the safety of my passwords.

Personally, I use a command-line implementation of SuperGenPass that a friend of mine wrote (and I host at github:gfxmonk/supergenpass). It avoids all sorts of spoofing / browser vulnerabilities, and is reasonably convenient with something like Guake.

I'm not trying to diss the concept at all - I love this kind of thing, and honestly can't understand why it isn't more widely used / encouraged. But It's worth pointing out what already exists in the space.

If they rate limited per user, you could trivially prevent someone from logging in by pummeling the server with login attempts for their username.

The compiled JS code looks harder to read than using callbacks to me

With good tools and a sufficiently correct compiler, that should be as irrelevant as worrying that compiled x86 assembly is harder to read than the C source.

StratfiedJS (http://onilabs.com/stratifiedjs) does this and more[0]. It's more heavyweight than a set of macros, but we believe the features warrant that.

[0] including a module system, fork-join parallelism, try/catch and stacktrace support even for async code.

(disclaimer: I joined Oni Labs to work on SJS, after struggling with my own coffeescript fork for 6 months)

For stuff like tab completion and for launching small command-line apps (think "grep", "sed", etc), absolutely. A penalty of hundreds of milliseconds for the _launcher_ alone can double (or more) the total execution time.

I use zeroinstall a lot (I'm a contributor), and I turned off tab completion because the lag (of the python implementation) made me wonder if my terminal had locked up, which was far more distracting than trying to remember the available arguments. I have re-enabled it in the ocaml port, because now it's effectively instant.

"slowness" is not the problem here - it's "slow program startup". If your process only lasts for tens of milliseconds, you're not going to make it any faster by embedding C code because 99% of time is still going to be spent initializing the python VM.

StratifiedJS allows you to write callback-less async code, including full support for exceptions thrown from async code (stacktraces and all):

http://onilabs.com/stratifiedjs (disclosure: I work at Oni Labs)

It does extend JS with some additional syntax as well (new concurrency constructs as well as some syntactic sugar), but it doesn't alter existing JS syntax.

For a more application-level (rather than OS-level) approach that shares a lot of good ideas with NixOS, there's also ZeroInstall (http://0install.net). There's a comparison with Nix at http://0install.net/comparison.html#Nix.

This looks great (and sorely needed). Unfortunately, console vim lacks the ability to recognise a bunch of useful keybindings (custom ones that I've grown quite fond of, it mostly has trouble with ctrl e.g ctrl+space, ctrl+tab).

Also, the colour scheme support (colours, bold, etc) in console vim is awful.

So yeah, I'd love to see something like this that supported vim-gtk. I already have a tiling window manager, I'm cool with using windows^.

[^] graphical ones, not Microsoft ones (which are supported, incidentally).

The thing about piep (and other such tools) is that they can make some reasonable assumptions that would typically be a bad choice for a generic language - things like having global variables for commonly used items, making assumptions about how certain return values should be interpreted, etc. Small things like this wouldn't fit well with most general programming languages, with the possible exception of perl.

Plus, it still doesn't solve the piping issue. constructing a command as a sequence of operations like:

p.foo() | len(p) | p + 1 | str(p)

is much easier to follow (and modify) than

str(len(p.foo()) + 1)

this is not a big deal for programming languages because we use variables, functions and other ways of structuring our code, but those don't map well to oneliners.

You absolutely can use `pip`, if you want. I made sure of that (or at least tested it once), because I know it's widely used and convenient. But I personally think it's a terrible way to install and distribute software, and would love for more people to try Zero Install, because I think it's the way that software ought to be distributed.