pcmonk

Not having Android support is frustrating, for sure. However, I've come to appreciate the flow of only being able to really manage email on my laptop. I use the gmail app on Android so I get notifications and can send off a quick response, but I don't feel like I need to do anything else there, like set a reminder for myself or mark it unread. I know it'll still be in my inbox when I get to a computer.

Also, I've been using it fine on Linux, except that it didn't support Firefox when I tried it.

It's not the ordering that matters, it's simply that the odds of boy-and-girl are twice the odds of boy-and-boy.

That's equivalent to saying that buying a stock doesn't move the price up because you'll have to sell it eventually. A lot of people in long positions means a lot of buys that haven't been re-sold. A lot of people in short positions means a lot of sells that haven't been re-bought.

How do you do this with kids? Suppose you're taking three kids to an event or a climbing gym or whatever and it's further than walking distance. Can biking be made safe enough, or if it's further, is it reasonable for them to bring them on the metro? What if it's three kids ages 5 and under?

This is an honest question. I live in a city with public transport now and I much prefer it for myself, but when I think of how I was brought up it's hard to imagine that working without a car.

Just click the Keybase link next to the username, and you can verify each of the connections yourself.

This is wonderful!

One thing: It looks like it shows the DNS badges on Twitter but not HN.

That's correct, you can transfer off Cash app. However, you can't deposit BTC to your Cash app.

They could definitely use a unique salt if they just check for matches on registration, login, or password change (when they have it in plain text). Still insecure because then you have the info that two different salted passwords have the same plaintext.

Yes, in the last section:

> Roughly speaking, it’s rational to be surprised by an event if and only if that event requires investigation and explanation.

He addresses this in the article if you read a little further down. Briefly, any sequence of 1 million coin flips is equally unlikely, so why are most of them not surprising?

"Surprising" is fine. The title isn't "Why you're not surprised at throwing 92 heads in a row". There's no agent in the title, so he's referring to an objective idea of an event being surprising. I'm not sure I agree with his concept of "surprising", but it's at least objective.

The article is very misleading here. The cease-and-desist letter is clearer[0]. They intended to raise $15 million, but the SEC stopped them within a day of their ICO launch, when they had only raised about $60,000

[0] https://www.sec.gov/litigation/admin/2017/33-10445.pdf Fact 27

Basically, our purpose for the API changed. The old stack was created first as an MVP, then evolved a lot over time. We decided to make our API useful not just for our front end, but also for developers.

The mongo "schema" was a mess, and our data actually has quite a lot of relations, so postgres was an obvious choice. That was probably the most important change.

None of our current engineers have much experience in node (the one who built the api originally no longer works for the company), and we all dislike it as a language. The code itself was a mess, and would need to be rewritten even just to switch to postgres. Ideally, we wanted a language that was typed, functional, and good for web programming. We built small prototypes in Nim, Rust, and Elixir, and Elixir just ran away with it, even though its typing is less than ideal.

The graphql choice (and the direct impetus for the rewrite) was basically because we decided to make our api useful not only for our front end, but also for our users to interact with directly from their code. For this to be reasonable, the endpoints needed to be completely restructured, and we needed to expose a lot more of our database. It seemed pretty clear that having a single graphql endpoint to expose all our data would buy us a lot in terms of being developer-friendly. Even just exploring in GraphiQL is so much better than reading docs for a REST API.

Overall, it's taken about two months of my time plus the last couple of weeks of one other engineer's time to recreate it all and migrate the data.

We're in the final stretch of migrating our old node/mongo/REST stack to elixir/postgres/graphql (with Absinthe), and I'm absolutely loving it so far. Elixir is a great language, and Absinthe is very easy to use, even for a graphql noob like me. Even new/experimental features like absinthe_phoenix and absinthe_ecto have been virtually flawless.

I guess the real test will be when we deploy it to production on Tuesday!

From the second link:

> FLP and the Two Generals Problem are not design complexities, they are impossibility results.

Two generals, in its impossible form, isn't applicable here. For example, this proof[0] depends on the deterministic form being impossible to solve in a finite number of messages. But why would we care about doing it in a finite number of messages? By that measure, at-least-once delivery is impossible too, yet neither you nor the blogger seem to have a problem with that. The solution is easy and common: send a message, ack new messages, retry if you don't receive an ack, never ack an ack, and always ack a dupe. As long as you aren't disconnected forever, this will give you at least once delivery.

