zenhack

So, from an executution model standpoint Rust is pretty close to C++ -- manual memory management, with RAII as the usual strategy for managing things. The big novelty is that the type system actually enforces this, so you can't have dangling pointers, or forget to close a file, or...

But most languages have had a solution to the resource problem at least as far as memory is concerned for a long time: garbage collection. It has huge advantages over Rust's approach, in that you can basically not think about RAII or ownership at all; as long as you're not actively holding on to an object, the memory will get reclaimed for you.

But this doesn't solve the problem for other resources like files, since when a file is closed actually matters semantically. You don't want to just let the garbage collector decide when to shut down a tcp connection.

So what the gp is suggesting is, it would be nice to have a language that uses GC where it makes sense, as it's generally easier to work with, but also provides sane mechanisms for releasing resources like files and sockets.

Weren't the ME vulnerabilities remotely exploitable? If so that's not the same at all as what we're talking about here.

I kinda balked at that too, but I think what the author was getting at is their scarcity is "real", in the sense that unlike fiat currency, there's nobody who can just print more whenever they see fit. I don't really agree with equating scarcity by itself with value, but when comparing to fiat currency, it makes some sense.

That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.

HKT would somewhat ease the type signature question; as I understand it in the rust community being able to parametrize over ownership/mutability is the big selling point that gets discussed. You could instead have a single Fn<Foo>, and stuff may require Fn<mut> or Fn<const>, rather than a separate FnMut. There's no keyword now, but owned could be part of that dance too. There's obviously the question of how to deal with backwards compatibility though.

There are more convenient ways of composing monads than monad transformers; extensible effects are a lot easier to work with.

Ulttimately I agree though, monads are not the right abstraction for a systems language. I'm quite happy using them in languages like Haskell and OCaml, where you've not only got a garbage collector solving the tricky ownership qustions for you, it's also faster than it has any right to be, so you can basically ignore the overhead of heap allocating a closure.

They become much less attractive when you're in a problem domain where you actually want to worry about fiddly details around memory allocation. This is much smaller space than people think it is, but it's what Rust is for.

There's definitely a lot of syntax that makes the language look bigger than it is. When I realized Rust's oo-style dot notation/self/Self was just sugar for plain old function calls, suddenly a big chunk of the language I thought I hadn't learned yet turned out not to just not exist.

One of the earliest memories I have of really enjoying math was a unit on modular arithmatic from my 6th grade math class. The teacher introduced the concept with a hands of a clock metaphor, gave us a whole bunch of drill problems, and told us to watch for patterns. We had an easel in the class room where he collected the insights students had gained. Discovering the relationship with remainders by ourselves was incredibly cool.

Having another interest to tie it to (especially if it's something you're more comfortable with) is huge. I have a CS degree, and for me, what bridged the gap into being comfy with "pure" mathematics (and appreciating it outside of any specific application), was my theory of computation class.

Webfinger, which the activitypub standard builds on, gives you something like this, but ultimately the provider has to actually support webfinger. This was a neat hack though:

https://github.com/bradfitz/webfist

But it never really went anywhere afaik.

I don't think not knowing enough about computers to realize that "delete" doesn't actually delete the data qualifies someone as an idiot.

It's worth noting that while monads themselves naively introduce a data dependency, that doesn't necessarily force evaluation order. If the compiler is smart enough and sees something like:

    foo >>= \_ -> bar

It is well within its rights to evaluate bar and then foo, or do both in parallel, or not evaluate foo at all, as long as it can guarantee that the resulting value is the same. The big thing it needs to be careful of is not to introduce nontermination.

What makes this do the right thing for effects is what values of type IO actually are, and what bind means specifically for IO. It's helpful to think of an IO value as code in another (imperative) language. Bind takes two fragments of code in that other language, and stitches them together into a script that executes one after the other.

The key thing is that the order in which you compute parts of the script is entirely orthogonal to the order the commands appear in the script.

In Haskell, evaluation does not cause side effects, period. `main` is a value of type IO, which is executed when the program is run. The effects of that execution are independent of how the value `main` is computed.

Obviously, the computation itself takes time and space though.

Yeah, this is Haskell's biggest footgun by far. The language gives you tools to control evaluation order (including some neat libraries that let you parallelize things without much disruption to the logic of your program), but there are no silver bullets.

A good rule of thumb is to by default mark fields for basic types like Int, Bool, etc. as strictly evaluated, and leave larger structures (trees, lists, etc) lazy. But you still need to be careful.

The compiler trying to silently fix things is probably a bad idea. The current behavior is at least easy to understand; I'd hate to have a program that's working because the compiler could figure out that it could make something strict, and then I bump something mostly unrelatrd such that the optimizer can't be sure anymore, so I get a space leak.

Also, unintended evaluation can potentially cause high memory use as well (e.g. [1..1000000]), so the compiler also has to be careful about introducing excessive memory use.

The compiler does do some strictness analysis, but it's a hard problem.

I like the way idris does things -- strict by default, laziness controlled by the type system, and some nice support for automatic coercions.

One big advantage of stack machines is that they tend to be better on code size, which very much matters when you're transferring code over the network. I expect other parts of the design make it easier to JIT; the lack of arbitrary gotos probably makes analyzing control flow easier, for example.

Worth noting, gopherjs has been around forever, and is mature:

https://github.com/gopherjs/gopherjs

...and already has a reasonable js interop story, whereas my understanding is that calling the dom api from wasm is not the simplest thing.

