|||

Rake Routes

by Stephen Ball

A simple language spec isn’t a feature when you’re building applications

Go famously gushes about its simple and readable language specification. One one hand kudos to Go for having a written specification and kudos for rigorously keeping the language simple.

But on the other, more pragmatic, hand a simple language spec means the language itself has fewer affordances out of the box. Programmers will be left to spin up their own designs for everything else. And, as we see in JavaScript, that’s a problem if you want to encourage a shared language community.

Everyone comes up with their own patterns, patterns which may not be obvious even as they are made up of the common components from the language spec.

A little copying

Go actively encourages this way of programming with the idiom a little copying is better than a little dependency.” Here they are actively avoiding one of the major pitfalls of NodeJS. But at what cost?

A lot of places

I say the cost is higher than the blithe quote indicates. A little copying from one place leads to an accumulation of a lot of copying from many places. Because the copying isn’t named, versioned, or isolated it is peppered throughout the resulting program. And that means if you find a flaw you have many places to fix. And, worse, if someone else finds a flaw you have no idea unless you come across and recognize the improved version of that little copy.

Go is for systems not applications

Now, to be clear, I don’t think this is a flaw for Go’s supposed primary purpose: a systems programming language. Systems programming should be short, simple, sharp tools to perform high quality work with a strong performance story. You don’t want to burden your systems with huge, complex, dull, and ill-performing tools. Excel is wonderful, Excel is not a systems tool. Excel is an application.

But many programmers out there are building, or trying to build, the equivalent to Excel in Go. To write not sharp tools but large applications in Go because Go has become their hammer and everything is a nail even if it’s a skyscraper.

Up next The Fastest Possible Tests I love tests as a fast programming feedback loop! In the last twenty or so years I’ve seen them go from an occasional critical verification to a
Latest posts A simple language spec isn’t a feature when you’re building applications The Fastest Possible Tests Shrink your data into bitfields (and out again) Every “if” statement is an object waiting to be extracted Choose Generic Tools Hyperlinks you might find interesting — #4 Running bundle install on rails master Use tldr for command line examples Friday Lunch Links — #3 Friday Lunch Links — #2 Logical Solver: Turn facts into conclusions Programming with jq Command line tools - jq Friday Lunch Links — #1 Why diversity matters Music for coding - October 2019 Code puzzles are a poor way to gauge technical candidates Add vim to a pipeline with vipe Connecting Objects with Observable Let’s write a shell script What’s a $PATH anyway? Let’s Use Hwacha to Scan URLs Deliberate Git Customize Your IRB Program Like a Videogamer Gem Spotlight: interactive_editor Things Most Interviewees Fail to Discover Rails isn’t for beginners How to use bundler instead of rvm gemsets How to write (and test) a gem to serve static files on the Rails asset pipeline A Taste of Metaprogramming