FLP only applies in the case of faulty processes. Specifically, FLP arises because the faulty process must either (1) ack the message before handling it, or (2) handle it before acking it. (1) fails if it crashes after acking before handling, causing it to forget it ever received the message (at-most-once). (2) fails if it handles the message, but doesn't persist that fact to disk, so that when the dupe is received it doesn't know it already handled it (at-least-once).

Urbit processes events transactionally (like a database), so you're guaranteed that if you received an ack it's because the other person has persisted that message or its results, and it won't forget about (i.e. they've persisted any state changes related to it). No faulty process, no problem. FLP impossibily doesn't apply.

I suggest actually learning about proposed solutions to problems rather than recalling that someone convinced you they were impossible to solve. Proofs are powerful because they're incontrovertibly true, but they only apply if their conditions are met.

[0] https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Proof

There are about 5 billion adults[0], and they don't all need separate planets. Married couples, for example, may not.

That's beside the point, though. Using scarcity to create value is not "extremely unconventional"; it's about the most ho-hum idea in Urbit. If you want a 128-bit address, you can use those in Urbit just fine. The only difference is that they don't have a default-positive reputation (where "reputation" is an abstract concept -- in practice, e.g. some channels wouldn't let 128-bit address post comments)

[0] https://www.census.gov/population/international/data/idb/wor...

> not all of the last 30 odd years of systems and programming research was pointless.

Indeed, which is why it's a shame our primary server OSes (Unix-likes) can't incorporate them. Urbit can.

As for what are the approaches different, there have been many words spilled over that, but here's a few examples to wit, most of which exist in one or two other systems, but aren't widely used:

- All events are transactions, down to the VM level. There's no concept of an event that left garbage around because power was cut or the machine was rebooted. You can always crash an event, making it as if it never happened.

- Single-level store. Never worry about ORM because your in-memory state never goes away (because all events are transactions).

- Persistent connections with exactly-once messaging. Disconnection is just seen as long latency.

- Strict, purely functional language with a strong type system but no Hindley-Milner (so you don't need category theory).

- Sane indentation for a functional language, known as "backstep".

- The file system is a typed revision control system, which allows intelligent diffs on types other than plain text.

Most, if not all, of these, have been described in research, but nobody's bothered to build a system with them.

They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work.

Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.

To most of us an "object" is something you can touch. We overload these terms all the time.

> To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones?

That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient.

"Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures.

In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.

> Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?

Urbit has always been fully open source as far as I know (at least since 2013). It is true that Tlon runs some of the galaxies and stars that most people use, but that's just because other galaxy owners haven't decided it's worth it to do so (because Tlon is doing a great job of it).

> "A value in Hoon is called a noun" - or you could just call it a value.

A "value" sounds like an abstract concept. A noun is one of two things: a natural number or a pair of nouns. Calling it a "value" makes it sound much more abstract than it is.

> "A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.

A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".

> They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.

The thing about revolutionary concepts is that their underlying principles are different than what you're used to, so if they look similar on the surface, you're lulled into thinking they're basically the same. But anyone who's put significant effort into programming in Urbit will tell you the system is fundamentally different. Not in the sense of "you could never understand what's going on here"; but rather, "we made these few different design decisions in the beginning, and that permeates everything".

IIRC, that particular episode happened in, like, 2013, when Arvo (Urbit OS) was barely prototype-grade. Urbit developers decided to work on the OS rather than chase after a bounty of about $1000.

There was also no meaningful documentation at the time, which is why nobody else could complete it.

If everyone has SSH access to a server somewhere, it's easy to just put a git repo there to let everyone keep working.

Obviously, this doesn't trivially scale to many repos/users/etc, which is why Github exists in the first place.

Oh, I agree. I guess I'm saying that if you want to live that life, that's great, go shrink your amygdala. However, if you haven't chosen that, then a smaller amygdala may not help you live a better life.

Sounds like a bad idea to me. People like Alex have a pretty short life expectancy.

Also from Arizona:

Eenie meenie minie mo / Catch a tiger by his toe / If he hollers, make him pay / Fifty dollars ev'ry day / My mom said to pick the very best one / And you are it

Yeah, but it's vim.tiny. They don't even alias it to `vim` because it's not full vim.

There's several good examples early in the article. Mostly, they end up in comments, where they're used as templates (e.g. "a social security number is of the form XXX-XX-XXXX").

Time zones in Arizona get extra exciting twice a year when the rest of the country jumps an hour for DST while we stay the same. Unless, of course, you're on the Navajo reservation, which does observe DST. Make sure you're not actually on the Hopi reservation, which is entirely surrounded by the Navajo reservation, because they don't observe DST.