I don’t have a stake in this but the page does say

> delivers microsecond performance at any scale

and then

> a very large hash table that is distributed across multiple machines

So the way that I read it, the network will be involved when they said “at any scale”.

I’m on iOS too. I see why you might think there are two different j there but what’s actually going on is that since the quoted text is in italics, and the text is wrapped on our iPhones so that the second italic j is on the next line of text, part of it is outside of the “bounding box” of the text of sorts, and is clipped off in rendering.

I appreciate your corrections and elucidations of this typographical mystery.

> I think this has led to the US educating many persons who later leave the country for visa issues

I’ve never been to the US but, if this is the problem then wouldn’t it be better to make it easier for people to stay also after they have finished their degrees? If the goal is to have a lot of highly educated people in the US I mean.

I agree. I'd like to see more educated foreigners stay in the US through a more sensible immigration policy. But another way to attempt to fix the weird brain-drain is by controlling who is getting the education.

USA educates more international students (by far) than any other country. I think the goal of policies like this is to prefer US students. But you're right that it would also be nice if foreign students had an easier time staying in USA after they graduate.

It wouldn't just be nice - it'd be smart. We could probably have more immigrant-owned business and immigrant-developed inventions of we made it easy for foreign born US graduates to stay. Both of which should add jobs to the economy and make the US more economically competitive.

I think everyone would support that kind of policy except where it would have an adverse effect on American students. The goal of policies like this are to promote USA students admission to higher education over foreign students. But the reality is that foreign student tuition is a huge money-maker. So USA students are at a disadvantage in the admissions process.

I wish HN had a top nav link and a mechanism like it has for “Show HN” posts, but for demoscene stuff. The prefix one would use could be “Demoscene HN” or something, and the rule would be the same as for the “Show HN” prefix – that using it is “allowed” only when the submitted of the link was involved in making the thing :D

I was not aware that Steam had changed their policy on sharing sales data. That is great! Are there any other indie devs that have shared the data about their Steam sales in a similar fashion? Better yet, is there a good list of links gathered somewhere for that?

I don't live in the Netherlands but I just wanted to say that it's a very inspiring project and also that it is a great thing of you to do that you are giving it away to someone else.

Upvoted and hoping it finds a good home :)

Speaking of which, coming from Rust (well, when I say it like that it sounds like Rust is the only language I ever used which is of course not true. I think Rust as a first language would be highly unusual still), I enjoyed being able to say

Rust code:

    let foo = if x <= 0
    {
        0
    }
    else if something_else > 50
    {
        9000
    }
    else
    {
        42
    };

And I miss this in Swift.

The ternary operator is fine on its own but I’m not a huge fan of nested ternary operators. With a bit of whitespace it's somewhat readable still but still not as comfortable and easy to read correctly.

Swift code:

    let foo = x <= 0 ?                0 :
             (somethingElse > 50 ? 9000 :
                                     42 )

One way of writing something that is more similar to the way I'd write it in Rust would be to make a closure and then run it.

Swift code:

    let foo =
    { () -> Int in
        if x <= 0
        {
            return 0
        }
        else if somethingElse > 50
        {
            return 9000
        }
        else
        {
            return 42
        }
    }()

But it's a bit annoying still, both to read and to write. Also, even in the current version of Swift (Swift 5), the compiler cannot infer the return type of the closure on its own even though all of the branches return an Int, so I'd have to explicitly annotate that as I have done in the code above.

I guess for a lot of people they would just make foo mutable and write the code as

Swift code:

    var foo = 42
    
    if x <= 0
    {
        foo = 0
    }
    else if somethingElse > 50
    {
        foo = 9000
    }

I concede that this is probably the most readable out of all of the three Swift code samples in my comment. But the point is that I didn't want foo to be mutable. I wanted to assign a value to it based on some simple logic and have it be immutable.

I find ternary operators perfectly readable if you split the parts across lines — they map exactly to the conditions and statements in an if-else group.

    Cond1 // if this
    ? Result1 // return this
    : cond2 // else if this
    ? Result2 // return this
    : cond3 // else if this
    ? Result3 // return this
    : ResultElse // else return this

I've come to hesistently accept nested ternaries, but I try to have all lines lead with a colon. This kinda mimics a switch statement with returns.

  firstPossible ? thenThis
    : secondPossible ? thenThisOtherThing
    : thirdPossible ? thenThisThirdThing
    : defaultThing

Always fun to see how people treat ternary nesting. They still feel a bit naughty to me. The terseness is sort of unbeatable though.

It's funny how people have so many different preferences for ternary formatting. I can't think of any other operator that would have tens of different format prefs.

Which is not true in PHP up until the most recent version (iirc) due to it being left associative instead of right associative you are assuming.

True, or even:

    Cond1 // if this
      ? Result1 // return this
      : cond2 // else if this
        ? Result2 // return this
        : cond3 // else if this
          ? Result3 // return this
          : ResultElse // else return this

Goodness me that has potential to become something truly hideous.

It's actually not that bad in practice... But I guess the pragmatic formatting is "whatever `prettier` does by default" anyway. :)

It's funny how people have so many different preferences for ternary formatting. I can't think of any other operator that would have tens of different format prefs.

I dislike the ternary operator in languages like C++. And many languages copy-paste it because they are used to it. I much prefer the more literal and reversed form in Python.

Instead of:

int salary = isEmployed() ? 2000 : 0

I prefer:

int salary = 2000 if isEmployed() else 0

Yes, it also makes the larger example somewhat readable:

    func calculate_tax(income):
        return 0 if income < 10 else 20 if income < 50 else 50

I love that idea, but I still prefer it’d read the same as an if. Meaning the condition first and the false case last.

Rust implements this:

    let foo = if is_employed() { 2000 } else { 0 }

I'd guess i fall into the mutable camp, while sometimes doing a closure.

Nested ternary if statements scare me from my PHP days, and noticed inlined closures can at times be harder to grok at a glance.

Agreed. Plus if the else clause has a side effect, you can't assign it to the variable, which means you need to instantiate to null or a dummy value. Very messy.

What's funny is that expression oriented languages translate really nicely to stack VMs. My hobby language compiles down to WASM and it was almost trivial to code gen if expressions.

Agreed about missing if and switch expressions in Swift. My preferred way of writing that would be:

    let foo: Int
    if x <= 0 {
        foo = 0
    } else if somethingElse > 50 {
        foo = 9000
    } else {
        foo = 42
    }

That way you get immutable foo and the compiler will shout at you if you forget to assign the value in one branch. It's not quite as nice as an expression, but it's less punctuation than the closure and the result is just as safe.

It's probably not the most idiomatic thing, but in Rust you can write:

    let foo = match () {
        _ if x <= 0 => 0,
        _ if something_else > 50 => 9000,
        _ => 42,
    };