damncabbage

Relative to Ruby it has more upfront checking of some things. In Elixir, calling a function that doesn't exist or with the wrong number of arguments is something that will error out at compile-time; with Ruby, you don't find out until you run the code with the bad call.

I agree, though, that compared to Haskell and Rust it doesn't give you much. Dialyzer is (intentionally) a fail-open checker that doesn't allow expressing generics; I've had a rough time getting it to tell me my code is wrong. Credo is (intentionally) just a style linter. "Just let it crash" isn't useful when you're talking about code that is going to break because of its structural incoherence (a class of errors type-checker are good at catching), and not because of transient errors in external dependencies.

> It falls short on many things TS would immediately flag

I'm kind of curious what you've run into personally. Having a dependency without any type-defs get silently treated as `any` is my own beef, but I haven't hit much else yet.

(Some type-defs' use for `any` also gets my goat, such as Promise's catch argument and some of the lodash functions, but I'm considering that a separate thing.)

​

> And honestly, some of the decisions around the language just feel strange. Not knowing what kind of bool to use [0] is pretty emblematic of where it is going as a language.

This is more an existing JS weirdness (`true`/`false` vs `Boolean()`); Flow doesn't mess with runtime semantics, only adding a layer that you check with then strip out.

And TypeScript has the same thing:

  var a: boolean = new Boolean(1);
  
  // Produces:
  // NewTypering.ts(29,5): error TS2322: Type 'Boolean' is not assignable to type 'boolean'.

It means restricting to where you can perform IO actions, eg. printing to a log, writing to a shared area of memory, etc.

Haskell does this by representing IO actions as values, eg. "IO String" (something like "IO<String>", for people more familiar with that syntax), representing an IO action that, when later evaluated, will yield a string that you can use in subsequent actions.

Haskell's "main" (entry-point) function is a value of type "IO ()" (IO of a value representing nothing useful; you don't get anything out of it, so you just have a nothing placeholder). When a Haskell program is run, it ostensibly (hand-waving here) takes that IO value and interprets it, performing the action IO.

You have functions like putStrLn (print a line) that takes a String, and returns an "IO ()" . Accordingly, if you have

  main = putStrLn "Hello, World!"

... you have a value that lines up with the expected return value of main "IO ()". More complicated examples, like

  main =
    readLn >>= (\x -> putStrLn ("Hello, " ++ x))

... are doing the same thing (checking the types line up), just with more moving parts (the Monad thing you mentioned, which we're using to relate the "read line" function with the "print line" function).

The key bit is that it's just "IO Blah" values standing in for IO actions, and like jigsaw pieces, these IO-returning functions only fit together where the types line up, restricting how you can use them.

Monads are tangential to this; the type-checking of that jigsaw puzzle is what matters here.

A list of items in an array. Some items in that list are of particular note.

(Say you have 15 items in an array. For whatever reason, such as you not being in control of the expected input structure of whatever you're giving this JSON to, you have them grouped with comments at the top of each block.)

> I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.

As someone who's standing on the precipice of GHCJS, Haste and PureScript, I'm very curious to hear about your Haste experiences in this regard.

(I've been using PureScript in my side-projects for a bit. For the sake of completeness of this list, I've tried Elm and am not interested.)

Agreed; HipChat is unfortunately a bit terrible about this. I'll often "lose" a notification from someone when I'm offline: it sends an email, yep, but the chat client itself loses the "unread message" bubble. I have to make sure I check email on every reconnect.

I'd be cautious: the range is too small for me (6'1" / 188cm). On a regular desk that suits me, it doesn't go high enough, and if you prop things on the desks up a bit, you then need to remove them when you lower it.

(It's also a bit wobbly, which isn't great, but probably expected.)

> ... being signed in is in-memory state.

Can be in-memory state. Everything beyond toy-sized I've ever worked on has externalised this sort of state to a database of some kind, if only so you can run a second copy for the sake of failover. I don't believe your example is relevant.

To just see the content on the page, paste this into the console:

    $('body').append('<style>.lesson,.post{visibility:visible;}</style>');

(I enjoyed reading the content, but found it infuriating to skim.)