I hadn't previously looked at lattice crypto in much detail, and was not aware the keys were as big as they are; thanks for pointing that out. That said, a big performance hit isn't necessarily the same thing as being practically unusable. It certainly explains why nobody's using it now. I'd be curious to read some concrete performance analyses.

A sibling comment points out one use case for symmetric-only crypto.

I'm also curious what people would actually do if forced to deal with a symmetric-only world.

I think it is more likely that we'd see cumbersome ways of dealing with key distribution than that people would just stop using crypto in all the places we rely on public key schemes today. Think symmetric keys printed on your bank statement (maybe with a qr code?) We'd definitely see it used a lot less than now.

That said, we'd probably have about the same number of people doing end to end email encryption; key distribution with an asymmetric scheme is no picnic either :P.

Quantum computers do not break "all known practically useful cryptography".

For symmetric crypto, some schemes will have to be dropped, and others will require larger keys. But we can (for example) just keep right on using AES 256.

For asymmetric crypto, we'll have to switch to some new schemes, but those exist (though I don't know of any current software using them). For example:

https://en.m.wikipedia.org/wiki/Lattice-based_cryptography

The bigger worry I think is what about all of the existing traffic that has been archived?

First, I'll point out that this is not a "liberal" thing; polling has revealed that republican voters are by and large for keeping the net neutrality rules as well. This isn't a left vs right issue, it's basically big ISPs vs most everyone else.

Second, and more to the point, internet service is generally much cheaper in other countries, but the reasons are most definitely not lack of regulations. It basically comes down to local monopolies, and the usual effects of lack of competition. Giving large ISPs more power will not help. This article gives a decent overview of the situation:

https://mobile.nytimes.com/2014/10/31/upshot/why-the-us-has-...

This was posted to hackernews a couple months ago:

https://arstechnica.com/tech-policy/2017/12/att-says-it-neve...

As the article points out the kind of abuses people are talking about are nit theoretical; they were done before the 2015 rules went into effect. This was especially true on mobile plans.

Another thing is you can look at how this has played out in other countries, and it isn't pretty. There's an image floating around of an ad for a Portuguese ISP, which looks like a cable tv add from the 90's -- explicit lists of sites that are provided.

It's hard to study this kind of phenomenon with the level of rigor we'd expect from a physicist. That sort of thing is kinda the best you can do.

Finally, I have friends who work at companies who do larger scale traffic analysis on the net, and from what they've told me, at least before the 2015 rules, throttling was basically the norm, though you'd be hard pressed to get the pr departments to admit it.

If you're at all interested in taking the red pill: elm and reason/ocaml are some things worth checking out. There is so much more out there than the C family tree.

Ah, point. That would probably need to change to relax the one mutable reference constraint, if you wanted to.

I will contest the idea that you don't want static typing for web dev. Curious, what statically typed languages do you have experience with? I ask because you only mention C# and Java, and I often find people who form their ideas about types from those languages think they have to be much more cumbersome than they really do.

Lots of (most?) rust libraries are "not thread safe" in the sense that those data structures aren't though. The reason this is ok is that to actually share a piece of data across threads it needs to implement Sync (which requires unsafe).

Also, as a sibling comment points out, the "thread safety" guarantee is relatively narrow -- it won't guarantee a general lack of concurrency bugs any more than a gc will guarentee reasonable memory usage.

I haven't thought through the details, but I suspect it's possible to adjust the semantics of rust in a way that allows multiple mutable references without sacrificing memory safety.

What you would hit is that the compiler would be hindered when doing optimizations in the same way that c and c++ compilers are, because of pointer aliasing.

There's a trade off there, and I think you can make the argument either way.

The type system is probably not the bottleneck in any of those cases. As a sibling comment points out, ocaml has very good compile times, and the inference problem is basically the same as in Haskell.

In the case of rust, I suspect one of the biggest issues is the way parametric polymorphism is implemented. Basically, if in your program you end up using e.g. Box<usize>, Box<MyType> and Box<Result<String>>, you're compiling Box 3 times.

I don't know enough about swift to hazard a guess as to where the build is spending its time.

My experience with Haskell is that compile times are neither great nor terrible.

People do tend to have a mental block where the possibility of fixing one of their dependencies is something that wouldn't even occur to them. To the point where they'll implement really complex workarounds in their own code instead of submitting a one-line patch (or sometimes even reporting it).

That said, as someone who is no stranger to contributing to upstream, the prospect of becoming the maintainer strikes me as something that is certainly not to be done lightly.

Yeah, legacy is probably an entirety different beast.

I think the hiring woes problem for languages like this is a reasonable hypothesis, but I've never seen any actual evidence for it. I constantly hear from folks who are worried that they will have this problem, and frequently hear folks saying they tried it and it wasn't a problem (see sibling comments, for example). I'm not sure I've ever heard from someone who has actually had this problem.

Yeah, but there are also often a lot of things that just genuinely don't make sense anymore. Xterm is packed with support for an insane number of old tty devices that no one needs. There are plenty of terminal emulators that successfully skip all that and no one ever complains.

I don't know of a magic formula for being able to tell the difference, so it's hard thing to talk about in the abstract.

I'm looking at this on mobile, and the cookie policy footer is taking up more than half the screen. Oh the irony.

It does. I also don't have flash installed, which probably helps. Can't remember the last time not having it caused a problem; good riddance.

rmrfrmrf made an allusion to this below (which I also linked to in another nearby comment):

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

The short version is: don't stare at explanations trying to grok it. Start hacking and keep an eye out for patterns.