[JDulin]

Oh, Urbit! Where to begin?...

First of all, this is staggeringly brilliant. You should pay attention to it in the coming months. I am not sure if it's destined to be the future, but I sure as hell hope it is.

I had the privilege of interning at Tlon, the company working on Urbit's development, this summer. It owns most of the namespace (Personal cloud computer IP addresses, essentially.) and is where the architect of the system works full-time. They are funded, well enough, by VCs you know of. Urbit is not really launched yet though - We spent the summer doing a lot of work getting the network, file system, protocols, and application layer in "Industrial grade" shape, and I believe more of that is happening this fall.

Because the system is still unlaunched and the docs are being retooled, I imagine these pages are discombobulating. That's... expected. Urbit has a lot of odd ideas that take time to appreciate. However, if you do take the time to understand the motivation behind the design of everything from Hoon's appearance to the network protocol replacement for TCP to the vision for future social networks, you'll find some of the best and most complete computer science research done in decades in networks, systems, and functional programming. The essential idea is not an outlandish one - We need a new basis of computing and networking to build digital identities with, and 1970s system software is not up to the task.

It's unfortunate that ambition and a sense of humor can be misinterpreted as a joke today. For now, you'll just have to take my word for it [1] that these guys are deadly serious and have the technical chops to back up their ambition. Future documentation and applications built on the OS should soon make that more immediately evident.

[1] Or start reading the tutorials!

[lumpypua]

https://github.com/urbit/urbit/blob/master/urb/zod/arvo/ames...

There are hundreds of lines of noise. This makes perl and forth look absurdly readable. What on earth do the directory and file names mean?

I dunno how familiar people on HN are but the original author of urbit is Mencius Moldbug, a neoreactionary blogger. His style of writing is absurdly obfuscated and purposely impenetrable if containing some interesting ideas. The exact same thing is true of urbit. Interesting ideas but obfuscated the point of utter inaccessibility.

Here's sort of the wider group of blogs he philosophically aligns with:

http://rationalwiki.org/w/images/d/d5/Scharlachs-visualizing...

His views are likely unpopular around here but I am a fan of a bunch of those other blogs, and I've tried to dive into Moldbug's blog Unqualified Reservations a few times. It's kind of insane—the guy is clearly very intelligent—yet writes in his own discursive style that is absolutely opaque.

[urbit]

Stepping away from the Algol keyword tradition is obviously a risk. At the same time, after using a keyword-free syntax for a while, reserved words feel really weird.

Someone just emailed and pointed out that he couldn't check out Urbit on Windows, because it has a file con.c. Oh, right, reserved filenames. How are reserved words different? The difference is - you're used to them.

Also, perceived usability (while it matters for marketing) is not the same thing as actual usability. Actual usability is something you only find out when you try to actually use something. We have a good bit of experience inflicting the syntax on coders of various abilities and backgrounds, and we're pretty satisfied with the result.

It helps that the syntax is quite a bit more regular than it appears at first glance. It's much more regular than Perl, and it also comes with a vocalization model that makes it easy to say out loud.

For instance, "=+", which more or less declares a variable, is "tislus." A lot of things like "=+" also start with "=", ie, "tis." You wind up learning about a hundred of these digraphs or "runes," which is a lot less than, say, Chinese.

Speaking of Perl, have you heard - Larry Wall is a Christian? I don't think this makes Perl a Christian programming language, though.One of the joys of our engineering inheritance from the 20th century, which was really humanity's golden age of political insanity, is that we get to stand on the shoulders of loons. We fly Christian astronauts into space on Nazi rockets programmed by Communist physicists. And it works...

[jrochkind1]

> it also comes with a vocalization model that makes it easy to say out loud. > For instance, "=+", which more or less declares a variable, is "tislus." A lot of things like "=+" also start with "=", ie, "tis." You wind up learning about a hundred of these digraphs or "runes," which is a lot less than, say, Chinese.

Uh... you realize this isn't helping to convince anyone?

The project may well be brilliant rather than ridiculous, but if so I suspect you're gonna have to come up with a better pitch to get people interested enough to invest the time to see it.

Your made up language where every punctuation mark is a phoneme or something... it's not helping.

And I should hope any programming language would indeed be easier to learn than Chinese (or just about any natural language).

[urbit]

