bjeanes

I totally agree. Ridding yourself of nils via the Maybe monad offers incredible abstraction potential, but would feel out of place in Crystal's Rubyishness without deeper thought into bringing other monads into play too.

Nonetheless, I am thrilled that we are seeing more and more languages that don't have implicit nullability on any type.

Thanks for linking to those RFCs. The planned or in-progress work for Rust compilation speed is very exciting. I can't wait to reap the benefits!

They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.

I came across this a few months ago and ignored it for similar reasons: the homepage doesn't talk about the fact that nil is a type not a value (which is AWESOME, btw). It wasn't until a coworker encouraged me to dig into the docs that I realised Crystal is actually pretty sweet.

I recommend stating something like "No unexpected nils at runtime" and for those curious, a link for where to read more. Not having nil is basically the most important feature in most new languages I take the time to play with. Now that I know Crystal treats nil responsibly, I'm really keen to start playing with it.

I too would encourage people seeing the parent comment to definitely watch those videos. The Rich Hickey talk especially has shaped a lot of my thinking in the last few years.

I have long held the same opinion as the parent comment and even attempted to build it myself a few times, but I hadn't seen qute, and I think I like that approach even better. Well, a hybrid; the paragraph currently being edited could be highlighted as markdownify does.

The feature does or did exist, but hidden. The early versions of GitHub Enterprise (called GitHub FI) exposed this and it can be seen in action in some places (e.g.: https://github.com/ghc; look at the "mirrored from" subtitles). I really wish GitHub would expose that feature publicly, though. The post-receive advice they give only works if you have full access to the master repo and misses out on recording the "this is a mirror" piece of metadata on the repository, which is useful for people who might try to open PRs etc

This reminds me of Waleed Aly's fantastic talk on Ethics & Technology in which he explored multiple ethical implications of self-driving cars.

Unfortunately, I can't find a recording of his talk (which I saw at Above All Human conf a few weeks ago) but here's an article about it, which may or may not capture the essence for other interested people: http://www.afr.com/p/tech-gadgets/see_an_ethicist_first_wale...

Hrm... he deleted that tweet :/

I assume you are talking about http://goodfil.ms/?

Yes, but importantly, only with firmware 33 or higher. I have 32.0 :(

AIUI, for security reasons YubiKeys are not firmware upgradeable.

Additionally, if somebody removes the token, dumps a bunch of OTPs and then puts it back, as soon as you use the token once, it will invalidate all previous ones so their dump will be reasonably useless. I leave my key in my computer when I'm at my desk but have it attached to my keychain so that I take it with me if I leave my desk.

> Isn't mutable variables the most obvious way to solve these problems?

Yes, but the mutation can be entirely limited to the reference. The data structures do not have to be mutable. It's a trade-off, of course, because you can't pass somebody just part of a data structure (like a sub-map) and have them mutate it there, but I think Clojure has shown that in practice this isn't really much of a loss.

You don't have to mutate them. You can create a new persistent variant and just mutate the ref to point to the new one. Users of that "variable" store the ref instead of the value (well, actually, they get the choice of which to do). If users have held on to references to the old values, the GC doesn't collect them. If they haven't, the GC can collect them just like any other circumstance involving persistent data structures.

> Structure-sharing of the persistent structures, for added efficiency/performance

I think the structural sharing is the definition of persistent data structures, as distinct from immutable data structures in general.

You can write to the file system, it's just not persistent across dyno restarts or shared across running dynos. Writing out for in-request work is fine.

I'd never thought about this before in the context of Java. IIRC, Java can not have type-parameterized enums (i.e. generic enums), so a Maybe<T> isn't possible. I hope I'm wrong — it's been a while since I did much Java.

I loved reading this the other day. Thanks again for writing it. I'll be coming to this post often, I think.

Salesforce's Apex language is case insensitive. It leads to a a lot of confusion, frustration, and distress when different programmers have their personal preferred style of referring to a class or var or when the lazy ones just write everything in lowercase. Never again.

And just like that your wallets aren't anonymous anymore or at least are tied to each other beyond transactions between them.

Seriously, though, this is kinda neat.

> Then, tap the "y" key to jump to the last commit found for that region.

That's not actually what happens. Pressing "y" resolves the current reference (master, some tag, whatever). It has nothing to do with what you select, you're just following the pointer that is the current ref.

For reference, the Clojure rewrite is https://github.com/zk/clojuredocs and is hosted at http://clojuredocs.herokuapp.com/

Haha I saw this happen today, actually. Painful.

Exactly what I was going to say. This seems like a good design decision, especially because the typealias hack offers a work around if you really need to.

> The top 2 money recipients are 2 feminists which have never seen a line of code in their lives (one of them doesn't even have a github account!).

That is both irrelevant and entirely incorrect. Both have seen and worked with code and both have GitHub accounts. Their relationship to code has nothing to do with the fact that people feel it's worthwhile to donate money to the work they contribute to their chosen communities.

> The main problem with the argument is that our body does a great job of fixing errors - so why does that process suddenly seem to stop? Why not just keep on fixing errors. If you can fix errors for 40 years why stop there? Why does the process suddenly stop at that age?

Because then you compete for resources with your offspring and limit the chances of passing on your genetic code.

I previously just switched my SIM back into someone's iPhone and used toggled iMessage on and back off again before switching the SIM back again.

> Aside from the 'wow, intelligence', why is it that those of us with spines lack any 'computing power' in things like our arms? Are there any common sense reasons?

I wonder if the fact that we can't grow them back is a factor. I could imagine that this would make it hard for us to evolve any sort of appendage intelligence that was important to our function.

That does suck, but there is `reattach-to-user-namespace` in homebrew which keeps the tmux server from doing that