z1mm32m4n

Ironically, one of the easier ways TypeScript has been able to work quickly is by skipping the type inference Flow does. It’s a trade off. The Flow team was advised that this approach would have performance problems early on in the project, and opted to focus on type system features first and perf second.

The important parts here are (1) that they remained metrics driven and (2) that they focused on repeatability.

1. Both TypeScript and Flow are gradual type systems. They both explicitly allow escaping the safety and coverage of a type system, either to allow easier interop with existing JavaScript packages or to allow existing JavaScript codebases to incrementally adopt types. So there are always holes in which errors are reported, regardless of whether they had to silence some explicitly or not. By measuring the extent, they have a yardstick against which they can drive further type adoption.

2. Repeatability is the only way to do large code migrations. Write the steps in a script, run it, find the bugs in the script, fix the script, and repeat. With 300k lines of code no doubt they have dozens or hundreds of people committing daily. So a script is the only way to sneak in during off-hours, get something in that doesn’t race to conflict with someone else, and land the change. A long running, manually crafter branch here would not work—it would effectively operate as a fork of the codebase for the entire duration of the migration, with all the downsides that a fork entails.

Kudos to the team; this is a very impressive feat!

> I rarely have any say in that, and I try not to get worked up about things I have no control over.

This hasn't been the case in my experience. I joined a new team about a year ago, and the predominant mode of discussion was Slack + IRL discussions.

Over time, I started writing docs (in Dropbox Paper, but if you want to use Google Docs feel free) and shepherding conversations to happen in those docs. @mention people into a thread to ask for their thoughts. Remind people that you have an ongoing doc to take a look at during standup.

Over time, it's possible to change team norms. But it's a slow process, and it's important to remain receptive to the experience other teammates are having too.

Exactly. I can't imagine providing intra-company support over either email or IRL.

IM lets me take a second to understand someone's question, maybe run some command or look up some docs, and then get back. When answering IRL, there's always the pressure to definitively answer the question, because they went through all the effort to actually take up time together. It's hard to say, "I don't know; I'll have to dig in deeper."

And turn around time on email for questions like "Why doesn't this thing work" sounds like an easy way to get blocked for half a day.

One of the appeals of email is asynchronicity—I can compose a well-reasoned proposal, and give my team time to compose a well reasoned counter-proposal.

But after more than a handful of rounds of this, it breaks down. Long email threads are impossible, especially ones that I wasn't originally participating in, but then got cc'd into. There's no easy way to skim and get a summary of the current state and where the heated bits of the proposal are.

That's why I like Dropbox Paper instead of email for these kinds of discussions. Threads spin off of a highlighted snippet, so there's always context to the discussion. Discussion in threads gets resolved, and the doc gets updated to reflect the decision—this means the doc is always canonical when someone new first reads it.

Email will never die because it’s so universally versatile. But specifically for intra-team discussions and decision-making, I'm convinced we can find (and already have found) better solutions.

It’s even nicer in Haskell because not only does do-notation make code look clean, await is a function, not an operator.

Want prefix await? Go for it!

    res <- await $ foo bar

Want postfix? You can have that too!

    res <- foo bar & await

Being “just a function” means it composes with everything else in the language, something the Rust languages designers have held in high regard when designing this.

(But I also fully appreciate the design constraints that prevent Rust from using “just a method” or ”just a macro”)

Who's to say we couldn't use the types to make the runtime faster in the future?

One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code.

If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actually be run. If the signatures lie, then any runtime optimization made using the types would only be overhead, because the runtime would have to abort the optimization and fall back to just running the interpreter.

[1]: https://sorbet.org/docs/runtime

Sorbet has multiple Strictness Levels[1]. The two most relevant ones are `typed: false` and `typed: true`. `typed: false` is the default level and at this level only errors related to constants are reported, like this one:

https://sorbet.run/talks/RubyKaigi2019/#/14

But we'd like to catch more than just errors related to constants, like those related to missing methods, or calling a method with the wrong arguments. Errors like these are only reported in files marked `typed: true`:

https://sorbet.run/talks/RubyKaigi2019/#/19

Sorbet doesn't need to have method signatures to know whether a method exists at all, or what arity that method has.

But more than that, Sorbet ships with type definitions for the standard library. So you don't even need to start annotating your methods to type check the body of your methods, because most of the body of your methods are calling standard library things (arrays, hashes, map, each, etc.).

The statistics in those slides are sharing "out of the box, what's the highest strictness level that could be added to a file without introducing errors?" So ideally an entire project be made `typed: true`, but Sorbet can be adopted gradually, so a project can exist in a partial state of typedness. We wanted to see how painful it would be to adopt Sorbet in a handful of large, open source rails projects, and it turned out to be not that bad.

[1]: https://sorbet.org/docs/static#file-level-granularity-strict...

My favorites:

The Last Lecture by Randy Pausch

How to win friends and influence people by Dale Carnegie

Hey! I work at Stripe on Sorbet. Don’t worry, you haven’t missed any announcement. Stripe is still very much committed to Sorbet; it’s used by hundreds of engineers every day to catch bugs and increase developer productivity. We’re currently hard at work polishing Sorbet to make it mature enough for people to use outside of Stripe. It’s not quite ready yet, but if you email sorbet@stripe.com we’ll have your email address so we can let you know when we do have something worth announcing.

Thanks for the interest in Sorbet!

I recently learned that a system like this is already described by Haskell’s Package Version Policy[1]. They call the vanity digit the “epoch”[2]. Basically the way the formalize it is that the first two components specify the major component, and a breaking change must correspond to an increment where the new major version is lexicographically greater than before. Depending on the whim of the maintainer this can be by incrementing the first or second number.