Don't worry - the test of a system is what it can do. If we were ready to show you what it can do, we'd have released it intentionally instead of unintentionally.

It's very difficult for a language, good or bad, to compete on its own merits or even demerits. C is a better language than Pascal, but people didn't start programming in C because of that - they started programming in C because the native language of Unix was C, and they wanted to program in Unix. Why did they want to program in Unix? Because, relative to its competitors in the minicomputer OS market, Unix was a better way to solve their problems. This is the normal way that new languages achieve adoption - they ride on the back of a new platform, which rides on the back of new solutions to (typically) new problems.

Today you see a lot of apps like Buffer and Slack, which are very successful in terms of userbase and even revenue. From a certain perspective, the value these apps are adding is very minimal - Buffer is... what, cron? And yet, there is a considerable distance between an AWS box in the cloud and a Buffer instance. A lot of value actually is being added.

Most of the code in a product of this type is actually the (usually somewhat) general framework that sits between the Linux ABI and the application logic/UI. Essentially there's a type of Greenspun's Law in play. If you build a layer like this, but as a true operating environment rather than an internal framework, the result is a VM in which the distance from a virgin instance to many of these kinds of apps is much smaller. In a familiar Valley pattern, they then become commoditized and have more trouble extracting rents.

If it's possible to provide this kind of value, which we certainly haven't yet demonstrated, I can assure you quite confidently that a flashcard or two is not an obstacle. I'm in my 40s, so I know how hard it is for a middle-aged dog to learn new tricks. But it's not that hard.

[jrochkind1]

On the other hand, if people had found C very difficult to program in, it probably would have hurt the adoption of unix.

In fact, if I understand the history, developers and sysadmins generally found C an improvement on their previous tools, and generally saw how it was so fairly quickly, without a lot of convincing.

You keep insisting that the... oddities of your language aren't really barriers, aren't as difficult as they seem, really aren't much worse than the conventional way to do things. But I think I've missed it if you've tried to explain why they are supposed to be better, what the justification is for such an unconventional approach, what it's supposed to actually accomplish to be worth it.

(beyond no reserved keywords in the domain of a-zA-Z, only reserved punctuation instead... which I don't think is convincing many people, who haven't really had much of a problem with reserved keywords).

(And the 'reserved keywords' thing doesn't even apply to your "lapidary" thing, which you insist really isn't that hard to deal with once you get used to it, which may or may not be true for people... but what makes it _better_, what's the point? Why not just use meaningful variable names everywhere, instead of taking an extra step to decide if it 'needs' meaningful variable names, or if instead obfuscated 'lapidary' variable names are sufficient? Maybe they're sufficient maybe they aren't, but what's the point, what's the harm in just using meaningful variable names in case they are helpful for a future reader?)

[urbit]

If you look below I've made arguments for all these things, but let me try to address them here. Compare

  ++  add
    |=  [a=@ b=@]
    ^-  @
    ?:  =(0 a)  b
    $(a (dec a), b +(b))

to

   attribute add {
     function(left-operand: atom, right-operand: atom)
     produce atom
     if equals(0, left-operand) {
      right-operand
     } else {
        recurse(left-operand (decrement left-operand)), 
                right-operand (increment right-operand))
     }
   }

As for the variable names, I can think of very few programmers who would insist that "left-operand" and "right-operand" are better names, in this context, then "a" and "b".

Using "a" and "b" accurately expresses the simplicity of the algorithm, and nothing could be easier to read. OLV in "add" says: there is nothing interesting here. "left-operand" and "right-operand" says: there is some semantic meaning here, which you have to trouble your brain to understand. But actually, it's just pointless wordiness - in this case.

As for the syntax, you no doubt can read my wordy example better. But a programming language is a professional tool, not a toy. Anything new demands a genuine investment to learn - this investment has to be paid off by actual productivity.

And people are, as I've said, much better at learning random associations than they think. Again, we've taught this syntax to everyone from Haskell jocks to JS cruft-jockeys to innocent CS 101 victims. The biggest problem - and it is a problem - is not that it it is hard, but that it seems hard.

[Locke1689]

Is the given text your attempt at eliminating reserved keywords by using nonsense as keywords?

Other languages have simply decided to use contextual keywords, which preserves familiarity and flexibility.

[urbit]

Good lord, no! Hoon has no reserved words at all.

