stefano_c

The "Variance of slice types" paragraph is confusing as hell. The type Tree implements interface Barker, after all. To me it looks like this is more about what I call "accidental implementation" (which is one of the many reasons why I don't like Go). Can somebody please explain what I'm missing?

The irony is that in a normal Rails app workloads are already split by default (requests and background jobs are handled by different processes that share the same codebase).

I've been writing Ruby for 20+ years and "unless" (the whole language, actually) immediately clicked for me when I first learned it.

That said, I only use it in 2 cases:

* as a trailing condition (do_something unless this), mainly for early returns * as the only arm of a multi-line block (unless this ... end, no "else" blocks - Rubocop would yell at me anyway)

And then only if the condition is either a simple value, or a combination of simple values (this && that, this || that).

That's it. Never had a problem with double negatives or accidentally inverting the logic.

I wish I could upvote comments more than once on HN :-)

- There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values.

This is similar to how Icon works: https://en.m.wikipedia.org/wiki/Icon_(programming_language)

How about scheduling a daily summary email? Daily reports?

Forgive me if I'm wrong (I don't know Phoenix that well), but don't you need some external library like Exq do perform background jobs? How is Phoenix+Exq different from Rails+Sidekiq?

Yep, you're perfectly right of course. My "solution" was mainly to address the problem "how can I return a String from a const function"... the answer is that you don't have to :-)

One possible solution in Rust could be:

    enum Value {
        Fizz,
        Buzz,
        FizzBuzz,
        Number(usize),
    }

    impl std::fmt::Display for Value {
        fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
            match self {
                Value::Fizz => write!(f, "Fizz"),
                Value::Buzz => write!(f, "Buzz"),
                Value::FizzBuzz => write!(f, "FizzBuzz"),
                Value::Number(num) => write!(f, "{}", num),
            }
        }
    }

    const fn get_fizzbuzz_equivalent(number: usize) -> Value {
        if number % 15 == 0 {
            Value::FizzBuzz
        } else if number % 3 == 0 {
            Value::Fizz
        } else if number % 5 == 0 {
            Value::Buzz
        } else {
            Value::Number(number)
        }
    }

    fn main() {
        (1..100).for_each(|num| println!("{}", get_fizzbuzz_equivalent(num)));
    }

There are no tags, or labels, no other folders or any other buckets of organization.

Actually there are labels (and what's the difference between a tag and a label?)

[...] there’s no automatic organization here

When you get an email from a new contact you decide where it (and future emails) should go; you can also change the destination after it has landed in your Imbox.

It is Slow & Ugly

This is very subjective: I like the UI a lot, and I've never perceived any slowness (Gmail, on the other hand...)

What would you suggest for replacing e.g. `u8 as usize`?

The thing that DHH is failing to mention is that Monoliths work great when your application looks something like Basecamp.

The thing that people fail to grasp is that (almost) everything DHH writes is in the context of "when your application looks something like Basecamp" :-) I've been following 37signals/Basecamp since 2002, I think (long before Rails) and they've always made it clear that their opinions/advice are _not_ universal, because they only speak from experience - _their_ experience. So, if you're not in a similar situation as theirs, then of course their arguments are going to look strawman-ish to you.