zenhack

The key thing is the user has somewhere they can actually run your app; it doesn't necessarily have to be their own box, it could be one provided by a friend or a hosting provider. That said:

> The one way out of this trap would be if we could come up with some kind of server that did not require administration

To a large extent this is actually a goal of sandstorm.

I'd contest some of your requirements though: /Nobody/ has 100% uptime, even AWS. And most individuals are not in a position where an outage is going to cost them millions. It might suck, but people trudge through worse problems with their PCs; no reason a personal server ought to be different. So I think the bar is a bit lower than you suggest; I think it's possible to get a server to the point where it can be "administered" by someone who's capable of "administering" a laptop.

We're obviously not there yet; you still need to set up a Linux box before installing Sandstorm itself, and we don't really have a great Story wrt backups yet. But Sandstorm itself is already mostly fire-and-forget; it auto-updates itself, our security track record is rock solid, and I can't remember the last time I had to do anything that felt like sysadmin work for my Sandstorm box. There are a couple things I think still need to happen:

1. We need an automatic backups & recovery story.

2. We can't require the user to install Linux first; we'd need a "sandstorm distro" so folks can do the whole business together. The OS should be hardened by default and self-update with Sandstorm, as well as integrate with the admin panel for scheduling reboots.

3. Ideally, there'd be hardware you could buy that's just already running the sandstorm distro.

There's some talk of trying to figure out funding stuff, though none of it is super organized yet. I personally set up a GitHub sponsors profile and a couple folks are donating. I could see us getting organized enough to scrounge up money for at least one person but we'll see.

But, even without that, I do think there's a reason to be hopeful that this is more than a momentary stir. The company shut down so suddenly and without really on-boarding new contributors, and I think much of the problem was that of getting over the hump of "all of the people who've worked heavily on this codebase disappeared at once." I think it might not have stalled in the first place if there were a couple folks outside the company who had been doing regular work on the platform. I still feel like our bus factor is a little low wrt to hacking on core, but I'm hopeful that we can get to a point where there's enough shared knowledge that we won't end up in quite that kind of slump again.

In fairness, this did come a bit later; it was there for quite a while before the company shut down, but when I first showed up I had a similar wtf reaction since at the time it was just GitHub and Google. But yeah, that was fixed a very long time ago.

It's possible to log in with just an email address; you don't need to use GitHub or Google. There's an FAQ entry about this too:

https://docs.sandstorm.io/en/latest/administering/faq/#why-d...

Though that doesn't address the intranet issue of course.

At the time sandcats took some of that burden off, so you could still self-host without having to wrangle with the cert stuff yourself:

https://docs.sandstorm.io/en/latest/administering/sandcats/

...but yeah, now that let's encrypt does wildcards it'll be easier to do it on your own domain. I'd like to see sandstorm have some nice integration for this in the future.