The nonsense words are all names. This is entirely a style choice. The actual name syntax is roughly Lisp's - for instance, (my-long-function arg1 arg2) does the same thing (roughly) in Hoon as in Lisp.

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant).

The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

I think our small sum of experience with this daring idea is that sometimes, it works better than other times. Basically, TLV naming is appropriate for code that is simple, but not trivial. (Trivial code, like "++add", is "ultralapidary" and gets OLV names - like "a" and "b".)

Ideally all of the Arvo kernel and Hoon self-compiler would meet the TLV standard of quality. All of it is written this way, though. In general, if you should be writing lapidary code, you know it, and if you don't know you shouldn't. (And should use more or less normal names as in any Lisp.)

[Locke1689]

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant). The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

Have you been reading a lot of Heidegger or was this an independent decision?

[urbit]

The latter. :-)

[melloclello]

Do you have any examples of what "non-lapidary" Hoon might look like?

[zerker2000]

I'm not sure much strictly non-lapidary hoon exists, but for samples marginally less lapidary than the kernel, I would like to point you to a simple algorithm translation at https://gist.github.com/MichaelBlume/17a227cc839f52f68c97, and the twitter library /main/lib/twitter/core.hook in the standard distribution.

[likeclockwork]

Please define "TLV", "OLV", and "lapidary".

[urbit]

Three-letter variable, one-letter variable, http://www.merriam-webster.com/dictionary/lapidary.

[tromp]

Three/One Letter Variables.

Lapidary:

(of language) engraved on or suitable for engraving on stone and therefore elegant and concise.

[likeclockwork]

https://github.com/urbit/urbit/blob/master/urb/zod/arvo/eyre...

What is pimp? What is pest seam marl?

What do any of these names mean? What does any of this do? Forget not knowing the syntax, the names look like gibberish.

[urbit]

I think the classic analogy is "grep." But they are commented, at least:

  ++  pimp              ::  traced request
    $:  ful=?           ::  | === HEAD
        fur=(unit mark) ::  type goal
        hen=duct        ::  event trace
        som=seam        ::  logical request
        pez=pest        ::  request state
        sip=marl        ::  injected scripts
    ==                  ::

I think this is not at all an unusual data structure for one to find in an HTTP server, no?

Now, this style (four-letter lapidary arm names, usually not nonsense strings but nonsense words) works in some places but not others. Frankly, %eyre is not exactly a triumph of the lapidary style...

[likeclockwork]

This Hoon code is very pretty but the English content of the names is extremely low.

I mean.. reading a programming language I don't know, okay.. I don't expect to be able to understand much. But syntax and semantics aside the names are a language of their own with no attempt at referencing anything that might even be a little bit similar.

It's as though every time you needed to name a concept you came up with a unique word for it. This reads like poetry in a language I will probably never understand.

The docs are written in English but I don't see a lot of signal in here and no real explanation of this vocabulary you've created.

I am having a hard time believing any of this. I would need to see an example of non-code communicative writing in this language. An email or chat excerpt, something with someone saying "call pimp with the seam to get the marl" or however you would phrase whatever it is. Do you verb these nouns? DO you use English prepositions and adjectives when discussing them?

I mean this is not just reading a programming language I don't know, it's reading a programming language with all the names in a foreign language. So even if I could understand broadly what's going on here.. I cannot.

Searching around the repo to try to find out wth `marl` is I found this:

    The fundamental hoon structure used to generate XML is a    manx. A manx is composed of a marx and a marl, representing an XML node

Yeah.. this is like esolang-level opaque. I'm afraid to even run this on my computer.

[urbit]

Frankly, it always surprises me that people are willing to randomly run other peoples' C code! It's really quite plausible that I'm just out to steal your Bitcoin wallet.

The above are all data structures - not even functions. So we say "a pimp" or "a marl" or whatever. For precision, we might say "slam a gate on a pimp," but everyone will understand you when you say "call a function on a pimp."

Then, we refer to the comments (written in English) to see what a pimp, etc, is. Documentation is admittedly a problem, but it's not any more or less a problem than in any other language, I feel. Obviously, we could have more of it!

[MrBuddyCasino]

He does have really odd political views. I know HN shouldn't be about politics, but this was a really interesting read:

http://www.thebaffler.com/blog/mouthbreathing-machiavellis/

