Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

I have some text based operational transform code I port to each language I learn to get a feel for it. (And I’ve got a version in C, JS, rust, swift and go). The go version is clunky. It’s longer than the others, and the lack of parameterised enums (or any type of simple polymorphism) makes it much harder to understand and reason about. The code is longer and uglier than the rust and swift equivalents. And it runs slower than the C and rust code. (I didn’t benchmark swift). After my experiment I find I have little appetite for the language.

I feel like programming is like electrical engineering. A lot of people graduate expecting to design transmission systems and power stations. But most of the work in the field is simple stuff like wiring up a new light switch at grandma’s house. Go feels like a language designed for that group of engineers - boring as a feature, reliable, simple to reason about, anti-clever (so whoever comes in after you can understand your work). It’s a predictable language for code-as-content. It’s great that people who do that kind of work have better tools. But I also accept that that’s not the type of software engineer I am. I want my code to be clever. I like to push at the limits of expressibility in a language. For the types of work I do (lately implementing various CRDTs), small, tight, fast code is better than simple, verbose code that any tom, dick or Harry could comfortably maintain.

Does this distinction have a name?

> I want my code to be clever. I like to push at the limits of expressibility in a language. For the types of work I do, small, tight, fast code is better than simple, verbose code that any tom, dick or Harry could comfortably maintain.

> Does this distinction have a name?

Yeah. Write-only code.

Code written this way is often smaller and tighter. But that doesn’t make it unmaintainable. Is Haskell unmaintainable because of its dense, clever use of the type system? No way. But I’d personally struggle to maintain something like that because I don’t have enough familiarity with Haskell to do so. Likewise I wouldn’t trust most programmers to maintain the rust code I’ve been writing lately - not because it’s bad rust, but because I’m making heavy use of the language’s features. That raises the skill floor. In comparison, if you gave me some crashing Go code I could probably debug it even though I don’t know much go.

I find most Java code bases awful to maintain because there’s always so much code. Simple changes take a long time to make because there’s so much code to understand and modify. Give me the tight rust any day.

The rust compiler is a great friend for the kind of code I imagine you’re talking about. Expressing ideas in the type system makes the code easier to maintain, because you can’t compile code that deviates from your invariants. I’ve been reviewing rust code at work for over a year now, much more recently having switched to a job where the main language is rust. Knowing in code review that the code compiled successfully is a huge benefit for readability and review, IMO, because you don’t need to go around checking any of the invariants the type system can catch.

There are also use cases for dynamically generating code, or having higher kinded types that Go just can't touch. Anything that resembles data engineering is unnecessarily tedious.

One of my favourite tools for teams these days is Hasura, which is written in Haskell. I could not imagine a product like this being written in Go.

> Is Haskell unmaintainable because of its dense, clever use of the type system?

yes.

Reply on news.ycombinator.com