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?
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).
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.
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:
(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.
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.
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.
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.