It looks like he thinks that the benevolent-dictator-for-life model is how countries should be run. And Peter Thiel seems to agree with him.

[VexXtreme]

They even seem to have a subreddit: https://www.reddit.com/r/DarkEnlightenment/

The whole "ideology" is basically just fascism and institutional racism dressed up as something else. Despicable. I would never use any software from some Hitler-reboot type of person. Don't empower and feed such people. They are usually narcissistic megalomaniacs who think they are fit to rule and tyrannize others.

[lexcorvus]

Before accusing someone of being a "Hitler-reboot type of person", perhaps you should, you know, actually read what they have to say about Hitler. For example:

Since most people are neither historians nor philosophers, the fact that Hitler was on the extreme Right, and this Reaction is also on the extreme Right, raises some natural concerns. Again: the only way to face these concerns is to (a) provide a complete engineering explanation of Hitler, and (b) include an effective anti-Hitler device in our design.

—Mencius Moldbug, http://unqualified-reservations.blogspot.com/2009/09/gentle-...

In other words, an explicit design goal is to avoid Hitler-like outcomes (because, duh). Thus, the accusation that he's a "Hitler-reboot type of person" reflects either simple ignorance—which you can fix by doing a little reading—or outright mendacity—for which, I'm afraid, there may be no cure.

[VexXtreme]

I mean look, I understand what the philosophy is about, and I think it would never work in the real world. We've learned time and again that entrusting a lot of executive power to one person is a horrible idea - extremely exploitable and subject to corruption.

Looks almost like a product of a deranged autistic mind. I have no interest in such asinine "philosophies".

[Padding]

> I have no interest in such asinine "philosophies".

I bet no one does .. the real issue is how to decide on what is "asinine". After all, why are your views and beliefs any more valid than any one else's?

[niels_olson]

What if his engineering concern with Hitler is the the mode of failure?

[loqi]

Would you use software from some anti-gay-marriage person? Do these types of policies sound at all pathological to you upon further reflection?

[jarcane]

That is quite actually one of the creepiest things I've read in a while. I've always been fundamentally uncomfortable with a certain wing of Valley thought, but man, even I didn't think it went that far and in such lofty halls.

[mikeash]

I thought it was pretty common to think that a benevolent dictatorship was a great way to run a country. The problem is in making sure your dictator is benevolent. Nobody knows how to do that, so we try non-dictatorial systems instead.

[MrBuddyCasino]

Exactly.

[javaexpert101]

Yarvin's weird political views aren't really part of Urbit.

[valvar]

I haven't read all of Unqualified Reservations, but what I have read so far (Dawkins, Open Letter, Gentle Introduction) has not been difficult to read at all. Perhaps long and winding, but not opaque. In fact, I find Moldbug to be much more accessible than his sources of inspiration (which are standard fare if you even want to even begin with political theory).

[lexcorvus]

Yeah, people who think Moldbug is opaque should try reading a little Carlyle. A few years back I spent a week powering through Carlyle's main political works (Chartism, Latter-Day Pamphlets, Shooting Niagara, and the Occasional Discourse), and it took a couple of days just to get acclimated to his writing style. By comparison, Moldbug is a breeze.

[ricardobeat]

Wow, now I'm curious about the language. Looks like made-up gibberish at first sight:

    ++  lax                                           ::    lax:as:go
      |_  [her=ship dur=dore]                         ::  per client
      ++  cluy                                        ::    cluy:lax:as:go
        ^-  [p=life q=gens r=acru]                    ::  client crypto
        ?~  lew.wod.dur  !!
        ?.  =(fak.ton r.i.lew.wod.dur)  ~|([%client-wrong-fake her] !!)
        :+  p.p.q.i.lew.wod.dur
          q.q.i.lew.wod.dur
        (haul r.q.i.lew.wod.dur)
      ::

[urbit]

Suppose we wrote this with keywords. I can't stomach a naked keyword so I'll put a colon on the front. We might write:

  :function lax {
    :object :tuple{her: ship dur: dore}  {
      :function cluy {
        :produce :tuple{p: life q: gens r: acru}
        :ifno lew.wod.dur  :error
        :unless (equals fak.ton r.i.lew.wod.dur) {
          :record :tuple{%client-wrong-fake her}
          :error
        } :then {
          :tuple {
             p.p.q.i.lew.wod.dur
             q.q.i.lew.wod.dur
             (haul r.q.i.lew.wod.dur)
          }
        }
      }
    }
  }

