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.

> I checked out our shared Twitter history, we talked a fair bit in the past but I wasn't able to find _anything_ like this.

> I mean this sincerely — are you _sure_ you didn't get me confused with someone else? I was definitely a dick from what I can see from the Twitter history and I apologize. However, I cannot remember and cannot find myself ever saying or implying something as horrendous as what you're describing here.

https://twitter.com/bitemyapp/status/477359528510382080

  [@bitemyapp] @KirinDave my first workflow video is up to 
  1,535 views on Youtube so far. Who knows how many people 
  have used my guide. I'm feeling good.

  [@KirinDave] @bitemyapp It is not about your traffic, it is 
  about their excitement. Get over yourself.

  [@bitemyapp] @KirinDave Drinking the haterade tonight. Some 
  of those pregger hormones transfer over?
  
  Should ramp up theft of Clojure library authors >:)

  [@KirinDave] @bitemyapp Yeah I'm hysterical that's real cool.

That covers a portion of the claim. (I'm trying to stay out of actually passing judgement on bitemyapp or his ">"-quoted defence or KirinDave's earlier claim.)

I don't think it needs judgment passed, that was shitty! Thank you for finding this.

Dave: I was out of line and there was no point for me to be dick-waving with you like that. I can't say it's possible for me to read everything you did into what I said, but it was a shitty thing to say regardless. I apologize.

There's also comments support in Flow directly, but it's sadly (but understandably) hideous:

  function somefunction(somestring/*: string*/)/*: boolean */ {
     var ret/*: boolean */;
     ...
     return ret;
  }

(See https://flowtype.org/blog/2015/02/20/Flow-Comments.html)

> 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'.

TypeScript's full error message on that last one is actually

  Type 'Boolean' is not assignable to type 'boolean'.
    'boolean' is a primitive, but 'Boolean' is a wrapper object. Prefer using 'boolean' when possible.

«Having a dependency without any type-defs get silently treated as `any` is my own beef»

You can add the compiler flag --noImplicitAny to get errors if you prefer.

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.)

Why would you want to do that in what is basically a human readable binary file and not in a readme?

You seemed to stop at the for who and for what purpose.

I can 'just' about see the case in something like nodeJS package.json files (that is the least of nodeJS's problems, but that's a whole other conversation). But a readme is a so much better option than having to troll through code comments.

The discussion above concerns why JSON isn't a good choice for configuration files. That's exactly because configuration files are not human readable binary files.

TBH. I find package.json files to be much much much much nicer files than configure.sh or settings.txt files, even a configure.py.

And if that isn't the case for you, not like you don't have the choice.

> 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.)

I really want to like Haste. It supports nearly all features of GHC, it works with Cabal, it produces small output that can be understood/debugged. Its runtime is only 500 lines of clean javascript. I was able to build a toy app that shared code between client and server and let me use my existing tools to work on it (Hdevtools et al.). For awhile a nice react library was in development for it.

But... its lack of support for TemplateHaskell and native code means that a lot of firewalls/shims are required to share code with likely server programs. There is no support for common library types such as Text and Aeson types - ghcjs has shims for those that build without native dependencies. react-haskell library switched to ghcjs because the Haste ecosystem/development community is non-existent. And I would probably not build a serious project with Haste for the same reason.

ghcjs is nice but...it is too big in so many ways. The runtime footprint for real programs is very large. The complexity of it seems high and it still only has a single dedicated developer. I've heard its performance demands are high - it doesn't seem like something you'd want to run on a phone. It feels too risky to me - Purescript or Typescript is probably what I would go with for a serious project.

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.

Or used a signed assertion that is verified with a secret.