(sandcats still works of course, and is still a good option to get started if you don't want to mess with DNS and certs right off the bat).

Yeah, I don't think I've ever encountered an ISP in the US that didn't give you a public IP. Maybe they exist?

You only get one, so you typically NAT everything, port 25 is blocked and often port 80 is as well, but that's about it.

It's definitely easier to deal with when using a debugger. But that brings a question to my mind: Why are there so many debuggers that make inspecting the results of intermediate expressions difficult? I should be able to step through my code at a finer granularity than a statement.

Re: self-documenting, certainly sometimes (I mean, you shouldn't play code golf...), but in this case the code in question was:

    2218         if (!valid_localpart(maddr->user) ||
    2219             !valid_domainpart(maddr->domain)) {
    ....
    2234                 return (0);
    2235         }
    2236
    2237         return (1);

It's not obvious to me what you would name the intermediate booleans that would be more self-documenting than the function names used there.

Re: the language feature: This is standard in ML-family/typed functional languages (OCaml, Haskell...), and lately has been being adopted by a lot of newer languages, including Rust and Swift.

My first full time job was at a university, and we had a lot of student interns, most of them not native speakers (lots of chinese students especially). What I've found is that it wasn't worth the trouble to correct every grammar mistake; if a commit message was understandable and had useful content, I'd usually merge it without bothering to correct botched plurals, wrong prepositions, and other mistakes that the students made regularly, as long as it didn't hurt understandability. I found that getting them to write good content wasn't a problem once we made it clear that this was expected (and it wasn't really easier with the native speakers).

Communication in software development is a huge deal. While language barriers are a thing, I don't think you can or should compromise on documentation, and when it comes to commit messages I don't think this is the leading reason why folks don't write good ones.

I'm told by friends who were at RedHat when they decided to make the source repositories public (as opposed to just throwing release tarballs over the wall), and commit messages went way way up. This tells me: people knew better, they just didn't care if they weren't being held to account.

Fossil[1] integrates a bug tracker & wiki into the repo proper, and I agree that it would be good for these to just stay pinned together in general. I'm kinda sad that git has basically "won" the SCM wars in the FOSS world; a decade ago there was a lot of interesting experimentation happening and I feel like having a winner has caused that to stagnate.

Re: Email being an inaccessible silo: communities that use git-format-patch/git-am usually use mailing lists, which are archived, and subject lines have [PATCH] in them so searching needn't be difficult.

[1]: https://fossil-scm.org

Fwiw, I think what's important about homoiconicity isn't so much that the language uses "boring" data structures for its (intermediate?) syntax tree, but that the both the syntax itself and the representation of the syntax as an AST is simple and obvious.

Haskell has TemplateHaskell, which can be used for macro-like things, but it's substantially less ergonomic, not because Haskell isn't "homoiconic", but because the grammer is actually really complex and non-obvious. There's tons of little things that you don't think about when writing Haskell code, but you have to deal with when manipulating it. For example:

https://hackage.haskell.org/package/template-haskell-2.15.0....

That's a node in the AST that stands for something that is at most one character in the source text, and usually zero. So code manipulating this stuff gets really verbose and clunky. It's still powerful, but it's not the same.

As a side project, I'm actually working on an ML-family language with a macro system. It still has a more traditional ML-style syntax, but it is simple so working with it should be comparatively ergonomic. In an ML you wouldn't frequently want to be working with loosely defined data structures anyway; the first thing you'll do is convert it to a more strongly typed form that captures what you really want to be manipulating.

I've been using vim for roughly half my life at this point. What I've found is that actually using the editor is so thoroughly muscle memory at this point that using another editor, where I actually have to consciously think about how to do something, is incredibly distracting.

It's not like the difference in input speed is really meaningful; as you'll see someone point out in any discussion about this stuff, the bottleneck in programming is thinking.

But what I find will often happen is:

1. I settle on a course of action. 2. I go to actually do it. 3. The editor doesn't do what I expect, because it's not vim. 4. I am momentarily confused, and have to think for a minute about how to do what I want. 5. I lose my train of thought entirely. 6. Rinse, repeat.

So for me it's not so much about any specific thing the editor does to make me productive. I do have opinions about some things, but what's important is that it just fades into the background and lets me think about the problem I'm trying to solve.

Beyond just being "different," I tend to eschew IDEs for much the same reason -- while many of the advanced features seem useful, I find them too distracting to be worth the trouble. Just me and the code, please.

Except that Nix doesn't manage your home directory! (though some folks have put together some less-than-prime-time solutions).

That's actually something that's a major hole for me; it would be like twice as useful if it did. But yeah, my solution is just: https://github.com/zenhack/vim-config

As others have pointed out, if they weren't distributing source and passing on the license, this is a blatant copyright violation, and what they were (still are?) doing is illegal.

If you're at all interested in doing anything about it, copyleft.org has a bunch of useful resources.

> but it’s not universally applicable either.

Nothing is universally applicable.

But yeah, I certainly wouldn't use it for hard real-time tasks. If you can't tolerate missing deadlines ever, there is a very short list of acceptable tools.

But (and correct me if I'm wrong; it's not my area) HFT doesn't strike me as hard real-time? See also a sibling comment that asks about Jane Street's OCaml use.

It's not like GC pauses are happening constantly; Go programs don't allocate that much, and a well tuned program can go a long time between collections. It likely is appropriate for many soft or firm real time systems. And you can shut the GC off if there are sections where GC really must not happen:

https://golang.org/pkg/runtime/debug/#SetGCPercent

Re: pause times, Go's garbage collector is actually really good here; you're looking at 10s of microseconds.

I'm convinced the term "systems language" doesn't have a coherent meaning at this point. See:

https://zenhack.net/2018/07/14/three-funerals-in-the-name-of...

I was having a similar experience earlier this year, so I reluctantly did the same for a while. I got sick of chromium though, really missed reader mode for one thing, so I decided to put in some more effort to troubleshoot.

For me what did it was switching to wayland (sway[1] specifically, from dwm on x11). Now it's a good step faster than chromium.

I agree with the sibling comment; there's something wrong going on, what you're describing isn't firefox's baseline.

[1]: https://swaywm.org/

> If you choose one of the more generic ones, now it takes more mental steps to collapse the indirection when reading it. (1. I have a Maybe Int. 2. This function expects an `s`. 3. `s` is constrained by `Semigroup s`. 4. Can I pass a Maybe Int to something expecting a Semigroup?

Semigroup doesn't involve higher kinds at all. What you seem to be discussing is either type classes or just a pile of junk from abstract algebra. Fwiw, Elm has semigroup too -- it's called appendable (which is a much much better name...).

> Learning curve is a very high cost by itself; HKP is the reason Haskell is notoriously difficult to learn.

I don't think any one feature of Haskell is why it's hard to learn. I think the reasons are much more mundane, the main ones being:

1. The language is just enormous. It's a lot to need to have in your head to understand some bit of code you come across. Folks end up picking a (small) subset of it just to stay sane, but this doesn't help you when trying to come across a new library; you basically need to have most of the language in your mind somewhere to understand $RANDOM_NEW_LIBRARY reliably. And because it's an issue of sheer size, there's no short-cutting it. It has a lot of features with heavy overlap in use cases, so you spend a lot of time thinking about silly things like "Should I use FunctionalDependencies or TypeFamilies?" "I'm writing a library that needs to generate a bunch of boilerplate code, should I use GHC.Generics, TemplateHaskell, or something else?".

2. The community is really lousy about pedagogy. They tend to lead with the abstraction, which is just not how people learn. I really wish this[1] had been written like a year earlier; it would have saved me a lot of trouble wading through useless instructional material trying to learn this stuff. It doesn't seem like the bulk of the community took that to heart though, and while there are some good learning resources out there, there's a sea of worse-than-useless ones.

3. There's a culture of complexity/over-engineering. I don't think this is unavoidable, but it's particularly a hazard of being research language where to a large extent the whole point is to play with crazy ideas. The maintainers still see the language as primarily a platform for experimentation, so KISS can be a hard thing to push for.

> and it seems like it must be pretty steep if you stack up languages with HKP and their quality of error messages and docs against other typed languages that don't.

I'm not really sure I buy this; I think the list of languages that have these things and have seriously made good error messages a priority is pretty short (empty?). I can point to some simpler ML dialects that still have some really lousy error messages.

[1]: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

Yeah, I've read the STG paper, though its been a while. IIRC there isn't a call stack as we'd normally think of it, but there's still a stack of pending pattern matches, so you actually do hit the same issues. I vaguely recall making deep recursion "just work" in GHC was something that happened just in the past couple years.

> * Laziness and higher-kinded types are both features with costs that significantly outweigh their benefits.

> It sounds like you disagree with the last bullet point. If so, then either we've had different experiences or we walked away with different conclusions from them.

I more or less agree on laziness (at least lazy-by-default; having a lazy type as found in OCaml available is a big win for little downside).

Re: Higher-kinded types: I'm curious as to what you think the high costs are? My impression is that they've mostly been left out of Elm due to pedagogical concerns. Is it just that or are there other things?

You can turn off overcommit, in which case you'll get a null return instead of OOM killing.

But also, you can still get a malloc failure without actually be running out of memory if the allocator can't find a big enough contiguous chunk of address space.

This is highly unlikely on a 64 bit system, but if you try to malloc gigabytes on a 32 bit machine you might see it.

> you can not get referential transparency with mutable variables

Sure you can: https://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.ht...

Rust's ownership types and lifetimes actually allow for this just fine. The latter is the essence of how Haskell's ST Monad works; you can use lifetimes to get locally-mutable state without violating global invariants, since once they go out of scope they can't be reused.

It's interesting to observe that, without "magic" standard library functions and `unsafe`, Rust's type system actually completely constrains mutability, and if a function doesn't have `mut` somewhere in its type signature, it doesn't break referential transparency.

That said, in practice, the language does have magic functions that violate this property, and they do so in a way that means you can't use the above reasoning principle at all. Also, mutability being constrained by the types is not the same thing as typical code not using it everywhere, which is the situation with rust-as-found.

Don't get me wrong, I like Elm a lot, but the drop in expressiveness/ability to build abstractions from Haskell is substantial. Especially when you're looking at modularity, there are a bunch of things that Elm can't abstract out that both Rust and Haskell can manage just fine.

I haven't used Rust heavily enough to comment on how it compares in great detail, but comparing to Elm as a proxy for Haskell doesn't really work.

Frankly, paradigms are a really lousy way to think about languages. I wrote a series of blog posts about this[1], but this opening lecture from one of Brown's PL courses I think does a better job of making the point:

https://www.youtube.com/watch?v=3N__tvmZrzc

It's useful to talk about what say, GC, laziness, lifetimes, ownership, typeclasses/traits, higher-kinded types, higher rank types, variants, elm-style records, etc. do to a language, and how they compose, but I think you can't go very far talking about how "paradigms" compare.

[1]: https://zenhack.net/2018/07/14/three-funerals-in-the-name-of...

It isn't a matter of memory usage; the memory usage is still linear in the size of the input regardless of the depth. If an attacker can get you to oom by feeding you a deeply nested data structure, they can do the same with a shallow one just as easily:

"[0, 0, 0, 0, 0, <...gigabytes of zeros>, 0 0, 0, 0]"

So you need to limit the overall input size regardless of whether you already have a depth limit in place.

I'd argue this is a pitfall that languages can and should solve. There's no reason why writing a naive recursive descent parser should cause this problem. The fix, using a separate stack data structure, is telling, since it's the same algorithm, with the same space complexity, you're just saying "my language's call stack isn't a usable implementation, so I need a different stack." Why not just fix the call stack?

In languages like rust/c/c++, this might be hard, since you can't grow the stack by moving them (since you'd need to update pointers, which are too visible in those languages, and even identifying a pointer at runtime is undecidable), and segmented stacks cause the "hot-split" problem.

But most languages could just make this problem go away by growing the call stack when needed. A few of them (incl. Haskell) do. I'm following suit in a language I'm working on.

I kindof wonder if this isn't one of those things that falls flat because it's a toy example, and anything but the most direct approach is going to look clumsy and over-engineered.

I've spent a bunch of time working in Elm, though I hadn't used it in anger before they dropped the FRP stuff.

My experience with post-frp Elm is that:

* It seems really elegant on small examples * When you start working with larger codebases, and you have some resuable UI elements you want to build, you end up writing a lot of "routing" code to shunt messages to sub-components. Conventional wisdom in the community is to try to keep app structure as "flat" as you can to avoid this, but I've not seen a codebase of meaningful size where this doesn't happen enough to be annoying.

I have a gut instinct that "real FRP" might shine a bit more at this point; it seems like it would make wiring together different bits of the UI easier.

Wait, is Arch back to being a hipster thing? I thought we'd graduated to well-known distro.

I've been using Arch since '06, back when Judd was still in charge and the repos were divided up in terms of "stuff Judd maintains" and "stuff other devs maintain." It was this small community project that nobody had really heard about, and I got so used to it just not being a thing that when (sometime in the range of '10 - '12?) folks started talking about it as a hipster thing, it really took me by surprise. A few years later it seemed like it was just one of the more well known "hands on" distros with great docs, and I was glad to have that phase be done with.

Perhaps -- it would be easier to scruitinize if the OP cited where their numbers came from. And given that the undocumented immigrants number is still off by more than a factor of 2, to me it reads more like it's just reactionary nonsense heresay rather than having any actual basis in reality. I'm open to being wrong though.

Also:

* I don't see any reason to believe nobody has more than one "cultural identity."

* Race is really more about culture than biology too. Maybe less so, but if for some reason you were motivated to come up with some categorization of people based on their biological ancestry, the races that we talk about wouldn't make a ton of sense. When you hear people saying that race is "socially constructed," this is what they're talking about. The Irish weren't considered white a century ago, and it's not like the change came about due to some scientific breakthrough.

I suspect part of the reason others are downvoting you is:

1. It's too much suspension of disbelief for them to think that he really could not have been expected to figure this stuff out on his own. 2. Your comments are also lacking any clear acknowledgement of the real harm here, which makes it read like you're just trying to use that link I posted as a defense for him, without engaging with the details of the situation.

I'm not sure how fair I think that reading is, and I think your own explanation for the downvotes is also part of the picture -- but not the whole picture by any means.

Specifically re: this bit:

> is equivalent to supporting toxic patriarchy rape culture or whatever. Really we just don't want to be dragged into their monkeysphere games

What I think this misses is that, regardless of intent, outcomes matter, and by making excuses you do make it easier for the injustices to continue, whether you mean to or not. A lot of guys have a really knee-jerk reaction to the term "rape culture" but the idea it exists to articulate is actually really important, whatever you think of the choice of expression: There are lots of behaviors far short of committing any heinous crimes yourself that add up to contribute to a society where these crimes are allowed to happen. Ironically, this quote commits the same lack of willingness to look past an gripes with the way an idea is presented and actually engage with the idea that lots of folks are pointing to in the reaction to RMS's statements.

I can't prentend to be able to see perfectly into RMS's mind and say what was really going on. It's certainly the case that management (of both MIT and the FSF) enabled him, but I don't think that totally absolves him. But I'm also not really interested in judging him one way another. I wish it hadn't had to come to this, and I hope he learns something from it and makes good use of the rest of his years. But ultimately I'd like to just move forward and keep trying to make things better -- ideally we build an environment where the next guy gets it into his head early on, doesn't make folks miserable for decades on end, and gets to keep his job; everybody wins. But to do that we need to be willing to acknowledge that there was harm here, and not just push the one side of the argument.