Is this better? Arguably, it's easier to learn. But I'm not sure I would regard it as better.

Also, for your convenience we've assigned CVC nonsense names to all the ASCII characters. Pasting from the source:

  ++  ace  (just ' ')
  ++  bar  (just '|')
  ++  bas  (just '\\')
  ++  buc  (just '$')
  ++  cab  (just '_')
  ++  cen  (just '%')
  ++  col  (just ':')
  ++  com  (just ',')
  ++  doq  (just '"')
  ++  dot  (just '.')
  ++  fas  (just '/')
  ++  gal  (just '<')
  ++  gar  (just '>')
  ++  hax  (just '#')
  ++  kel  (just '{')
  ++  ker  (just '}')
  ++  ket  (just '^')
  ++  lus  (just '+')
  ++  hep  (just '-')
  ++  pel  (just '(')
  ++  pam  (just '&')
  ++  per  (just ')')
  ++  pat  (just '@')
  ++  sel  (just '[')
  ++  sem  (just ';')
  ++  ser  (just ']')
  ++  sig  (just '~')
  ++  soq  (just '\'')
  ++  tar  (just '*')
  ++  tec  (just '`')
  ++  tis  (just '=')
  ++  wut  (just '?')
  ++  zap  (just '!')

One of the problems with using these handy little glyphs in syntax (and an even worse problem with using Unicode glyphs in programming, btw) is that "semicolon" is not convenient to say. The length of the vocalization matters a lot to how you think about a symbol, even if you don't often say it.

[axlprose]

> Is this better? Arguably, it's easier to learn. But I'm not sure I would regard it as better.

For what criteria of 'better'?

I can't really present an argument either way since I'm not familiar enough with the language, but it does seem like it requires a fairly high amount of cognitive overhead for... I'm not sure exactly. Keystrokes?

There is something to be said about the efficiency of glyph-based writing systems like kanji, so APL might've been on to something, but overloading common ascii characters and creating meaningless words? That seems like a lot of noise for brains without extraordinary working memory to filter out on a regular basis.

I'm sure thinking and writing in it are fine (even brainfuck isn't difficult to write), but for something intending to be the backbone of the internet, I would've assumed maintainability to have been the most important design goal.

[urbit]

Essentially, I'd say most peoples' brains are better at associative memory than they think they are.

When you see a digraph like -> or ?: in C, do you think "hyphen greater-than" or "question-colon"? Your brain long ago learned to treat these as individual symbols, not strings of two characters. And this despite not even having easy-to-say names for them. (In Hoon they are "hepgar" and "wutcol" respectively.)

[gpvos]

The digraph operators are not a large problem for me. I'm used to Perl, so I'm sure I can master them. But what is a lew.wod.dur, and what is lax supposed to mean? What happened to variable names that made at least a nod to descriptiveness? Why do you think adding a two-word comment to a function is enough to make it all crystal clear?

[JDulin]

As a coder of "various ability and background", I found that Hoon source code was a relaxing joy to read and write after a few weeks of dedicated study.

It is, believe it not, designed with readability as a first-class priority. However, a common meme in language design today is that "Code should read like prose." This sounds good, because it means languages are easy to learn. Who wants to learn a bunch of symbols and patterns and junk? I want to code (Python, JavaScript, etc.) now!

But when we program, we aren't dealing with the trivial knowledge English is efficient at exchanging in an email, or the subtly it portrays in a novel. We are talking to a computer. The ideas we explain to a computer are often much more complex than we can explain precisely with English in any reasonable amount of time, so complex we often lose ourselves in them.

Mathematicians and physicists gave up on making human language explain specific technical ideas long ago. Have you ever read a paper on cosmic topology or quantum field theory? There's a comforting padded bumper of English framing the ideas, but the reason the paper is published is in symbols which would appear to the uninitiated as "hundreds of lines of noise." The English is usually just an introduction.

I think Hoon is wonderful [1] because it has both power and predictability. Power lets you express complex ideas concisely and easily, while predictability lets you read and understand someone else's code without frustration. Perl is powerful because it's dense, but it does so at the cost of predictably. Mathematics symbols are terribly powerful, but wildly unpredictable [2]. Python is sort of powerful and sort of predictable. The seductiveness of English simulacra programming languages is that you often don't realize how much power you're giving up because it's just so relaxing to not think about symbols and patterns when your code has the predictability of an email.

