Posted on

Simplifying generics-heavy typescript code using Container Interfaces, Extractor Types and Companion Namespaces

Writing generics-heavy code code in Typescript can sometimes be arduous, especially because typescript doesn’t facilitate higher kinded types at language level.

So, a function that accepts multiple arguments of generic types often has to accept type parameters of all these generic types in order to retain type safety:

This can get cumbersome fast, especially when the parameterized types have constraints on the type parameters because now these constraints also have to be replicated:

Continue reading Simplifying generics-heavy typescript code using Container Interfaces, Extractor Types and Companion Namespaces

Posted on

Fable+F# vs ReasonML | Hacker News

I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts.

Continue reading Fable+F# vs ReasonML | Hacker News

Posted on

ReasonML vs TypeScript – First impressions

This post summarizes preliminary observations while comparing ReasonML and TypeScript during selection of a reasonably (pun-intended) type safe language for frontend development. The observations here are somewhat biased in favor of experienced javascript developers and focusses primarily on frontend development workflow and does not take into account the (primary) native backend of Reason.

While this post primarily compares Reason and TypeScript, much of what is outlined about TypeScript equally applies to flow as well.

Continue reading ReasonML vs TypeScript – First impressions

Posted on

Typescript and validations at runtime boundaries

Typescript team has explicitly stated that they don’t intend to extend typescript’s static type checking to the runtime.

Typescript Design Goals lists the following in the section on Non-goals:

Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

While on one hand this design goal is advantageous in that the output generated by typescript is very close to what hand written javascript would have looked like. And the runtime cost of typescript remains close to zero, therefore adoption of typescript does not alter performance characteristics of an application.

However, this also implies that for cases when static typing cannot help us we need to separately write validators using a validation library (eg. Joi) which has to be kept in sync with the typescript types.

This post outlines an approach to eliminate this redundancy using the io-ts library by Giulio Canti. This approach has also been adopted by some other libraries like MobX State Tree and Runtypes.

Continue reading Typescript and validations at runtime boundaries

Posted on

A Vagrant+Docker based workflow for clojure web development

This post outlines a container based development workflow using Vagrant and Docker.

Many common docker tutorials (eg. the official node tutorial) suggest a workflow where projects source is copied onto the image, which is then built and run through docker. This approach is not really practical for clojure development as normal clojure programming leans heavily on rapid prototyping and REPL driven development.

The setup below utilizes Vagrant and docker volumes to setup a development environment which ensures reproducibility and container isolation while retaining the short feedback cycle which clojure developers take pride in.

Continue reading A Vagrant+Docker based workflow for clojure web development