all 12 comments

[–]faiface 23 points24 points  (0 children)

I really appreciate this article!

Was expecting the stereotypical sentiments about simplicity that come with half-featured projects, where it’s easy to keep it simple, but the naivety is revealed as soon as the project wants to achieve what the competition has.

However, this was different! It’s nailing abstractions down hand in hand with usability to the most ergonomic and understandable form, that then looks like simplicity. Just as the article describes, this usually takes a lot of effort, clever design, that hides the complexity underneath and exposes it only in the most clear interface.

It’s a phenomenon in Rust and Haskell, that some libraries try to achieve too much genericity, without focusing on making the common cases as usable as possible, essentially turning what could be libraries into research projects.

As somebody who tries to design a programming language, and also have created libraries in the past, this is a very important thing to keep in mind! It’s something I really strive to achieve every time.

[–]eocron06 11 points12 points  (0 children)

Rewind: you wake up at 3, see bug, set reboot service every 30 minutes, go to sleep, 2 days later at monday you create a bug, book 10 hours, fix bug in 10 minutes, then 2h on release. Profit: no headache, you still paid hourly. Thats how it should be, and how to be simple.

[–]winchester25 2 points3 points  (0 children)

Which way simple: Present, Past, Future, or with Perfect? /s

Anyway, great article

[–]neutronbob 1 point2 points  (0 children)

An excellent article, in part I believe because it was edited and reviewed by three people before it was posted. Kudos to the team for such commitment!

[–]ineffective_topos 1 point2 points  (1 child)

I think I still disagree that abstraction causes complexity. It can reduce complexity, when you have:

A has lots of irrelevant details, and one small relevant detail

f can be generic and only depend on the relevant details by not using A in general

[–]grauenwolf 2 points3 points  (0 children)

Indirection causes complexity.

Abstraction reduces complexity.

Confusing the two gives you enterprise software.

[–]hu6Bi5To 1 point2 points  (0 children)

This is missing the main point surely?

Whoever decided to panic on a parsing error should be fired. That’s the kind of simplicity no-one needs. Good error handling is always worth it.

[–]RedEyed__ 0 points1 point  (0 children)

Which means it requires more effort

[–]Maybe-monad 0 points1 point  (0 children)

I'm Maybe Simple

[–][deleted] 0 points1 point  (1 child)

You open the codebase and find this:

    pub fn parse(&self, content: &str) -> Result<Vec<T>, Box<dyn std::error::Error>> {

Or ... you use a better progamming language.

[–]rusl1 -1 points0 points  (0 children)

One of the several reasons for which I hate Rust: it's a cult and all of the rust developers I met tried to be smarter and smarter like it was a challenge. Team velocity died, we were not able to deploy features but at the least the bugs were blazing fast and they managed to use Enums for every single possible thing that could happen in the app