Hoon's power is in the zoology of runes (Digraphs) and it's predictability is rooted in its homoiconicity. Every symbol on the keyboard is utilized to build powerful runes, each of which in turn is utilized to append predictable structure onto your AST. When you understand the basic patterns of these constructions and reductions, it's not hard to read someone else's library and understand it in an afternoon. I can't say the same for the Java SDKs I come across. [3]

I'm not saying it isn't inaccessible at first and doesn't take time to learn. I am saying it is worth it.

[1] It's my favorite language - It is just plain fun.

[2] That's why the English frame around a physics paper is there - It tells you what each symbol represents in this paper and what they're trying to do.

[3] The language design also includes several decisions to avoid the pratfalls of other homoiconic languages (Primarily the readability of Lisp), but those are explained in the docs.

[rgrieselhuber]

Is that image of associated blogs generated using some tool?

[jcburke]

Wait, so they wrote their own bytecode, functional language (complete with compiler and libraries), functional operating system, TCP replacement, and distributed storage protocol? And will presumably write all their own apps, or some kind of interface layer that will allow non-Hoon code to run on their system efficiently? That has to be one of the most ridiculously ambitious projects I've ever seen. Good luck to them I guess, but I've always been a believer in not reinventing too many wheels at once

[urbit]

Perhaps it makes a bit more sense if it's explained that the original goal was to keep the whole codebase (outside of the C support layer, which adds no semantics) at 10Kloc. Unfortunately this is now rapidly slipping toward 20.

Of course, Kloc is a deceptive measure of algorithmic simplicity in a functional language, if compared to procedural. Also there is about another 15Kloc of C in the interpreter and another 10K that wraps an event layer on libuv.

Bear in mind that Urbit can also be seen as an ACID database on the log-and-snapshot principle - events are transactions. You can of course export application state to some other storage system, but you don't have to. (If you change the source code, your app reloads - you do have to write a function that maps your old state to your new state, though.) So there is a lot of strange futzing around with mmap at the bottom.

[guscost]

I never would have guessed that Urbit has funding. That sounds like a very interesting job.

[djur]

Peter Thiel is known for his financial support of both neoreactionarism and various types of out-there futurism; I wouldn't be surprised if he's involved, and I'm sure he's not the only jillionaire with similar interests.

[guscost]

On the other hand if someone told me that a certain angel is funding Urbit, I would probably have guessed that it was Peter Thiel. It seems like just the kind of ambitious/ridiculous and politically loaded project he would be interested in.

I have no idea whether Urbit is as significant an idea as Mr. Moldbug suggests, but it's too interesting not to try out at least.

[clarkm]

> Peter Thiel is known for his financial support of... neoreactionarism

Do you have examples?

[djur]

Sure. He funds Eliezer Yudkowsky through MIRI; "friendly AI" futurism is at this point a branch of the "Dark Enlightenment". Thiel himself has famously said "I no longer believe that freedom and democracy are compatible".

[alexandros]

The first sentence above is completely false. Eliezer Yudkowsky has explicitly stated that he has nothing to do with the reactionaries, and the latest stats on the friendly AI community (as gathered at lesswrong.com) show about 2% of members are neoreactionaries. Further, with FHI at Oxford, FLI at MIT, CSER at Cambridge, the Superintelligence book being endorsed by everyone from Elon Musk, to Stephen Haking, to Morgan Freeman, calling MIRI/Friendly AI a branch of the reactionaries can't be anything else but a deliberate attempt to smear people's reputation.

I'm on the record as having several severe criticisms of EY/MIRI, but being neoreactionaries is not one of them.

[djur]

EY has made a point of saying that he has nothing to do with Moldbug, but ideologically there isn't much room between Moldbug-style techno-monarchism and the 'friendly AI' utopia.

I'm referring more generally to the "Dark Enlightenment" than just neoreactionaries. In that group I include pretty much any group focused on alternatives to liberal democracy, with carve-outs for Marxists and fascists. EY fits comfortably into that category (see his "Politics Is The Mind-Killer" tract).

[urbit]

I'm quite confident that Eliezer would object strenuously to this characterization!