4title: Common objections to Urbit
6preview: Some common objections to Urbit, discussed.
7image: http://media.urbit.org/site/blog-9.jpg
19We love crowdsourced criticism. We've heard a lot of great
20objections to Urbit. Surely there's more out there! If so,
21comments are open at the bottom of the page. We'll revise this
22document to include anything new and interesting.
24Here's our list right now:
26- [Urbit is not ready for prime time.](#prime)
27- [Nock jets are a total hoax.](#jets)
28- [Urbit needs an infinitely extending packet/event log.](#log)
29- [Urbit is a total scamcoin. It's 100% premined.](#scam)
30- [Urbit isn't even really decentralized! It has a government!](#gov)
31- [{Sandstorm, IPFS, Ethereum, ...} is way ahead of Urbit.](#sand)
32- [Urbit doesn't have enough planets for every human being.](#planet)
33- [Cloud computing is inherently non-private.](#pwned)
34- [Urbit will never be able to call any existing code.](#code)
35- [Hoon is too weird. No one will be able to program in it.](#program)
36- [Urbit programmers are stuck with Hoon.](#stuck)
37- [Ordinary users will never be able to manage an Urbit server.](#user)
38- [Urbit has no killer app.](#killer)
39- [Urbit is sniffed at by Houyhnhyms.](#horse)
41*"We choose to go to the moon, not because it is easy, but because it is hard."*
42— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)
44<h2 id="prime">Urbit is not ready for prime time.</h2>
48Urbit right now is a fun toy. It is fun to learn Hoon. It is
49even fun and quite practical to make actual contributions.
50(Hoon's IEEE floating-point was written by someone we've never
51met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never
52seen anyone *not* have fun with Urbit.
54But there is all kinds of stuff wrong with the codebase. Urbit's
55documentation is much improved, but remains incredibly weak --
56Arvo is almost totally undocumented. Scaling is poor at best.
57Urbit's reliability is dubious. Its security is nil.
59Urbit is feature-frozen. The only thing we're working on now,
60and for the rest of 2016, is doc, debugging and and self-hosting.
61In that order of importance -- teaching Urbit is more important
62than fixing it, which is more important than making it useful.
63But we're quite confident that these are all solvable problems.
65The most important milestone about Urbit today is that it's ready
66for technical decisions to be made collectively. A system like
67Urbit can only be invented by a mad auteur. It can't be
68maintained or stabilized by a mad auteur. Our primary goal today
69is expanding the number of people who understand Urbit, and we
70expect these pioneers to participate in technical governance.
72<h2 id="jets">Nock jets are a total hoax.</h2>
74**TLDR**: all of computing is a hoax. You can't compare a hoax
75to nothing. You can only compare it to all the other hoaxes.
77A "jet" is a sort of software device driver in Urbit. Urbit is
78precisely defined in terms of an interpreter that fits on a
79T-shirt, Nock. But a naive implementation of Nock is nowhere
80near practical, because Nock has only one integer operation:
81increment. For example, to decrement a number in Nock, you
82increment a counter up to the number under it.
84The only way an efficient Nock interpreter can work is to
85recognize algorithms like decrement, and implement them
86non-naively. By far the easiest way to do this is not to analyze
87arbitrary code as it's being executed, but to register and match
88well-known implementations in the standard library. No one
89should be writing their own decrement.
91But the semantics of the interpreter, *so long as the jet and the
92jet harness are defined correctly*, are exactly those of Nock.
93We are not extending or changing Nock in any way. We are just
94taking a shortcut in certain cases we understand perfectly.
96It's not at all unprecedented to have implementations much more
97complex than the corresponding specification. The x86
98instruction set is relatively simple; the complexity of its
99decoding and execution path in a modern CPU is enormous. This
100path may well have "peephole optimizations" that replace matched
101algorithms, and if it doesn't the modern compiler does. People,
102*bad* people, use "jets" to cheat on benchmarks all the time.
104Nock is designed as a standard. It's built like a standard.
105Typically what causes real problems in standards is ambiguity.
106Two implementations are incompatible, but each swears it has the
107right interpretation of the natural-language spec. This simply
108cannot happen in the Nock world. If two implementations
109disagree, at least one of them is incorrect. This puts us firmly
110in "with enough eyeballs, all bugs are shallow" territory.
112The fact remains, however, that a Nock interpreter without jets
113is completely useless. And there is not even an informal
114document that tells you what jets you need for a reasonably
115efficient Urbit. (There should be such a document.)
117The correct way to think about jets is not to compare them to a
118perfect interpreter created by unicorns. Jets are a combined
119replacement for two other techniques in language implementation:
120intrinsics and a foreign-function interface.
122Compared to both intrinsics and an FFI, your jets have one key
123disadvantage: they need to be specified in pure code. You may
124not have this executable specification, which means you need to
125write it. Is this really so bad for your development process?
126An executable specification? Which can be trivially tested
127against the efficient implementation?
129Compared to intrinsics, jets give you true separation between
130mechanism and policy; only the interpreter, not the programmer
131and not the compiler, needs to know what's accelerated.
133Compared to an FFI, jets preclude I/O, so can be trivially
134sandboxed. Except that the programmer needs to mark routines
135which may benefit from optimization with a hint, here too we
136separate mechanism (efficient implementation) from policy.
138Yes, formal verification of jet equivalence is desirable.
139However, in the real world, many specifications, including quite
140complex ones, are tested into equivalence by brute force.
142Urbit has some jet abuses. The equivalence between our markdown
143parser in Hoon and the CommonMark C library is super dubious. It
146But the miscomputation resulting from a minor jet discrepancy is
147not a security hole or even fatal. It effectively means the
148event history, computed correctly, does not match the current
149state. The way to resolve this conflict is for the current state
150to win, and the event history to be discarded -- not abnormal
151anyway. See the next question.
153<h2 id="log">Urbit needs an infinitely extending packet/event
156**TLDR**: no, it doesn't. Urbit can prune the log.
158We can prune the event log because the Urbit transition function
159doesn't have any access to the event history -- just the current
160state and the current event.
162Urbit defines the semantics of a complete event log. It doesn't
163and can't require an implementation to maintain the whole log.
164It can maintain a checkpoint and the log since that checkpoint.
165The current implementation of Urbit maintains
167However, any practical urbit maintains a periodically updated
168checkpoint. Our present implementation doesn't provide a way to
169prune the event log. But that's just a missing feature. We have
172<h2 id="scam">Urbit is a total scamcoin. It's 100% premined</h2>
174**TLDR**: yeah. But at least it's not the DAO.
176Like a cryptocurrency, Urbit is a digital title. But Urbit is
177digital land, not digital money. If you assess it as a currency,
178it's a lousy currency. If you assess a cat as a dog, it's a
181In real-world economics, the crucial distinction between land and
182money is that land (a) has intrinsic utility and (b) is
185Because of (b) alone, frictionless transactions in land are
186impossible. A blockchain is only needed to ensure zero-cost
187high-frequency transactions. So digital land doesn't need a
188blockchain. Which means it doesn't need mining.
190Of course, just because a digital title system doesn't need
191mining, doesn't mean it can't distribute an initial allocation by
192proof-of-work -- or by any other arbitrary method which is
193careful not to benefit the system's own developers. Could we
194give away the Urbit address space randomly? Sure. But why?
196Probably the purest design is the "proof-of-burn" initial
197allocation used by some coins. By any standard, proof-of-burn is
198technically beautiful and results in an extraordinary level of
199ethical independence. We can't help but admire it.
201But any altcoin or metacoin is just way less work than Urbit. An
202altcoin can afford to burn even its creation energy, capturing no
203value at all from its seigniorage. Your altcoin doesn't have a
204clean-slate system software stack to drive. If your rocket has
205to go to the moon, it's going to leave a little bit of smoke in
208Ethically, what makes "premining" feel wrong is that the creators
209of the currency are rewarded disproportionately for their effort.
210The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.
211Nothing about Urbit matches this pattern at all.
213Curtis invented Urbit. So by the [homestead
214principle](https://en.wikipedia.org/wiki/Homestead_principle), he
215started out owning all of it. But by now, Urbit's 8-bit galaxies
216have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).
217Curtis owns 20, or about 8%.
219Tlon, the corporation which still runs Urbit development, has 95.
220(Without Tlon, there is basically no Arvo.) 50 are reserved for
221a hypothetical Urbit Foundation. Tlon employees have another 16.
223The rest of the galaxies belong to donors, investors,
224contributors, contest winners, and just random people who were in
225the right place at the right time. One is a Silicon Valley
226tycoon. Another is an Orthodox nun in a monastery in Greece. A
227couple are ex-Tlon employees who might totally hate us. There is
228nothing they all have in common, which is sort of the point.
230This property distribution looks a lot like land ownership in the
231real world -- complex and asymmetrical. That's no accident. If
232you have a problem living in New York because New York's real
233estate is not distributed equally among its residents, you may
234have a similar problem with Urbit. The reality is that Urbit,
235like New York, wasn't born yesterday and comes with a complex
236ownership history which we couldn't possibly change, even if we
239Decentralization is hard. The only real goal of a property
240system in address space is to create and maintain
241decentralization. The whole network has to exhibit centrifugal
242force, not centripetal force. Proof-of-work systems certainly
243seem to have unexpected centripetal qualities, producing
244unanticipated concentrations of centralized hashpower. See the
247<h2 id="gov">Urbit isn't even really decentralized! It has a
250**TLDR**: it's technically impossible for Urbit to be
251decentralized at this stage of its life. Urbit is designed to
252achieve decentralization, not be born with it.
254A young network can't afford to be decentralized. It has to act
255as a unit. Because it has no network effect, it needs every
256scrap of efficiency it can get.
258A decentralized general-purpose computing network like Urbit can
259*only* be bootstrapped by a central government. For example, by
260default your urbit upgrades its OS automatically (like an
261"evergreen" browser) with signed network updates. Whoever signs
262these updates is a government by definition.
264When it's impossible to eliminate centralized power, it becomes
265necessary to tame, stabilize, and limit it. This should not be
266surprising to anyone living under a constitutional government.
268As we found out with the DAO, if a network isn't ready to be
269decentralized, its developers shouldn't even try. If Ethereum is
270hard-forked to roll back the DAO (which looks like the most
271probable result), it acknowledges that it both has a central
272government, and needs a central government. Decentralization is
273good. Pretend decentralization -- "decentralization theater" --
274is harmful, and not a effective path to actual decentralization.
276A key test of a free software project's health is whether it can
277fork. So long as the unity of the public-key hierarchy and the
278network protocol is maintained, the Arvo kernel and Urbit system
279can fork in all kinds of ways without disrupting the network.
280Any stress will fragment the "government" that develops the
281kernel, and as it fragments it grows more limited and stable.
283Urbit is designed to govern itself collectively by address space
284ownership -- effectively, "proof of stake." Any arbitrary power,
285will tend to fracture along these property lines. For instance,
286our hot updates are sent through the galaxy hierarchy; in a
287development fork, active galaxies would pick upstream sources.
288Two implementations of a standard are better than one.
290And by fragmenting the galaxy space into 57 separate partitions,
291we've created a global property map which is much more likely to
292splinter further, than reunite.
294In the long run, every galaxy should have a separate owner, who
295is a human being rather than a corporation. Combining galaxy
296holdings will damage the reputation of both galaxies. The only
297reason to merge ownership is to move toward incipient monopoly.
298Whether a galaxy admits this openly or denies it dishonestly, its
299reputation will suffer.
301The technical goal of Urbit is to create a network which, *if it
302actually takes over the world*, inevitably becomes decentralized.
303Even if Urbit takes over the world, no individual or coherent
304organization takes over the world. There is nothing even close
305to a single point of failure in a mature, successful Urbit.
307This is the goal of all the new "web3" decentralized systems. If
308IPFS, Sandstorm or Ethereum takes over the world, nobody takes
309over the world. (The same is almost true of the Internet --
310though it wouldn't be that surprising if a time traveler from
3112116 revealed that ICANN had become a planetary government.)
313Urbit, by starting out as a centralized network, just reduces the
314technical problem to match the actual goal. Only long-term
315decentralization matters.
317It's very important that Urbit in 2116 be fully decentralized.
318For Urbit in 2016, pretending to be decentralized would be a joke
319at best, and a hoax at worst. And of course, no one can DAO us
320-- since the property system is still just a central registry.
321Among other things, we check it into Github. Github is not a
322blockchain -- but still, good luck with that.
324<h2 id="sand">{Sandstorm, IPFS, Ethereum, ...} is way ahead of
327In general, web3 (next distributed web) solutions don't compete
328with each other. They support each other. Concretely, they are
329all part of each others' network effect.
331IPFS, Sandstorm, Ethereum, and Urbit can all take over the world
332at the same time. None of them competes with the others. They
335For instance, IPFS and Urbit are both global immutable
336namespaces. IPFS is a chord-routed, content-addressed namespace.
337Urbit is a direct-routed, identity-addressed namespace. Urbit is
338a typed revision-control system; IPFS is a blob store. IPFS
339isn't a computer; the work hasn't been done, but Urbit can easily
340mount the IPFS namespace and compute functionally against it.
342So the better IPFS does, the less Urbit needs to struggle against
343its lack of network effect. The better Urbit does, the easier it
344is for IPFS to point to a functional language that can actually
345use its referential transparency directly. So their relationship
346is symbiotic, not competitive at all.
348The closest thing to a general-purpose competitor that Urbit has
349is Sandstorm. Sandstorm, which by the way rocks, is also a
350personal server built around a network protocol.
352But Sandstorm and Urbit compete in the way that, on the PC, the
353OS and the browser compete. In theory, the OS could solve the
354problems that the browser solves; or the browser could be the OS.
355In practice, Windows is a great OS to run a browser on.
357Similarly, a world in which Sandstorm takes off is an awesome
358world for Urbit, because everyone who has a Sandstorm instance
359has a great platform for running Urbit on. Urbit on Sandstorm
360will be a sort of "double-hulled" personal server, safer and more
361friendly than either system alone.
363Sandstorm and Urbit have very different approaches to network
364identification; Sandstorm uses capabilities, Urbit identity.
365Broadly speaking, we believe, capabilities are optimal for
366expressive power; but identity is optimal for the UI of the
367common case. We'd need to see the Powerbox, Sandstorm's UI, more
368fully fleshed out to understand its UI approach better.
370<h2 id="planet">Urbit doesn't have enough planets for every human
373A 32-bit planet is a tool, not a toy. Like a car, it's a device
374for a responsible and independent adult. There aren't 4 billion
375cars in the world, nor 4 billion independent adults.
377If you aren't an independent adult, and you don't need or even
378shouldn't have unconditional digital freedom (no one's 8-year-old
379daughter needs unconditional digital freedom), a moon from
380someone else's planet is fine. (Even most of today's independent
381adults don't complain enough about being Facebook's moons.)
383And limiting the supply of anything doesn't create a shortage.
384It sets a price. Ideally, in the long run, we think a planet
385should cost about $10. This could be off by an order of
386magnitude either way, and it wouldn't be the end of the world.
388If a planet costs $10, that means you paid $10 to get a planet.
389A planet with no reputation has a positive reputation, because
390someone paid $10 for it and hasn't yet done anything wrong.
391Positive default reputation is the single quality that makes a
392social network social.
394There is always a tradeoff between free speech and free beer.
395Urbit will always choose free speech.
397<h2 id="pwned">Cloud computing is inherently non-private.</h2>
399**TLDR**: a general-purpose cloud computer is much, much more
400private than a special-purpose cloud computer. In general, a
401cloud VM is secure against corporations but not governments.
402With a global adversary, compute in your closet -- or even on
405One reason we want the decentralized Internet is that we're tired
406of giant corporations spying on us. Think about it this way:
407Amazon is Netflix's main competitor. And yet, Netflix runs its
408whole operation on AWS. Why is Netflix sure that Amazon won't
411A general-purpose virtual machine is special from a privacy
412standpoint, just because it's commercially realistic to design
413terms of service that prevent the host from peeking and poking at
414the customer's machine. Crossing this moat is technically
415nontrivial and can't possibly happen by any reasonable accident.
416No hosting contract could contemplate it.
418Whereas when your cloud computer is a special-purpose machine --
419just a database row on some corporation's mainframe -- there is
420no way these services can promise not to handle your data.
421Handling your data is *what they do*. On a special-purpose
422server, the concept of privacy is not even defined.
424Where even a general-purpose server falls down is where the user
425has a sovereign adversary, which can secretly violate explicit or
426implicit hosting contracts. Users with a sovereign adversary
427must rely only on their own physical security.
429However, most users don't have a sovereign adversary. And those
430who do maximize their "herd immunity" if they can use the same
431protocols as those who don't. Otherwise, the adversary could
432simply focus on everyone who uses the secure protocols.
434Also, the portability of a cloud server image is critical. Of
435course, since Urbit is formally specified, it's trivially
436portable. In fact, one strategy against sovereign adversaries
437may be continuous rotation between hosts, like an MX missile.
439<h2 id="code">Urbit will never be able to call any existing
442**TLDR**: neither will Javascript. And dear Unix, the browser
443does not miss interacting with your `$LD_LIBRARY_PATH` at all.
445You can't talk to the OS or use system libraries from Javascript.
446Therefore, there is no point in having any kind of gateway,
447compatibility bridge, native methods, or other interface between
450When in doubt, remember that Urbit is "the browser for the server
451side." It plays by the same general rules. Isolation means
454<h2 id="weird">There's no way Urbit will ever be
455adopted. It's too weird.</h2>
457**TLDR**: Urbit adoption is designed to be driven by ordinary end
458users. Urbit isn't ready for ordinary end users yet. We're
459working on it -- come help.
461Right now, Urbit is a developer tool. Or rather, a developer toy
462-- since the only thing it's useful for is developing Urbit. It
463also could be a much better toy. We're working on that too.
465But it's absolutely wrong to think of Urbit being adopted as a
466developer tool in the conventional sense. If you think this is
467almost impossible, you're right.
469If we look at the way most successful platforms are adopted,
470they're not adopted for their own virtues. They're adopted
471because they're part of a larger solution. It's very hard to
472displace a native component of an existing platform. Urbit is
473not trying to do this.
475C is a better language than Pascal, but it didn't beat Pascal
476because it's a better language. C beat Pascal because C was the
477native language of Unix, and people wanted to program in Unix.
478People don't use Javascript because Javascript is a great
479language, but because it's the native language of the browser.
480Replacing the native language of a platform may be doable -- but
483Hoon is not competing with C, or even Haskell, as a Unix
484programming language. The only reason to program in Hoon is that
485it's the native language of Urbit. Urbit is not competing with
486node.js or Rails as a Web backend. The only reason to run Urbit
487is to run a personal server.
489Nock is cool, but it only gets adopted if Hoon gets adopted.
490Hoon is cool, but it only gets adopted if Urbit gets adopted.
491Urbit only gets adopted if it's useful as a personal server for
492human beings -- most of whom won't be Hoon programmers, or
495<h2 id="program">Hoon is too weird. No one will be able to
498**TLDR**: Hoon is ridiculously simple. Our documentation and
499tooling are just immature.
501It's pretty fair to assume that (a) functional programming is
502hard and weird, (b) Hoon is weird even for a functional language,
503so (c) Hoon must be hard-squared.
505Actually, Hoon is weird even for a functional language because
506it's an attempt to remove the hardest things about functional
507programming: category theory, lazy evaluation, and gratuitous
508abstraction. To know a language is to know what the compiler is
509doing; all the semantics of the Hoon compiler fit in 2000 lines
512It's too easy for us to wind up living in Isaac Asimov's Trantor,
513a world in which everything got invented thousands of years ago
514and the idea of new technology is just weird and scary. History
515isn't over yet, and nor is technical history.
517New things are harder to learn than old things. We ask smart
518high-school students to learn calculus. Think about how much
519harder it was for Newton and Leibniz to invent calculus, or for
520their first students to pick it up. Hoon is nowhere near as hard
523Most of the difference is just the collective certainty that our
524society conveys to a high-school student that calculus is
525learnable. When you're learning Urbit, you don't have this
526collective knowledge; so you don't have the confidence that the
527problem is solvable. Confidence makes a huge difference.
528Moreover, any bug or glitch in the developer experience destroys
529this confidence and takes a long time to heal.
531Yes, we know: Hoon remains quite hard to learn. Again, we have
532no reason to think this problem isn't solvable. Public
533enlightenment remains our main priority.
535<h2 id="stuck">Urbit programmers are stuck with Hoon.</h2>
537**TLDR**: patience, grasshopper.
539There's quite a straightforward way to implement any perfectly
540specified language with a reliable interpreter in Hoon. First,
541write an interpreter for that language in Hoon. Second, jet that
542intepreter function with the existing implementation.
544It is not clear that Javascript is *quite* well-defined enough
545for this treatment. But Lua probably is.
547<h2 id="user">Ordinary users will never be able to manage an
550**TLDR**: Urbit's technical simplicity has always been designed
551to drive human usability. But the polish is the last thing that
552goes on. So we can't evaluate this claim right now.
554Right now, Urbit is only for geeks. You already need to be able
555to wrangle a Unix machine to run it. What's the point?
557This Urbit isn't the real Urbit. It's an early milestone on the
558way to the real Urbit.
560The real Urbit -- for normal human beings -- is a hosted service.
561Getting a planet is as easy as signing up for Facebook. Probably
562many users will think of it as another web account. They might
563not even know it can run more apps than the ones they use.
565A deterministic, persistent cloud computer is something different
566from a traditional server. Normally when we think of a server in
567the cloud, we think of it like a live animal -- a creature that
568needs to be cared for, fed, and herded. A file in the cloud is
569more like a rock -- you can forget about it for ten years.
571An urbit is a general-purpose computer, but it doesn't even have
572the concept of a reboot. It upgrades itself. If you don't feed
573it any packets for ten years, then turn it back on, it will spend
574a day or two upgrading itself, then be back to normal. Maybe
575it's something in between a rock and an animal -- a cactus?
577Another huge difference versus an Internet server is that we're
578confident that Urbit's limited supply of identities will make it
579easy to keep abusers off the network. So far, so good -- but of
580course, no one abuses a young network.
582The bottom line is that managing your urbit has to be as easy as
583managing your iPhone. Normally, it consists of deciding what
584apps you want to be running, and how much you trust them.
585Resources can't be free, so sometimes you have to play memory
586police. Humans have shown that they can handle these tasks.
588Our '70s OSes and networks, which were great designs in their day
589and have matured into excellent industrial tools, give us a
590totally misleading impression of how hard it should be to manage
591a general-purpose computer. Computing isn't scary or dangerous.
592Unix and the Internet are scary and dangerous. That's fine for
593an industrial tool, but not a personal tool.
595<h2 id="killer">Urbit has no killer app.</h2>
597**TLDR**: the killer app is personal API aggregation.
599It's a truism that any new platform has to be fundamentally much
600better at solving some problem than the mature platform it seeks
603We can look at Urbit's killer app from two perspectives: as a
604developer, and as a user.
606From the developer's perspective, Urbit's advantage is that it's
607a network stack which provides exactly-once delivery of typed,
608validated, transactional, encrypted and authenticated messages.
609The difference between an Urbit API and a REST API is like the
610difference between a paved road and a dirt road. On the other
611hand, you do need to learn a new functional language.
613From the user's perspective, there's one task that any personal
614server can perform, that can't be performed by any Web service:
615unrestricted API aggregation.
617Well before Urbit is ready to *replace* any conventional web
618services, it should be ready to *command* them in place by API.
619(Or if needed, by scraping.) If all you care about is being in
620control of your own data, it's fine to leave it in the hands of
621these services, as you have the API secrets to get it out.
623Managing a set of security connections to your existing services
624is one of the first important tasks of a modern personal server.
625This is a stateful task that typically requires both a durable
626API key and a temporary OAuth token. APIs change all the time,
627so connection maintenance also requires evergreen updates.
629The origin of this API key will vary, but usually the best way to
630set it is BYOK: the user registers their own urbit as an "app."
631And the neat thing about having your own API keys, for multiple
632services, on a single general-purpose computer, is that none of
633these services really has any practical way to control what you
634do with your own data.
636Terms of service which constrain the use of data (as opposed to
637the abuse of the service) simply aren't realistic and will no
638longer apply. This enables a variety of novel user experiences
639which aren't implementable as traditional web services, and also
640aren't available via conventional third-party API aggregators.
642Also, since Urbit is after all quite immature, it doesn't make
643much sense to restrict this security state to code within Urbit.
644The Urbit interpreter `vere` runs as a Unix daemon that
645implements the FUSE user-level filesystem protocol, and maps the
646data on your services into the Unix filesystem. For example, one
647of our demos lets you `ls` your Github issues.
649So it's straightforward to build, for instance, a Python app that
650uses Urbit as a gateway to mash up a bunch of web services. As a
651Unix programmer, you might even just regard Urbit as a generic
652Web API gateway daemon, without worrying about its internals.
654We have other ideas for initial killer apps. But this, we feel,
655is the best one. API libraries for `npm` et al abound.
656Stateful, self-updating, generic API aggregators with FUSE
657integration, also integrated with a reactive web server, are
660<h2 id="horse">Urbit is sniffed at by Houyhnhyms.</h2>
662It's difficult to categorize [this awesome
663essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)
664in a single bullet point. So I've saved it for last.
666When reading this essay, it's important not to forget the amazing
667absence of genuine, mutually critical discourse in computer
668science (as in most sciences today). You never hear what Swift's
669designers think of Go, or vice versa. And critical public
670discourse decreases, not increases, with increasing academic
673The basic test of any field purportedly scientific in nature is
674whether its researchers are genuinely interested in each others'
675work, and willing to share these genuine responses publicly. If
676this practice does not exist, the field may still be useful
677and/or interesting. But it is not science.
679What's awesome about Fare's essay is that he's *doing it right*.
680All the actual details are irrelevant. And mostly wrong. But
681that's of very little importance compared to *doing it right*.
683Anyway, we've already addressed the idea that jets are a sham.
686### Event-sourcing and/or caching is a pattern, not a layer
688Fare' is perfectly right that "one size does not fit all" in
689persistence. Generally, Urbit uses event-sourced persistence.
691But it has multiple layers of event-sourcing: in the definition
692of Urbit itself; in the application sandbox vane (Gall), and in
693the application itself. Urbit also has a completely orthogonal
694revision control system (Clay).
696And there is not a single cache across the whole system, though
697arguably there should be; for instance, the functional build
698system (Ford, which Fare' the master of build systems might
699appreciate) has its own internal cache.
701It is a common mistake to confuse a design pattern with a layer
702or feature, and equally fatal whichever direction you fail.
704### Let's be clear about why DSLs suck
706DSLs suck not because they are difficult to newbies in the base
707language. DSLs suck because every time a programmer, even one
708*experienced* in the base language, comes into a new codebase or
709project, she has to learn a new custom language.
711You need enormous wins to justify this cost. It's the goal of
712the base language designer to preempt these wins, creating a
713language which is almost never so tiresome and full of
714boilerplate that it requires a DSL or template layer.
716Hoon is almost entirely made of macros -- but they are internal,
717fixed, built-in macros (with no gensyms). This fixed set of
718macros is essentially enough. Occasionally we want to add one or
719two. But we never, ever pine for context-dependent macros.
721### Determinism is not consensus, and is not constraining
723Fare' is totally right that an urbit's data is meant for itself
724alone. In fact, an urbit has the right to compute incorrectly if
725it wants. We go to considerable lengths to ensure that you can't
726gain any particular advantage by incorrect computing.
728The whole point of Nock is that it's so low-level that there is
729no conceivable advantage in upgrading it. Divergence is just
730pointless. This is not a question of network integrity, just of
731practical standardization.
733This consistency stops at Nock. Without anyone violating the
734correctness of their lifecycle functions, anyone or everyone in
735Urbit could replace Hoon with Javascript. Determinism does not
736cramp Urbit's semantic style in any way, shape or form.
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list