DEV Community: Alex Verein

Comparing switch-like operators in 14 different programming languages

Alex Verein — Sat, 11 Sep 2021 10:00:22 +0000

We are going to look at Javascript, Typescript, Java, C#, Swift, Objective-C, Python, PHP, Ruby, Kotlin, ReasonML, Dart, Go and Elixir.

At Avo (avo.app) we work with 12 languages, and I decided to do a series of quick comparisons of those languages, plus 3 languages we are going to support soon.

First feature we are going to look at is the switch-like constructs. We are interested in 3 features related to switches - ability to use switch as an expression (so it returns a value), whether the switch construct is exhaustive (you need to handle all cases to compile the code) and if the fall-through logic disabled (so you don't need to break out of each case explicitly).

Language	has switch expression	is exhaustive	no need to break	reference
javascript	limited, only if wrapped in a function https://stackoverflow.com/a/55944296	-	-	https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch
typescript	limited, only if wrapped in a function	limited http://ideasintosoftware.com/exhaustive-switch-in-typescript/	-	same as JS
java	starting java 12	expression is, statement is not	additional syntax starting java 12	https://openjdk.java.net/jeps/354
c#	starting C# 8.0	- (expression will give a compile warning)	need to break in the statement	https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/switch-expression
swift	-	+	+	https://docs.swift.org/swift-book/LanguageGuide/ControlFlow.html
objc	-	+	-	🤷‍♂️
python	no switch in python :)
php	called match, introduced in php 8	match is, switch is not	match , switch is not	https://www.php.net/manual/en/control-structures.match.php
ruby, called `case`	+	-	+	https://ruby-doc.org/core-3.0.1/doc/syntax/control_expressions_rdoc.html#label-case+Expression
kotlin, called when	+	expression is, statement is not	+	https://kotlinlang.org/docs/control-flow.html#when-expression
reasonml/rescript	+	+	+	https://rescript-lang.org/docs/manual/latest/pattern-matching-destructuring#switch-based-on-shape-of-data
dart	-	+	-	https://dart.dev/guides/language/language-tour#switch-and-case
go	-	-	+	https://tour.golang.org/flowcontrol/9
elixir (called case)	-	- (runtime error CaseClauseError)	+	https://elixir-lang.org/getting-started/case-cond-and-if.html#case

How to set up `git bro` command with git alias

Alex Verein — Fri, 16 Jul 2021 11:49:38 +0000

Have you seen people use the git bro command in terminal and always wondered how they do it?

It's actually very easy and I'm going to teach you now. Moreover, after mastering this technique you'll be able to use any command your imagination comes up with, like git cmon or git brunch.

I'll also share my own commands config in the end (quite conservative tbh).

You have git set up

First of all, you need git. I assume you already have it, if not, check this out.

Add the command

All you need to add a command is to define an alias, like this

git config --global alias.bro `branch`

Manage the aliases

To see all the aliases run

git config --list

To remove one run

git config --global --unset alias.bro

My aliases

As I promised, in the end I share my setup

alias.co=checkout
alias.cm=commit
alias.st=status
alias.bro=branch
alias.br=checkout -b
alias.pushit=push -u origin HEAD

Thanks for tuning in

That's it, now you can update your CV stating that you are bros with git!

👋

ReasonML & Rescript in 5 minutes

Alex Verein — Fri, 23 Apr 2021 16:46:57 +0000

What is this language about?

It's a functional language that compiles to JavaScript (or to OCaml). We use it widely at avo.app.

What is ML in ReasonML?

Nowadays ML usually stands for Machine Learning, but in the old days there was a programming language called "Meta Language" which is the ancestor of ReasonML, or Reason Meta Language.

Why rename?

ReasonML is compatible with both JS and OCaml, but lately it was mostly used in the JS ecosystem.
Rescript takes JS-related things from Reason and stops being limited by OCaml support.

What are the good things?

Immutability

All references are actually constants. Shadowing is widely used. Standard library functions are non-mutative and produce new instances if any changes are made. There is a workaround to create a mutable reference if needed but deliberate enough to be discouraging.

Piping and currying

Rescript is a functional language with no methods on objects, but you can call and chain functions in a familiar way with piping and currying, like
myList->List.length
or
myArray->Array.map(item => item * 2)

Sound type system and type inference

This is probably the main reason to choose rescript. It has strong type system and powerful type inference, so you are rarely required to explicitly define types, but the compiler always knows what the types are.

No folder requirements and no imports

This is a case in many languages, but coming from Java I really appreciate this feature. And Javascript developers love the no imports thing!

Full support of algebraic data types

It's very easy to describe any domain with the custom types
You can create type aliases like type eventId = string or complex types like

type event = {
  id: eventId,
  name: string,
  uniqueName: option<string>,
  description: string,
  properties: list<property>,
  types: list<eventType>
}

The main construction in the language is the exhaustive switch optimized for pattern matching

It's accompanied by an empowered kind of enum called variants. There are options of variants with and without duck typing. Better to see it in action

Simple syntax

It's possible to start writing code after just a few hours of learning if you already know another programming language.

Relatively safe refactoring

The combination of a rigid type system and exhaustive switches make the compiler very efficient in finding bugs in the compile time.

What are the not so good things?

Simple syntax means it's verbose

There is not much syntax sugar, for example to unwrap an optional constant you'd have to write maybeSomething->Option.map(something -> something->performOperation) instead of maybeSomething?.performOperation() in some other languages.

You have to define functions before using them

Yes, like in good old C.

You can still have type-related bugs

