type: post

title: Elixir

description: The Elixir programming language

hide_image: true

resources:

- src: pdq.png

params:

alt: two people standing in front of construction of a business office

comments: true

draft: true

A few years ago I happened to find myself at predominantly C# shop that decidedly pivoted to take on a new stack with Elixir, LiveView, TypeScript and React. For a greenfield project, this was exciting, fast, and uninhibited. I was grateful to work with a technology that ranks as highly desired in every StackOverflow Developer Survey. However, as our codebase scaled, some of the realities of a dynamically typed language began to set in.

Elixir excels in specific contexts such as personal projects and small teams with stable membership, concurrent systems leveraging BEAM's actor model, fault-tolerant applications using OTP patterns, and high development velocity on well-understood codebases. So much is available out of the box with Elixir and Phoenix. Websockets, pubsub, caching, memory store, concurrency, and clustering are huge wins in the language that small teams can spin up without much effort. I believe Ecto is the best database library with a SQL DSL and Query Result Mapping available in the open source world.

Code comprehension and issue tracing become difficult at scale with dynamic typing. For most code changes in large codebases, it's difficult to ascertain which code paths are affected. Refactors require excessive caution and testing. Dialyzer helps but it doesn't solve the fundamental typing gap.

There is also organizational friction with adopting Elixir. There can be a learning curve for functional programming concepts and there's a limited hiring pool compared to mainstream languages.

Other minor issues include slower compile times, especially without strict avoidance of circular dependencies, and a weak language eecosystem.

At my org, we're iterating on certain [design patterns that improve readability and organization](/boundary).

Gleam offers static typing while maintaining Erlang ecosystem compatibility. Elixir itself will soon become a [gradually typed language](https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html). Gleam looks very promising, but it isn't a practical decision for the enterprise world until the language matures.

Elixir provides genuine technical advantages for concurrent, fault-tolerant systems. It's an excellent solution to reach for with many features such as concurrency, clustering, pubsub, websocket messaging, memory storage, and other enterprise features out of the box with Phoenix. However, these benefits come with significant organizational costs: harder hiring, steeper onboarding, and maintenance challenges from dynamic typing.

Elixir is an excellent choice for purpose-built microservices for specific concurrent jobs such as [handling websocket message](/multiplayer).

Success with Elixir could depend on:

- Team stability and functional programming expertise

- Specific technical requirements that justify the adoption overhead

- Organizational commitment to the learning curve

For most teams, businesses should evaluate whether Elixir's features outweigh its dynamic typing drawbacks and niche ecosystem.

type: post

title: Go

description: The Go programming language

resources:

- src: discussion.png

params:

alt: three people talking in group, one man pointing back with a thumb

comments: true

draft: true

I encountered a [Hacker News comment](https://news.ycombinator.com/item?id=44392307) that summarizes my perception of Go:

Go has become the "practical pragmatist" of modern languages. It's beloved for its simplicity but limited by deliberate design choices.

Go excels as the reliable workhorse:

- Fast compilation prioritized over optimization

- Low barrier to entry with quick learning curve

- Networking and server development where it truly shines

- Simple type system that "just works"

- Comprehensive tooling for profiling and testing

- Strong concurrency with goroutines and channels

Garbage Collection Reality

- "GC causes performance issues with large in-memory caches"

- Not optimized for large, long-lived object heaps

- Works best with short-lived objects

- Forces architectural compromises for performance-critical systems

Expressiveness Ceiling

- "Go has a very low barrier to entry, but also a relatively low ceiling"

- "The proliferation of codegen tools for Go is a testament of its limited expressive power"

- Limited type-level features compared to modern languages

- Repetitive error handling patterns

Design Philosophy Constraints

- "Go is the product of like 3 Googlers' tastes"

- Deliberately simple but sometimes oversimplified

- Lacks advanced type safety features

- Channel complexity despite being a core feature

Go optimizes for Google's specific use cases:

- Infrastructure and glue code

- Large teams with high turnover

- Prioritizes readability over expressiveness

- Fast compilation over runtime optimization

This creates friction for teams with different priorities or performance requirements.

Go succeeds as a "good enough" language for many server-side tasks. Its compilation speed and simplicity make it excellent for rapid development and large teams. However, its deliberate limitations create frustration when projects outgrow its design constraints.

Go works best when:

- Building servers, networking, or glue code

- Fast iteration matters more than peak performance

- Team composition favors simplicity over expressiveness

- GC limitations align with your data access patterns

The language's greatest strength of extreme simplicity is also its primary limitation when requirements demand more sophisticated solutions.

{{ if not (and .Params.hide_title .Params.hide_date .Params.hide_image) }}