[1] https://pvp.haskell.org [2] https://pvp.haskell.org/faq/#semver

And if you want a visualization of those stats:

https://data.worldbank.org/indicator/NY.GDP.PCAP.CD?location...

^ I find it really interesting to see how volatile some of these charts are, while the US GDP per capita seems relatively stable.

Ah, maybe that’s the formal definition. But it’s still frustrating to be at a bus waiting for a late bus and then see a 61A, B, and C all in a line, knowing that any of them will get you to dinner :P

Ah this is an interesting idea. Passengers already have to request when they want to get off. I'm assuming you mean if no one wants to get off, a bunched up bus skips a stop because a bus behind it says "I'm behind you, I'll take this stop."

That would mostly work, but the problem in Pittsburgh at least is the bus bunching happens between related but not quite identical routes. For example, the 61A, 61B, 61C, and 61D all run down Forbes Ave, and frequently get bunched there. But then later in their routes, they fork: two go one direction, and two go the other direction. For many passengers, it doesn't matter which one they take. But for other passengers, it has to be a 61A etc.

This reminds me of a homework assignment in one of my freshman year classes which was to implement various church encodings and helper functions in the lambda calculus using only LaTeX macros!

I’m all for cohesion, which it seems was the main point the author was trying to make.

But I found the first motivating example (refactoring is hard) to be a poor argument in favor of cohesion. When making a breaking public API change, types and the ensuing type errors are going to be a way more powerful guiding force for identifying affected usage sites than cohesion. Of course, his examples were in Python, so maybe the author doesn’t have such luxury.

An interesting point about programming is that so much of it comes down to thinking of names. I found this article by a Russian native about programming and naming things rather fascinating:

https://temochka.com/blog/posts/2017/06/28/the-language-of-p...

I’ve frequently needed to access a plain text version of a site in a bash script or from the command line. For this, I use the command

    w3m -dump <url>

which dumps the website’s text content to stdout.

Considering you mention not having programmed extensively in a functional language, I'd say you should pick a language with extensive documentation for beginners. I know you dismissed it, but many people have put a lot of time and thought into designing materials for learning Haskell. In particular, I think most people recommend the Haskell book[1].

That being said, all the choices you list (Elm, Haskell, F#, OCaml, PureScript) are solid languages with good communities. The core languages are similar enough that if you start learning one, the things you learn will transfer decently enough to all the others.

[1]: Haskell Programming from First Principles (http://haskellbook.com/)

Ah! Thanks for pointing this out, I'll be sure update the post. (I haven't used TypeScript all that extensively, so I didn't even know about `const enum`.)

Ah, that's my mistake! The generated Reason output got copy/pasted incorrectly. (It's correct if you click through to the Try Reason link.)

In fact, Reason generates the `>=` comparison, and it knows it can do this because it know that a value greater than 2 can never happen.

The post should be updated to reflect this in a second!

I wouldn't be surprised if they were actually using some techniques from NLP. In particular, I wouldn't be surprised if they'd run sentence parsers over their entire Books collection and then manipulate the parse trees to find sentences in books that look like good answers because their sentence structure is similar.

I think my favorite part of this is that inevitably people will write type definitions for TensorFlow.js in TypeScript, Flow, ReasonML, Purescript, and more.

It has always seemed like data science and machine learning tasks have always been most popular in dynamic languages like Python, Julia, and R. I really hope this can be a bridge over to typed machine learning APIs!

(Of course, I’m also interested to hear about your favorite typed machine learning library if you have some that you already use)

This is an interesting take on handling money. By far my favorite library for abstracting over monetary operations is safe-money.

The author does a good job at building up the abstractions from first principles in this post: https://ren.zone/articles/safe-money

Do you have support for Code Intelligence with Flow (for JavaScript) or Ruby on your roadmap?

I mostly use Spotify and stream music rather than collect mp3 files, but I still have a couple hundred or so songs that Spotify doesn’t have. Spotify lets you load local files and add them to playlists alongside songs you stream, and I’ve generally been pretty pleased. It certainly beats iTunes, and it’s nice having everything all in one place.

I want to second this. The number one problem with resumes is that they all focus on the positive space: craming as much text and non-data-ink onto the page as possible.

Let your main point breathe.

Also: use a professional typeface. Recruiters look at Times New Roman, Arial, and Computer Modern all day. Try Avenir, Garamond, or San Francisco. Maybe even pay for a font license.

> And fi­nally, font choice. The fastest, eas­i­est, and most vis­i­ble im­prove­ment you can make to your ty­pog­ra­phy is to ig­nore the fonts that came free with your com­puter (known as sys­tem fonts) and buy a pro­fes­sional font (like my fonts eq­uity and con­course, or oth­ers found in font rec­om­men­da­tions). A pro­fes­sional font gives you the ben­e­fit of a pro­fes­sional de­signer’s skills with­out hav­ing to hire one.

— https://practicaltypography.com/typography-in-ten-minutes.ht...

Do they still use AWS for compute, with their own data center just for storage? Or do they have their own infrastructure for compute?

If I remember correctly, they noticed they could dust costs significantly in storage compared to S3 because the vast majority of files in your Dropbox folder just sit there and hardly need to be read or written again (photos, etc.).

If they’re not using AWS for compute, it’d be interesting to see what sort of similar reasoning they have for why the costs are cheaper in house.

This doesn't directly solve your problem, but if you click through to the comments section of an article and click the "web" link (between "past" and "favorite"), it'll search Google with the text of the post submission.

So if you're looking for multiple viewpoints, this is a ~frictionless way to start reading multiple perspectives.

Yep, org-mode is really cool too!