Having a powerful compiler that catches 99% of the type bugs can be too relaxing and it becomes easier to miss that one occasional bug that slips through the compiler checks. 😉

Bonus

We are maintaining a public code style guide for ReasonML, contributions are very welcome!

Kotlin vs Swift: implementing a method that accepts a limited set of polymorphic equitable types

Alex Verein — Tue, 23 Mar 2021 18:47:34 +0000

At Avo we work on code generation based on tracking plans.
Recently we added a new interface for calling events - before we were generating a method for each event in the tracking plan, i. e. there were methods Avo.userSubscribed(userType, subscriptionType) and Avo.commentAdded(authorId, mentionedUserIds).
With the new interface we create a type for each event, i.e. UserSubscribed with userType and subscriptionType as fields and CommentAdded with authorId and mentionedUserIds fields, and a new method called track that expects instances of those types, like this Avo.track(UserSubscribed(userType, subscriptionType))

Why?

This change makes Avo more flexible to use in large codebases, for example you can build the UserSubscribed events in different parts of you app gradually and pass it around.
You can also build a simple test implementation of the new track interface that does not require mocking.

What are the challenges?

Firstly, we don't want users of the generated code to pass unexpected things to the track method. Only the events defined in the tracking plan are expected.
Secondly, we want the events to be meaningfully comparable.

Solution

Let's see what both languages can offer us to solve this little challenge.

1. Defining the event types.

The ways of choice to define a limited set of types are:

In Kotlin - sealed classes. Sealed classes are abstract classes and you can define their child classes only in the same file. User's won't be able to create their implementation of our sealed class, exactly as we want. This also makes the compiler know the exact set of descendants of our sealed class.

sealed class AvoEvent {
    data class UserSubscribed(val userType: String, val subscriptionType: String): AvoEvent()
    data class CommentAdded(val authorId: String, val mentionedUserIds: List<String>): AvoEvent()
}

In Swift - enums. Enums in Swift are more powerful than in most other similar languages. Each enum case can have any number of variously typed parameters, which is nice for our case. User's are not able to add cases outside of the enum.

public enum AvoEvent: Equatable {
    case userSubscribed(userType: String, subscriptionType: String);
    case commentAdded(authorId: String, mentionedUserIds: [String]);
}

Here things are quite even, since classes are a bit more flexible (more on it in the next section) and also in Kotlin you use common class interface for most things, while in Swift you have to use different entities - classes / structs and enums. On the other hand Swift code looks cleaner.

2. Making the types equitable

In Kotlin we use data classes. Every data class automatically gets equals method implementation without the need to write any code based on the primary constructor values.
In Swift we set our enum to conform the Equitable protocol. In modern Swift if all the used types of a thing we add Equitable protocol to are Equitable you don't need to write any implementation. This is similar for both languages.
Everything is great until we get a enum member with an Any type parameter.
The problem in Swift is that the Any type is not Equitable. And once it appears you have to implement the compare method (==) manually. Moreover, once you have the compare method you have to manually implement comparison of each enum case. (In Kotlin for example we can implement the equality method on a separate single child class of our sealed class, that's the advantage of sealed classes over enums I mentioned in the previous section).
In Kotlin Any type is equitable out of the box. Since it's has equals method it is designed to be.

This point is won by Kotlin.

3. Picking what to do based on the provided parameter

Here everything is quite simple:
In Kotlin we use when statement.
In Swift we use switch statement.
The good thing about the switch statements in Swift is that they are required to be exhaustive. This makes perfect sense in a statically typed languages - I want to be sure that if I add a new case to my enum and not add it to the switch I'm alarmed by the compiler.
Unfortunately it is not the case in Kotlin. When you use when as a statement, not assigning it's result to a variable or using it in some other way, which is a default way for those who come from Java and many other C-like languages, it is not required to be exhaustive. You can use when as expression and then it becomes exhaustive, but that's not enough. Here is a bit more on that topic.

In this part I give the point to Swift.

Results

All in all, it is a draw in out little face off, Kotlin is a winner on the data structure design side and Swift wins in the operator design.

What are great developer docs? Looking at Stripe here, let's discuss

Alex Verein — Tue, 16 Mar 2021 09:43:30 +0000

Recently I had a chance to work with one of the most honored developer experiences out there - with Stripe, https://stripe.com/docs
Here are a few things I really liked about the docs there and a few flaws I found.

But to be clear, overall I rate Stripe docs very high.

(+) First of all, it's awesome. Human readable prefixes in the API keys, omg, why does not everyone do it?!! I.e. price_****** for a price key and sub_******* for a subscription key
(+) Docs are user story based, which is very cool. It's easy to go with the flow and find what you need. Would totally adapt that. Search is also good, but it is a must nowadays
(-) The subject area is huge, some specific things are hard to find though, i.e. subscription statuses are teased here and there, but the whole list is only in the API docs
(-) Some cherry picked dev docs/references are available through the main docs entry point, but others live at https://stripe.dev and there are no easily findable direct links to the server sdks from the main docs
(+) Server (at least Node.js I worked with) SKDs are exactly like the API reference. This is insanely convenient. I suspect this is one of the reason why the server SDKs are not featured in the main docs

What do you like and dislike about developer docs, for Stripe or any other product? Share some examples!

Public ReasonML Code Style Guide @Avo

Alex Verein — Tue, 27 Oct 2020 08:58:54 +0000

Just released a blog post about our Code Style Guide approach.

Last week we've open sourced the guide itself on GitHub.

Contributions are adoptions are more than welcome, let's build a canonical ReasonML & ReScript code style guide together!