How we made Haskell search strings as fast as Rust - <AUTHOR> https://tech.channable.com/posts/2019-03-13-how-we-made-haskell-search-strings-as-fast-as-rust.html <comment><USER2> as maintainer of two of the haskell libraries they use, a member of the core libraries committee, and a hackage trustee, i'd like to throw in my two cents:

1) i see they are doing fully qualified imports. please add major bounds to your version deps, stack doesn't excuse not tracking what versions you used!

2) they have

"data Next a = Done !a | Step !a " in their code,

this tells me they could have possibly benefited using the stream abstraction in Vector!

[https://hackage.haskell.org/package/vector-0.12.0.2/docs/Dat...](https://hackage.haskell.org/package/vector-0.12.0.2/docs/Data- Vector-Fusion-Stream-Monadic.html) is a link to the latter

<comment><USER3> About (1).

The exact versions they used are specified by the stack.yaml file.

In this case, see [https://stackage.org/lts-13.10](https://stackage.org/lts-13.10)

Stack has a feature that lets you automatically added bounds to a hackage upload based on the stack.yaml. (However, I personally do not recommend using this feature, as those bounds usually end up being overly restrictive. Manually-written bounds are better.)

<comment><USER2> yet its off by default and most users dont use it.

I do agree human judgement based bounds are best, but stackage snapshots aren't that. Furthermore, stackage/fpo LTS is not LTS in the same sense as linux-distributions and their BSD-unix cousins. Proper long term support in any meaningful sense is a commitment by the distro provider to backport security/bug fixes to the LTS. Stackage LTS doesnt do that.

stack tricks its users into not thinking about their relationship with their dependencies and poisons library code from being usable by haskell devs/users/contributors who dont use stack. :)

the more you know! :)

</comment></comment></comment><comment><USER4> I can't speak to the content or Haskell at all but I really like the clean formatting of the post, particularly the charts and images. Does anyone know what tool might have been used to produce them? So clean and crisp.

<comment><AUTHOR> It's LaTeX, tikz, and pgfplots for the images. Complied with xelatex to pdf and pdf2svg to svg. The rest is custom HTML and CSS. We use the Hakyll static site generator.

<comment><USER5> Yes, can confirm. Check out [1] and [2] to learn more about TikZ and PGFPlots.

[1]: [http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf](http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf) [2]: [http://mirrors.ctan.org/graphics/pgf/contrib/pgfplots/doc/pg...](http://mirrors.ctan.org/graphics/pgf/contrib/pgfplots/doc/pgfplots.pdf)

</comment></comment></comment><comment><USER6> Impressive work! The clincher is at the end

> Relying so much on optimizations to ensure that very high level code > compiles to the right low-level code is fragile. Case in point: after > upgrading our Stackage snapshot from LTS 10 with GHC 8.2.2 to LTS 13 with > GHC 8.6.3, we saw the running time of our benchmark double.

This would scare we about doing any real performance optimization in a language as high-level as Haskell: am I just fiddling with compiler internals now?

</comment><comment><USER7> What actually amazes me is that... Python is good enough:

> A naive Python script that loops over all needles and calls str.find in a > loop to find all matches.

> working through all 3.5 gigabytes of test data once

> Time is ~6.5s.

I love these kinds of benchmarks. They consistently show that for specialised cases you do need to drop down to C/Rust/hand-written Haskell implementations. In many-many more cases, well, even Python with a naive implementation is good enough.

Not to diss Haskell or Rust. Only saying: chose your tools as you see fit, and benchmark.

Also kudos to the authors to use mean instead of average in the graphs.

<comment><USER8> > Firstly, the program spends most of its time in the heavily-optimized > str.find function, which is implemented in C.

I'm not going to outright call this "cheating", but most of the time, virtually unconditionally, when Python is fast it's because it isn't Python, it's C.

It definitely feels worth noting that Python is radically slower than other languages, and the main "tool" it provides for improving performance is to rely on another language entirely.

<comment><USER9> Well Python is written _IN_ C, at least the standard version is, so I really wouldn't call it anywhere near cheating... :).

But I don't disagree that the Python owe's it's performance to C.. it owes _everything_ to C :)

<comment><USER8> I think there's a very big difference between the runtime being implemented in C and the libraries being implemented in C.

<comment><USER10> Example Java: Runtime written in C++, practically all libraries written in Java, including the standard library, and Java libraries are greatly preferred.

</comment></comment></comment></comment></comment><comment><USER11> > Clearly there was plenty of room for speeding up our string matching. We > considered binding the Rust library, but due to the way that Haskell's > foreign function interface interacts with the garbage collector, passing a > string to a foreign function requires copying it. That copy alone puts any > foreign library at a significant disadvantage, so we decided to see how > close we could get in Haskell alone.

It's a shame Haskell copies strings across FFI boundaries, because binding the Rust version would have been almost as fast, with (presumably) significantly less effort.

<comment><USER12> I wondered about this and poked at the internals of ByteString (suitable for ffi) and Text. Turns out Text could allow ffi by changing a single function (newByteArray to newAlignedPinnedByteArray).

Presumably creating lots of small strings is a typical use case for Text so losing compacting gc hurts. ByteString on the other hand is more used with binary data and is designed for ffi use.

<comment><USER13> Hmm ByteString has the opposite issue and solved it with ShortByteString. Seems like PinnedText could be the analogue.

</comment></comment></comment><comment><USER14> Interesting article.

Out of curiosity: how much optimizing potential is in the software that was programmed by Burntsushi in Rust?

<comment><USER15> There is definitely some room. As usual, it depends. I'm away from the computer, so I haven't had a chance to look and see if the OP's benchmarks are published. So it's hard for me to say anything specific at the moment.

In the literature, there are generally two different variants of Aho-Corasick. The traditional formulation follows failure transitions during search, which comes with overhead. In effect, it's an NFA since search can traverse through multiple states for each byte of input that it sees. The other variant is the "advanced" form, which is just effectively turning the NFA into a DFA by precomputing all of the failure transitions into a single table. This can be quite a bit faster depending on the workload, but obviously uses more memory and takes more time to build. My library supports the DFA version, but it had a bug (which has now been fixed) which prevented the OP from effectively benchmarking it.

The OP hints that some substantial number of samples use a very small number of patterns. Sometimes only one. In that case, it probably wouldn't be best to use Aho-Corasick at all. Instead, it should use an optimized single substring search algorithm, such as Two Way. Even for multiple patterns, if there aren't that many of them, it might be better to use Teddy from Hyperscan.

This article is fairly timely. I'm almost done a rewrite of my Aho-Corasick library. It will bring some small performance improvements (but more importantly a simpler API), and I hope to move the Teddy algorithm into it at some point.

As always, specific workloads can often have their performance improved quite a bit.

<comment><USER16> You should borrow "FDR" from Hyperscan as well. :-)

AC sucks. It's simple enough, but it's always going to be either slow or big - sometimes both. I'd say that's a source of frustration to me, but it's not really, as we made a lot of money selling string matching to customers back when Hyperscan was closed-source. It's so much easier to sell string matching than regex matching as regexes are full of surprises, but strings are quite tractable.

I'm not delighted with where we left string matching in Hyperscan - "FDR" was wheezing under load in a bunch of ways, and I had some better things in the pipeline. But it still should generally murder AC barring some corner cases.

Unfortunately, Hyperscan has moved away from having a pure-play literal matcher in it (what remains is really more of a specialist 1- to 8-char literal matcher), which I regard as a semi-mistake (so there may be more corner cases than there used to be).

<comment><USER15> I thought FDR was for single literals only?

One of the hurdles for using the algorithms from Hyperscan is that it's not always clear when particular algorithms are used and in what conditions. I have the same problem in my regex library, but Hyperscan takes it to another level because it's so much more sophisticated. :)

<comment><USER16> (see other response)

FDR is for > literals than Teddy. It's Noodle that's for single literals. Hard to imagine how you could get confused given that the names we chose are so transparent. :-)

<comment><USER15> Hah. I've only made it halfway through your paper so far. Excited to read the rest. :)

</comment></comment></comment></comment></comment></comment><comment><USER17> Why UTF-16? Seems like an odd choice of character encodings.

<comment><USER18> It's what Haskell's 'text' type uses internally. This stackoverflow question seems to discuss why that is the case:

[https://stackoverflow.com/questions/23765903/why-is-text- utf...](https://stackoverflow.com/questions/23765903/why-is-text-utf-16-as- opposed-to-utf-8)

<comment><USER19> Sadly every language developed in the 90s has this flaw. Stuck somewhere between bytes and actual UNICODE.

<comment><USER20> To be more clear, this flaw happened because way back when we thought UCS-2 was sufficient. Then UTF-16 happened and all these systems designed for UCS-2 had to be hacked up for UTF-16 instead.

<comment><USER21> To be even more clear, this happened because early versions of Unicode consisted of fewer than 2^16 code points, and this was thought to be enough. In 1996, Unicode 2.0 was published and allowed characters whose encoding required more than 16 bits. This necessitated UTF-16 which allows expansion up to 32 bits to represent characters in higher planes (and is compatible with most text that had been encoded in UCS-2).

<comment><USER22> > allows expansion up to 32 bits

It doesn't allow expansion up to 32 bits. How would that even be possible? Some of the bits are needed to indicate to use the second two bytes, so there's a hole in the range and it's less than 32 bits.

<comment><USER18> "Surrogate pairs" use two code units (32 bits total) to increase the number of code points that can be represented. It seems a lot more complicated than UTF-8. I have no idea how many code points can actually be represented in theory. There are under 21 bits' worth of Unicode codepoints, though, so I'm sure the claim that UTF-16 can represent all of them isn't some kind of trick.

<comment><USER20> A surrogate pair can represent 20 bits, or 2^20 values. A single UTF-16 byte is of course 16 bits, or 2^16 values. 2^20 + 2^16 == 0x110000, which is precisely as many unicode code points as there are (0–0x10FFFF).

Decoding UTF-16 (with surrogate pairs) is pretty similar to decoding UTF-8 except the state machine is simpler (as it's just 1–2 code units per codepoint, instead of 1–3). It also means that if you validate that you have a high surrogate and a low surrogate, the combination is guaranteed to be a valid codepoint (whereas with UTF-8 there are invalid encodings, e.g. any 1-byte codepoint can actually be encoded using 2 or 3 bytes instead, which the state machine must reject).

<comment><USER18> Wait a minute.

"A surrogate pair can represent 20 bits, or 2^20 values. A single UTF-16 byte is of course 16 bits, or 2^16 values. 2^20 + 2^16 == 0x110000, which is precisely as many unicode code points as there are (0–0x10FFFF)."

This explanation can't be quite right, because the possible surrogate code unit values are carved out of the set of 2^16 code units. So you are double counting those surrogate code units.

From Wikipedia: "Since the ranges for the high surrogates (0xD800–0xDBFF), low surrogates (0xDC00–0xDFFF), and valid BMP characters (0x0000–0xD7FF, 0xE000–0xFFFF) are disjoint, it is not possible for a surrogate to match a BMP character, or for two adjacent code units to look like a legal surrogate pair."

<comment><USER18> OK, I've found the gross reason why the 2^16 + 2^20 arithmetic works:

"The Unicode standard permanently reserves these code point values for UTF-16 encoding of the high and low surrogates, and they will never be assigned a character, so there should be no reason to encode them. The official Unicode standard says that no UTF forms, including UTF-16, can encode these code points."

Ugh.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Converting the function to act as a fold instead of just returning a lazy list, is that necessary because all the unboxing and strictness internally meant the matches couldn't actually be lazy?

<comment><USER12> Lazy data structures require allocation. GHC's lists use build/fold fusion to remove intermediate lists but that's basically just a less reliable way of converting to folds [http://hackage.haskell.org/package/base-188.8.131.52/docs/src/GH...](http://hackage.haskell.org/package/base-22.214.171.124/docs/src/GHC.Base.html#build)

The other common fusion technique used in haskell is stream fusion which is very similar to the mutual-recursion-encoded-as-sum-type version in the blog post.

There is also indexing-based fusion which the Repa library uses. It allows more control over traversal order (think optimizing stencil codes) but requires regular arrays, e.g. no filtering.

There are some other research projects like specialized compiler passes via hermit but afaik nothing really production ready.

<comment><USER20> Ok so not using a lazy list for matches is basically just around avoiding the requisite allocation? I suppose if you consume the list immediately at the call-site the compiler could in theory after inlining convert it to the closure-based approach for you, but probably wouldn't.

</comment></comment></comment><comment><USER16> It's a pity that Aho-Corasick always seems to be the starting point for this kind of work, because it's as slow as a wet week and/or the tables are huge (pick your poison).

To do this right you need a fast prefilter and a reasonable fast string match. Our string matcher in Hyperscan blew AC away on size and speed, typically. Unfortunately, I never had a chance to build its successor. But AC is a disaster of one dependent load after another and is mediocre at best in terms of performance.

<comment><USER15> It's really not a pity at all, considering that:

1\. There is no write up of the Hyperscan algorithm of which you speak. I wrote up a part of Teddy, but I still don't understand the full algorithm. Hyperscan's code takes serious effort to understand. I spent days staring at Teddy and I still didn't get everything.

2\. Aho-Corasick is reasonably simple to implement and does fairly decently for a large number of tasks.

3\. Aho-Corasick is trivially portable.

<comment><USER16> Ha, there's a _paper_ about FDR now.

The fact that AC is portable and simple and that everyone feels good about themselves as a result of implementing a classical-sounding algorithm (why AC and not Rabin-Karp? who knows?) is why is keeps cropping up, like kudzu. It's still either (a) huge, (b) slow, (c) both and (d) a poor fit for modern architectures - it has a way of turning the problem into a latency problem for whichever level of memory its structures fit into (rather than a throughput problem).

It's _a_ solution. Big deal. There are half-a-dozen better ones just floating around in the literate, but this shitty one seems to be the one people fixate on. Maybe it's because Aho and Corasick sort earlier in the dictionary than Rabin and Karp?

<comment><USER15> It's been a while since I looked into Rabin Karp, but I remember there being two issues: 1) it really wants all of its patterns to be the same length and 2) it doesn't scale to a large number of patterns. Aho-Corasick has its own issues at scale, but only to the extent that your proportion of memory reads that hit cache decreases. But honestly, I've never implemented it in anger.

I'll have to take a closer look at FDR. I thought it was for single pattern search, not multi pattern search.

I don't really understand why you're being so bombastic about this. AC has a number of nice qualities, as I mentioned above. We don't need to resort to bullshit about how it's only used because it makes people feel good about themselves. That's not a good way to win people over to your cause.

<comment><USER16> I've spent years benchmarking against various AC implementations; typically in Snort. They're usually stupidly huge and slow.

Rabin-Karp needs a fair bit of help to work; I mention it as a starting point. As a core matching technique it isn't much more fancy than "put your stuff in a hash table". Handling strings of different length _is_ in fact hard but using multiple tables is viable. It scales a lot better than Aho-Corasick in that you can engineer the size of the hash tables and anticipate performance.

Conversely, AC just develops a huge 'root cloud' when the pattern sets get big - increasingly, you're always in a prefix of something. It tends to benchmark well (sorta, kinda) especially if you feed it input that doesn't look much like what you're trying to match. You then just bounce around a couple shallow states that get to be resident in L1 and you look pretty smart.

Also, in Rabin-Karp or fancy variants, every access is independent of every other, a property that you can only dream of in AC as you pootle from state to state making reads that depend on what you did last.

"FDR" works on a different principle - it is 'bucketed SIMD shift-or with super-characters' (see the paper).

I have a third matcher in the wings based on PEXT, which I must finish up.

Honestly I don't care what people do. Arguably a good deal of the money we made from Hyperscan in its closed-source era came from selling a 'regex' matcher came from just doing the simplistic case of multiple literal matching. Our Rabin-Karp thingy (multiple hash tables with different lengths and strides) was called "hlm" (originally, "Vomitsauce"), took a few pages of code, wasn't that conceptually complex, and probably by itself (sans regex) netted a few hundred thousand a year (we eventually replaced it with FDR). This is borderline ridiculous; making money of a big complex regex matcher seemed well-deserved, but making money off a simplistic task like this seemed like picking up bills of the ground.

What frustrates me is that people don't generally look beyond one solution, don't innovate, and don't care that they aren't innovating or reading the literature. Apparently algorithm design is a parlor trick for getting into Google, not a thing that one might actually _do_.

<comment><USER15> > Honestly I don't care what people do.

You can't have it both ways. You clearly care to some extent. Whatever though. Clearly we disagree on how to approach this stuff. I realize you probably don't intend this, but you really come off as belittling others for not being as smart as you. It's not cool.

> Conversely, AC just develops a huge 'root cloud' when the pattern sets get > big - increasingly, you're always in a prefix of something. It tends to > benchmark well (sorta, kinda) especially if you feed it input that doesn't > look much like what you're trying to match. You then just bounce around a > couple shallow states that get to be resident in L1 and you look pretty > smart.

The OP constructed a benchmark from exactly the task they are trying to do and did algorithm development until they got a better result. That seems like exactly the right way to approach this. Not everyone is in a position to make an extra few hundred thousand dollars by switching from AC to Vomitsauce.

That's all I'm trying to do too. It's going to take a _long_ time for the field to collectively catch up to Hyperscan. It'll take me years, if I keep on my current path.

<comment><USER16> I think the field should _pass_ Hyperscan, not catch up to it. There are a number of things about HS that I'm increasingly uneasy about.

As for the rest I'm done. I don't think I can adequately explain my irritation at the general state of discourse about the things I worked on for 12+ years without coming off in all sorts of ways I don't really intend. Suffice to say I've seen things you people wouldn't believe, strawmen comparison implementations on fire off the shoulder of Orion, etc. :-)

I will try to write up my new string matcher at some point, in a less convoluted context than Hyperscan. HS, from sheer complexity, makes almost all algorithms more or less undiscoverable - it's hard to avoid having some busy- body subsystem jump in front of the simple demo you're trying to do.

<comment><USER15> > I think the field should pass Hyperscan, not catch up to it. There are a > number of things about HS that I'm increasingly uneasy about.

Right. I meant it as a short-hand way of saying, "it will take a while for the field to catch up to the battle tested knowledge you've accumulated, of which, some is expressed inside Hyperscan." :-)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> This does seem to actively circumvent a number of the things that are always held up as why Haskell is a great language: it uses strict types in a number of places, has explicit inline and no-inline annotations everywhere.

It also seemed to require a lot of work to construct the code to make tail call optimization happen, but that's par for the course in Haskell.

<comment><USER24> I'm not that versed in Haskell myself, but is this really the case? I would think that expectations for low level optimization and general code are different.

Though, I suppose you could then say that if the rules are different for low level optimization, they may as well have imported an external library written in Rust.

<comment><USER25> Optimized Rust feels more idiomatic at least.

<comment><USER26> but I don't think it's a suprise, since rust is made to be fast while haskell is made to be beautiful (for some sense of beautiful)

</comment></comment></comment></comment><comment><USER27> "A naive Python script that loops over all needles and calls str.find in a loop to find all matches. This is not Aho–Corasick [...]".

I'm the author of pyahocrasick, a python C extension that implements the AC. I'd love to see it in the comparison. :)</comment>


ClojureScript, Lisp's Revenge [video] - <AUTHOR> https://www.youtube.com/watch?v=MTawgp3SKy8

<comment><USER2> I happened upon the video through a different source yesterday. Saw it. Didn't really get the title. Sure he quickly ran through the What-Why-How-Perf- Examples of ClojureScript. Had I not already been interested in Clojure/ClojureScript, I would have walked away from the talk thinking whats the big deal? Other languages also compile to JS and vanilla JS isn't all that bad once you get to know it. So yeah, just by watching the video, I didn't understand what the title meant by 'Lisp's Revenge' or even 'Hoare's Revenge'.

EDIT: Before viewing the presentation I wasn't aware who the presenter, David Nolen, was. I was aware of the online persona "SwannOdette" and his blog posts [1] were a major reason for me seriously considering ClojureScript. During the presentation I realized that "SwannOdette" and "David Nolen" are one and the same. His blog posts [2][3][4] are a lot more convincing than this video.

Some day I will write in vanilla Javascript the corresponding code for the examples in those posts. That will truly help me appreciate the advantages Cljs brings to the table. Incase someone else does that, please do reply here.

[1] - [http://swannodette.github.io/2013/11/07/clojurescript-101/](http://swannodette.github.io/2013/11/07/clojurescript-101/)

[2] - [http://swannodette.github.io/2013/07/12/communicating- sequen...](http://swannodette.github.io/2013/07/12/communicating-sequential- processes/)

[3] - [http://swannodette.github.io/2013/07/31/extracting- processes...](http://swannodette.github.io/2013/07/31/extracting-processes/)

[4] - [http://swannodette.github.io/2013/08/31/asynchronous- error-h...](http://swannodette.github.io/2013/08/31/asynchronous-error- handling/)

<comment><USER3> David is a great guy, but sometimes his talks don't get the point across in a powerful way.

Clojurescript uses CSP (same concept as Go channels invented by Tony Hoare) to allow simulated multiple concurrent threads of execution in javascript. How many compile to javascript languages have concurrency? not many.

Clojurescript has powerful immutability at the core of the language, macros that are so powerful they can add concurrency to single threaded javascript via a library.

I admit it's not simple to understand everything clojurescript has from a casual glimpse, but if you learn enough, it can really kick all the other compile to JS languages in the butt.

<comment><USER4> "macros that are so powerful"

You just made every single Common Lisp programmer who reads your comment cringe.

Clojure is a very nice language and while it has no real innovations it does bundle a few unusual (for mainstream) concepts into a single easy to use package. However, you should wait with calling Clojure macros "powerful" until after you get access to readtable. Or wait, you won't ever, that's a feature, supposedly...

<comment><USER5> Clojure has something better than CL reader-macros [1]. These are name-space specific, and more composable than CL's reader macros.

And reader-macros can be achieved with a small hack [2].

[1] [http://www.infoq.com/interviews/hickey-clojure- reader](http://www.infoq.com/interviews/hickey-clojure-reader)

[2] [http://briancarper.net/blog/449/clojure-reader- macros](http://briancarper.net/blog/449/clojure-reader-macros)

<comment><USER6> That's a just small part of Lisp's reader macros.

</comment></comment></comment></comment></comment><comment><USER7> I really like Clojure (and have enjoyed David Nolen's CLJS tutorials and guides), but I find ClojureScript to have terribly arcane tooling. Despite being familiar with Clojure, it's still 10 minutes of cargo-culting and copy- pasting before I can start actually working on a ClojureScript project. Slightly ironic for a language which places such an emphasis on removing "incidental complexity."

<comment><USER8> If Emacs is your thing, which it should be if you do Clojure, DPPs starter project Spiffy, will give you very decent setup in a couple of minutes. [https://github.com/dragonmark/spiffy](https://github.com/dragonmark/spiffy)

<comment><USER9> > _If Emacs is your thing, which it should be if you do Clojure,_

This is the kind of attitude that keeps people away from your language. The amount of people who shun away from C# simply because they don't like the idea of Windows / Visual Studio should be a hint.

<comment><USER10> That's more of a Lisp problem than a Clojure problem. All the Expert Lisp Programmers settled on Emacs many moons ago (as in decades past) and no one has bothered to write another (good) Lisp-friendly text editor since. And well, you can't really write Lisp without a suitable text editor, so all the Lisp neophytes either give up or learn to cope with emacs and eventually forget about replacing it.

<comment><USER11> Could you explain what you mean by a reasonable text editor? Thanks

<comment><USER12> I suspect he means one that has paredit.

<comment><USER10> Even before that, it's shocking how few text editors have basic Lisp indentation and REPL support.

I guess I did forget about Light Table (as AFAIK it doesn't support Scheme or Common Lisp yet), which seems like the right thing to point beginning Clojure programmers to.

Hell, that's probably a big part of why Clojure became more popular than the previous Lisps.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> David Nolen is passionate, bright, and brilliant. I watch some of his talks every now and then when I want to get hyped up to get some coding done.

<comment><USER14> David Nolen inspires me with his grasp of programming concepts & paradigms. Watching his talks and the other clojure geniuses truly inspire me. You are so right about the passionate, bright, and brilliant part. I feel his enthusiasm to iterate the world into a better place to code in.

</comment></comment><comment><USER15> Goto conference is pretty awesome. Saw this live in DK was really inspiring.</comment>


The Boring Company FAQ - <AUTHOR> https://www.boringcompany.com/faq <comment><USER3> So, the key ideas are:

\- Smaller diameter tunnels. 14' is suggested. This is slightly larger than the deep London Tube lines.

\- Electrically powered TBMs. Those exist. However, often the business end of the machine is hydraulically powered. Musk is probably thinking of going all electric, at least for the cutter head. After all, he has lots of experience with high-torque electric motors.

\- Do cutting and tunnel ring assembly simultaneously. Some TBMs already do that. Those exist; they're called double-shielded TBMs.

Issues glossed over:

\- Soil variability. Very different techniques are required for different soils. Sometimes the soil has to be "conditioned", adding something to make it solid enough it can be drilled through.[1] This is the biggest practical problem in tunneling. Too much water is the usual problem.

\- The back end. TBMs are long machines. The front end does cutting and ring assembly. The back end, which can be several hundred feet long, is mostly material handling. There's usually a two-track narrow gauge railroad behind the TBM, carrying ring segments forward and dirt backwards. It's constantly being extended with new track sections. That's part of the TBM's job.

Here's a good overview of TBMs design, from Machine Design.[2]

[1] [http://www.therobbinscompany.com/wp- content/uploads/2014/08/...](http://www.therobbinscompany.com/wp- content/uploads/2014/08/FastEPBAdvance_NAT2014.pdf) [2] [http://www.machinedesign.com/archive/art-digging- hole](http://www.machinedesign.com/archive/art-digging-hole)

<comment><USER4> Yeah this is all very odd and everyone is lapping it up. He claims to want to reduce tunneling costs by a factor of 10, but starts by quoting a very high benchmark of $1 billion per mile which is quite easy to beat. Then he reduces diameters to something much smaller than all the expensive mega projects, into the range of something where technology is well established and costs are already 1/10th of his quoted $1 billion per mile. But then for some reason the solution has to involve putting cars into these tunnels. If what he thinks he is on to is viable with cars in those tunnels, it's even more viable with trains carrying 1,000 passengers each coming every 3 minutes. So why aren't we building these subways with trains?

The largest part of the problem to solve here for the US is not the technology of tunneling. It's the process of engineering and building infrastructure like this that seems to become way more expensive in the US compared to places like Spain. I do believe he could reduce costs by vertically integrating the whole thing. But then we should ask why don't we do that anyway?

<comment><USER5> > But then we should ask why don't we do that anyway?

Sure. Why didn't we have electric cars before tesla? Why didn't Boeing or Lockheed Martin make reusable rockets?

Alan Kay said something[1] recently that has been bouncing around my head for the past few days. He said that many people think darwinian processes (like the economy) optimize. "One my degrees is in molecular biology, and I can tell you, any biologist would say they're absolutely not optimized. The whole point is to fit into some niche in an environment. And if the environment isn't the _right kind of environment_ evolution isn't going to give you something interesting".

In the context of the economy, if there's no innovation, and not enough competition, and no new players entering a market, I don't think its all that surprising that the existing companies might stop reaching to be more efficient.

It seems strange to think that companies would leave money on the table, but in older industries I think this is exactly what happens. The money just requires too much organizational churn for their corporate appetite.

[1] [https://youtu.be/DIR6Rmhm3To?t=54m17s](https://youtu.be/DIR6Rmhm3To?t=54m17s)

<comment><USER6> Off topic:

The more I think about organizations the more I they seem to be the key players preventing change to me. (Which is not necessarily a bad thing)

Business says: We had this great idea, now let's freeze everything in time and let's make money of this snapshot forever, because who knows when we'll find gold again.

Entertainment industry likes to do that especially.

<comment><USER7> That's not businesses - that's humans. Or do you apply for a new job every two weeks whenever you see a higher salary advertised?

<comment><USER6> More precisely it's humans when they form a bunch / organization ;).

<comment><USER7> NO, I'm saying that even individuals are conservative in that they will tend to stay with an existing job, locale or speciality even when an alternative could potentially offer better returns. I don't check the job listings every day.

<comment><USER8> Risk vs reward. Often the risk is too great, especially for a company that is making a lot of money. Why risk R&D when there's no competitor. Companies are optimised to make money, not progress.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The old strategy of hiding your outlandish claim in an assertion in the first sentence!

"To solve the problem of soul-destroying traffic, roads must go 3D"

The word "must" is a very strong one here, there are other options:

* Reduce the amount of travel that people need to do (remote work, online shopping).

* Reduce the density of cities (enabled by remote work or longer commutes with better internet access).

* Increase public transport options (higher passenger density).

* Encourage cycling.

I feel like only somebody who lives in LA would make the "must" assertion and not think about all the other options... oh wait:

[https://www.bloomberg.com/news/videos/b/6e27fcba-309d-494e-b...](https://www.bloomberg.com/news/videos/b/6e27fcba-309d-494e-b87d-c73fb8bb1750)

<comment><USER10> Cities like LA will become denser over time. It might seem counterintuitive but increasing density alleviate traffic (people walk).

You can't clean a hotel or flip a burger remote.

Public transit has failed to solve the problem despite a 100-year head start.

Cycling... in LA...

I don't think the Boring Company is trying to solve the gridlock. They will, however, provide an option for those who can afford to pop down into a Teslalane [sic] for a trip to the airport. And that's fine. It's [Teslalanes] infrastructure that ultimately helps the city thrive until the time that the land use patterns rebalance. There will always be traffic - but it won't always have the same overall impact.

<comment><USER11> > Public transit has failed to solve the problem despite a 100-year head > start.

Public transit _SOLVED_ the problem 100 years ago in the US. And then it was sabotaged by the big automakers.

<comment><USER12> >Public transit SOLVED the problem 100 years ago in the US. And then it was sabotaged by the big automakers.

I think American Individualism sabotaged Public Transit when it realized it could avoid the public by using automobiles.

</comment></comment></comment></comment><comment><USER13> I'm more interested in the nuances of tunneling, like how they'll handle water seepage and flooding. Flooding is actually a huge problem with climate change causing larger and more frequent major weather events.

After Hurricane Sandy, it took almost a week to reopen the subway tunnels.

I can just imagine the kind of kinetic force that'll occur if a sled carrying a car slams into a section that has a few feet of water.

Airflow and humidity are other concerns. Airflow is necessary to keep passengers safe. Controlling humidity is important for keeping the infrastructure from degrading more quickly.

Any good paints or fabrics or metamaterials that could be used as a tunnel liner that only allow water to wick in one direction (from tunnel internals to surrounding soil)?

<comment><USER14> >Any good paints or fabrics or metamaterials that could be used as a tunnel liner that only allow water to wick in one direction (from tunnel internals to surrounding soil)?

Thermodynamically impossible without an input of energy. FWIW.

<comment><USER15> It turns out that most transportation tunnels do in fact have a significant input of energy.

Ventillation _to exhaust waste heat_ is a major concern.

From discussions of net-zero housing in Alaska (Thorstein Chlupp), my understanding is that water tends to flow from hot to cold -- it will condense along a cold surface. A condenser + sump system where some engineering mechanism keeps the inner tunnel wall from remaining at equilibrium temperature with the interior, might work, though how cold that would need to be to keep humidity manageable would be a question. Routing the cold-side air ducts such that they waste heat to the subsurface and draw heat from the tunnel wall might be one approach. Further cooling through water (fresh, sea) is another possibility, though both present significant issues, scarcity of fresh in Los Angeles, and general nastiness of sea,

<comment><USER14> While you're right, in that heat is an issue in tunnels, harvesting low- temperature-delta energy is incredibly inefficient. It is always better to source the needed electricity from a generator that is specifically designed for such.

(The only time this may be untrue is when dealing with very small things like remote sensors, where running a wire might actually be more expensive than harvesting the microwatts needed locally. But this is a fraction of a fraction of a percent of total system needs.)

<comment><USER15> What I'm saying is that for the purposes of removing moisture, the temperature gradient itself is an energy flux which might be utilised.

In some ways, this is the inverse of an evaporative cooler, where the incoming air is saturated with moisture to lower its temperature before being vented to a warm space to be cooled ("swamp coolers" are best suited to dry climates, and have humidity issues). Here, instead, cool (possibly chilled) air could be ducted through the warm space, with the intent of condensing moisture onto the ductwork (for drainage by other means) prior to being vented into the space.

You're trading cooling capacity (condensing water warms the cold air supply) for humidity control.

I'm _not_ trying to imply that this is _practical_ , only that a latent energy flux might exist.

</comment></comment></comment></comment></comment><comment><AUTHOR> > _What do you do with all that dirt?_

>... The Boring Company is investigating technologies that will recycle the earth into useful bricks to be used to build structures... These bricks can potentially be used as a portion of the tunnel lining itself, which is typically built from concrete. Since concrete production accounts for 4.5% of the world's greenhouse gas emissions, earth bricks would reduce both environmental impact and tunneling costs.

I called it. :) [https://news.ycombinator.com/item?id=14224261](https://news.ycombinator.com/item?id=14224261)

<comment><USER16> I have seen ~3 decades old earth bricks (granted, uncompressed) and it's not pretty. Maybe compression and hydro-isolation does wonders.

<comment><USER17> Mix in some resin?

<comment><USER18> The traditional way is to use straw.

</comment></comment></comment></comment><comment><USER19> I'd like to see more details about edge case scenarios.

What happens if a sled gets stuck? What would be the procedure and response time for getting the right personnel down there?

What failsafes are in place for disasters? What if the power grid went offline or there was a flood?

How do you prevent human error? What if people left their gas vehicles on and there was a toxic level of carbon monoxide in the tunnels? What if people jumped or accidentally fell onto a sled while it was descending?

<comment><USER20> > I'd like to see more details about edge case scenarios.

The thing is, we're all MUCH more comfortable with the danger we're familiar with, than the danger we're unfamiliar with. Imagine if planes were just being introduced today - what are the edge case scenarios? What happens if there's mechanical failure at 30,000 feet? What happens if there's turbulence, lightning, birds, volcanic ash? What happens if the pilot is suicidal? What happens if... But we really don't care, do we? Air transport is familiar.

I'm not saying the dangers of new tech aren't important - they're very important; but keep in mind that while the idea of suffocating after a crash or malfunction in a hyperloop tube/tunnel will feel significantly more perilous than any misfortune that may befall you on a plane _simply because a plane 's risks are now familiar._

When we look back at how planes came of age, it seems like people were idiots to get on them (I recently read about the de Havilland Comet... it disintegrated in mid-air like 3 times in a year - don't quote me on that, but it was bad). Did it have to be so bad? No; of course some disasters could have been avoided with better oversight and accountability, but nonetheless, in the face of risk, the new tech provided such great advantages that its risks were accepted. It's fair to be aware of the way new tech can fail, but we shouldn't dismiss a tech simply because it can't "prevent human error" 100% of the time, or be perfectly immune to failure of any sort.

If we can introduce a new tech that has failure properties similar or better to current tech, but that adds significant value to everyday life, we're netting a very positive gain. We shouldn't let fear _any_ failure prevent us from pursuing new tech, just like we shouldn't let fear of stubbing our toes prevent us from walking.

<comment><USER21> >I'm not saying the dangers of new tech aren't important - they're very important; but keep in mind that while the idea of suffocating after a crash or malfunction in a hyperloop tube/tunnel will feel significantly more perilous than any misfortune that may befall you on a plane _simply because a plane 's risks are now familiar_.

Without understanding edge case scenarios, we cannot make claims like these. Maybe these tunnels really will be more perilous than planes. Or maybe not. The whole point of asking the 'what if' questions is to clarify these issues.

Airplanes have been studied intensely enough that we know the rates and modes of failure. It's worth pondering the same for new technologies as well.

<comment><USER22> People have been building tunnels for a lot longer than they've been building planes. They are extremely well-understood.

The innovation here is in digging the tunnels, not their operation.

<comment><USER21> Then by all means, go ahead and answer @atarian, not me. His or her questions didn't seem straightforward to me, but perhaps you or someone else knows better.

<comment><USER22> You are the one who is suggesting that there are vague, ill-defined risks involved in this "new" technology.

</comment></comment></comment></comment></comment></comment><comment><USER23> This is FANTASTIC! It's important to understand how massive the Earth is (even though it's a pinprick when compared to the sun). You can EASILY go 3-D or deep.

The deepest mines in the world are around 12,000 feet deep. This is about 6x the height of the tallest building in the world (2000 feet tall).

Imagine, thus, putting in a tunnel at what would be every 5th floor of a skyscraper and that you could fit 6 skyscrapers underground...that allows for approximately 150 stacked tunnels! Excessive of course but possible!

<comment><USER24> I'm just imaging a 150 way 3-d lane merge at the other end :O

<comment><USER25> When imagining a 150 way merge I can't help but feel like it'll pollute enough to make nearby trees crumble in a matter of days. 150 ways at approximately 1 car per second (a very full highway) and 1.1 people per car (I hardly know anyone who carpools), there's 150 _1.1_ 120 = ~20 000 people every two minutes. Trains can operate at the same frequency, carry a few thousand each and pollute a lot less -- heck, electric ones can draw from solar panels, reducing pollution to near zero. Give it ten tracks and you have equivalent capacity to 150 stinky lanes.

<comment><USER26> Musk's idea was that gas-powered cars would _not_ be driving through tunnels themselves, but on electric sleds, which makes the tunnels as non-stinky as with electric trains.

</comment></comment></comment></comment><comment><USER27> This does not answer the most obvious and important question: why not invest in public transport? It's boring but it will work.

<comment><USER28> This IS public transit. Public transit without the last mile (or in LA, the last 5 miles) problem. This freedom-supporting tech also thwarts the tyranny inherent in public transit (schedules, robbing your life with all the waiting, limited load carrying capacity, forced interactions with antisocial individuals, etc.)

<comment><USER29> But there is still a last mile problem, you have to enter and exit out of the tunnels. That's the last mile. Or do you suggest that tunnel building will become so viable from an economic and engineering standpoint that everyone will have an entry point in their garage?

> This freedom-supporting tech also thwarts the tyranny inherent in public > transit (schedules, robbing your life with all the waiting, limited load > carrying capacity, forced interactions with antisocial individuals, etc.)

Funny you don't mention the tyranny inherent in single-occupancy vehicles: Robbing your life having to find parking. Paying to park your car (if you live or work downtown). The antisocialness of sitting in your car for 1-2 hours a day with just NPR as your only friend. The inherent inflexibility of SOV travel, where your car carries just 20% of the designed capacity most of the time. And finally, the infrastructure that has to be built to support cars, driverless or not, zipping around everywhere, making it harder to walk or bike to where you want to go.

<comment><USER28> I guess you missed the 125mph speed in the tunnel, thus decreasing that 1-2 hour commute to about 9 minutes or less. Or, 20 times faster than even the best crammed in a sardine can public transit.

The idea of public transit being redefined as 6-8 passenger vehicles you get paired with at the bus stop that then use the tunnel network to decrease transit time for those who need to use public transit is also absent from your retort. As is the honesty about the typical case for public transit, non-peak. This case in the tunnel system suddenly realized for a fraction of the cost because vehicles are on-demand instead of driving a mostly empty big ass bus (or light rail car) on a route according to a schedule. It's basically for public transit what streaming is for TV.

Also, all of the things you describe as "tyranny" are actually choices, making them "freedom", the opposite of "tyranny". I've lived in Los Angeles for almost 35 years and I've never chosen a 1+ hour commute, though you are free to if you choose. I also don't choose to go to the parking insane areas. Again, your choice. But there is little choice with current public transit solutions. You go where they tell you when they tell you and that's that. And don't forget your mandatory sampling of the, I'll put it nicely, culture du jour.

<comment><USER30> I recommend you first try mass transit in Berlim, Tokyo, Singapore,etc before discussing this.

Your impression of mass transit seems to be very biased due to the american fuckups with them.

</comment></comment></comment></comment></comment><comment><USER31> "To solve the problem of soul-destroying traffic, roads must go 3D"

This is not very convincing. Solving congestion by building more roads isn't exactly a new idea. Its track record isn't that glorious either: [https://en.wikipedia.org/wiki/Induced_demand](https://en.wikipedia.org/wiki/Induced_demand)

Not to sound too negative but how about some evidence on why it will work this time?

<comment><USER32> The induced demand argument applies to _marginal_ increases in capacity on already-congested roads. If you make enough extra capacity, eventually you run into limits in how much demand can be created. For example, if you check out the city streets at 3 AM, you'll typically find that there's a lot more capacity than people are using.

These guys are quite ambitious in the scale of the tunneling they want to do.

</comment></comment><comment><USER33> So in the concept video it shows passengers loading on to a sled at surface level that can hold maybe a dozen people, and then it descends on an elevator 50 metres to the tube and goes down the line. This sounds cost effective compared to a full on underground subway station, which really aren't cheap to build even if you 10x the cost of tunneling, but it isn't good for much unless all those passengers intend to also get off at the same stop, which isn't really something that happens. So if one of those dozen passengers wants to get off, then all 12 will have to go all the way back up to the surface and back down again, which could end up being cripplingly slow.

<comment><USER34> > _that can hold maybe a dozen passengers_

there's no reason this system couldn't carry a bus.

musk markets to the elites first, then uses that to subsidize the mass market solutions.

<comment><USER35> Or how about trains underground...

<comment><USER34> yes, imagine that, subterranean.. rail.. ways.... a type of 'sub-way'. possibly even a private one.

</comment></comment></comment></comment><comment><USER36> I'm no starry-eyed admirer of The Boring Company, but it's funny how many peoples' argument here seem to be: "The Boring Company's plan to alleviate traffic congestion is flawed and non-optimal. It would make more sense to replace American cities with high-density ones and build mass transit instead".

<comment><USER37> Why is that funny? I see a proposal that requires cars as something that at best maintains status quo. A walkable/bikeable city seems far better to me than one that is made for cars. Roads are for cars instead of people. All that parking is for cars.

<comment> crush-n-spread Yeah but people don't _want_ that! No one is going to invest in getting rid of roads or giving away bicycles. That serves no one but the poor. People _will_ invest in an underground transport network that solidifies Tesla's advantage.

Think about what will actually work, what is actionable. Getting rid of cars is completely unactionable. Tunnels are. So Elon does tunnels.

</comment></comment></comment><comment><USER38> An automated electric tunneling system that can recycle material into building components sounds incredibly useful to prep mars for colonies.

<comment><USER39> Have you ever read up on Mars lava tubes? The idea of using them to start colonies makes a lot of sense to me.

<comment><USER38> I have! These would be good for expanding existing cave systems as well as building planned structures where lava tubes aren't naturally occurring or are exposed to the atmosphere

</comment></comment></comment><comment><USER40> Uhh, this isn't going to be the panacea many are making it out to be here. This will not come close to accommodating the current capacity of freeways.

The tunnel is being planned to be 14 feet wide, which is how it suddenly becomes viable. That's around two 'stabilized electric sleds' in one tunnel.

Current freeways are 8+ lanes and you'll have to consider how the specifics of group travel are going to be worked out.

Can anyone who've done their own research comment on the throughput once there are interconnected tunnels?

<comment><USER41> Well hang on. Do we understand the impact of, for example, just a single lane, one-direction tunnel with respect to rush hour traffic in LA? It's like a shunt. Sure, more is better, but we're not talking about replacing freeways. We're looking at a way to improve traffic.

<comment><USER40> (If you're taking about inter-city travel)

I really doubt one person on a lane can be faster than a freeway with 4+ lanes (in one direction) no matter how fast it is going.

Another thing you'll have to consider is that there will be a logistical problem at the exit stops if you want to take advantage of all the high speeds being talking about. I'm talking about passengers getting stopped off there.

There have to be atleast X/2 get-in/get-out stops for people to climb into the sleds or there will be a bottleneck. (Considering X is the throughput for the amount of time it take a passenger to embark/disembark)

(If you're taking about intra-city travel)

Building these tunnels would be very, very inefficient compared to say building _another_ road over the current roads.

I'm not from LA but I believe the major traffic occurs at rush hour, and short stretches of roads are really the problem. So finding out the hotspots and mending them would do much better than digging out lots of tunnels under heavily populated areas.

Another point is that in intra-city travel, high speeds cannot really be taken advantage of, so they'll basically travel at subway speeds. Now, subways as you see are already filled up if you take a look at New York. How do you think a one man car would fare compared to that?

(off topic) Again, I'm a fan of musk, but to me, this seems similar to the 'Put man on Mars' argument because that's where we have to be in a couple centuries. Rather than that, putting money towards colonizing harsher places on earth like deserts or Antarctica would be money much better spend IMO.

<comment><USER42> Presumably we would get better at building more tunnels after the first one, and presumably once an existence proof is in place the economics will justify accelerated R&D, resulting in a technological feedback loop.

You can only layer so many roads above ground. But as said in the post, tunnels have no such limit. 100 years from now one could imagine a very thick subterranean transportation network. The interchange and routing problems I'd guess are solvable iteratively over the course of decades, since you have a lot of free space to work in with minimal constraints once you are deep enough to allow "forking" the network as you build more advanced technology.

Slapping two freeways together is not strategy that lands you ultimately in that future, but starting on the problem building cheaper tunnels is.

<comment><USER40> Tunnels might look more futuristic, but I can't imagine a world where building layers of tunnels will be cheaper than larger roads.

We've already put the R&D into roads, and the cars that run on them. Routing problems have also been solved. No matter that feedback loop, it wouldn't get cheaper than laying a road.

It's true that you can build many tunnels, but why? Congestion is really a problem in inner city roads. I rarely hear of any congestion in freeways, and I have to say, expanding to a couple more lanes sounds a lot more viable.

<comment><USER42> The company is based in LA, a city known for its hellscape of congested freeways.

</comment></comment></comment></comment></comment></comment><comment><USER43> >To solve the problem of soul-destroying traffic, roads must go 3D

There are other methods. Public transport on trains of course or more high tech maybe semi self driving cars platooning ( [http://www.tech- faq.com/vehicle-platooning.html](http://www.tech-faq.com/vehicle- platooning.html) ) which could almost be done with present tech.

</comment><comment><USER25> > Secondly, increase the speed of the Tunnel Boring Machine (TBM). TBMs are > super slow. A snail is effectively 14 times faster than a soft-soil TBM. Our > goal is to defeat the snail in a race.

I can imagine them at parties:

"So what do you do for a living?"

"Our company is trying to win a race from a snail."

"Hahah-- wait you're serious? What kinda company is that?"

"The Boring Company."

<comment><USER44> SpaceX actually does the same.

</comment></comment><comment><USER45> Costs can be reduced greatly even without any technological innovation. NYC and LA spend ~10x more per km of subway than what some European cities spend. (E.g. NYC's $2.2B/km vs. Paris's $230M / km. [1]) So try to replicate what foreign cities are doing and you get significant savings.

However since either way digging tunnels will be expensive, it seems inefficient to try to do this for cars. It would be more reasonable to just build a better subway system. Especially if in the future there will be automated fleets of self-driving cars waiting for you at each subway stop...

[1] [https://www.vox.com/policy-and- politics/2017/1/1/14112776/ne...](https://www.vox.com/policy-and- politics/2017/1/1/14112776/new-york-second-avenue-subway-phase-2)

</comment><comment><USER46> "This is not a new concept, as buildings have been constructed from Earth for thousands of years including, according to recent evidence, the Pyramids."

Classic Musk snark. Love it.

</comment><comment><USER47> This is a little crazy. Because of too much surface traffic, let's bore tunnels and develop sleds. The problem is: inefficient use of the existing infrastructure, 1 person per car, and the like. This wii be improved by the sharing of vehicles, and the driving of vehicles in formations by filing flight paths, using driverless technology. Cars are a highly unattractive investment anyway, a $50,000 car sits unused 23 hours a day. I am also skeptical that right of way, permits, and local governments could ever be satisfied by this scheme. And one pleasure of driving is looking out the window. You want to go in tunnels? By yourself? Oh you will work?

Nahh.

<comment><USER48> Agree with the first point - if the final goal is to move people around at low costs in terms of construction/maintenance, land use, and environmental factors, the low ratio of "transported human" vs. "transported metal" makes cars the worst of all choices. This can also only alleviated for so long by making roads more congested in a more efficient way. In the end, roads are still a massive waste.

Some of your other points make too many assumptions of maintaining a status quo. E.g. automated cars will make sharing schemes more feasible. You can either hop on an uber-like car to get home, or lease your car out in the 96% of the time it sits idle.

Unfortunately (depending on the right price) I think this will make car travel more attractive compared to other forms of transport. One can think of a lot of sharing schemes - individual cars, minibuses, or large busses like we have today - with different price points. Overall costs of motorized travel is likely to fall. So I would think that overall we will see that vehicle use will go up (at the expense of walking on foot, for example) and use of parking lots will go down. In fact if traffic wasn't as cyclic as it is one wouldn't need any parking lots at all.

Also, if you can really get to the 130 or so MPH in the tunnel, then travel time will not be such an issue.

The main fallacy of the whole initiative, however, is that it is based on status quo of the structure of cities. Compare the urban sprawl of a post-WW2 US city with those of a medieval town. The main difference was that travel was slower, and faster travel was incredibly expensive (mostly unreachable due to lacking technology). It led to a much more efficient use of resources. If anything we need to redesign our cities based on these old principles in order to reduce overall resource consumption.

</comment></comment><comment><USER49> There's some interesting stuff in here, I'm excited to see what comes of it.

But I'm a bit worried about the thought process in the intro:

> A large network of road tunnels many levels deep would fix congestion in any > city, no matter how large it grew (just keep adding levels)

this is untrue in the general case. Notably, if everyone wants to drive to the city center, then there will be congestion, because at one point you must get to the destination.

It's not just volume, but throughput that causes congestion.

When the traffic flow isn't spread out nicely, your traffic can only go as fast as the weakest link.

You know what has higher throughput than cars? trains

</comment><comment><USER50> Independent of the tunnel, a network of sleds able to move vehicles at one sled per vehicle... is going to be ludicrously expensive and the maintenance costs will be huge. Current roads don't need sleds, sled tracks, elevators, switching and management, safety gear etc, and that's even before we get to the usual tunnel needs of ventilation, pumps, and lighting.

It seems a bit odd to be proposing very high maintenance infrastructure at a time when the US is famously facing a huge problem in not being able to afford maintenance for its existing infrastructure.

</comment><comment><USER51> To solve the problem of soul-destroying traffic takes just a mindshift from corporate decision makers to realize that physical presence of employees are not necessary for success.

</comment><comment><USER52> I think people are missing the strategic importance here. Tesla is going to be in the game of self driving cars. Once self driving cars happens, there is no longer going to be anyone who buys cars, they will simply hail a ride using the self-driving Telsa(Uber, Lift, Google) network. Soul-Crushing-Traffic is going to be optimized heavily, using certain algorithms and the inter connectivity of the cars. However, one HUGE advantage that Tesla cars are going to be able to have are these tunnels. I think this is of huge strategic importance, because they can reduce the cost for transportation across cities, because they don't have to deal with all the traffic. As discussed in plenty of places on hackernews, ride-hailing is going to be a commodity similar to the airline or ocean transport industry. It will be solely based on cost. If Tesla can make the cars at cost, owns the self-driving tech, are all electric with a huge network of free fuel, and have tunnels that allow you to bypass traffic then they will own the future transportation industry, while everyone else tries to catch up.

<comment><USER53> I don't see how the tunnels can be commercially viable just carrying Teslas. That's a tiny fraction of traffic. Apart from anything else I can't see cities granting permits for exclusive tunnel systems like that, which don't benefit the broader public.

<comment><USER52> I think you missed the first point I made. Tesla will be THE biggest ride- sharing service once it gets to scale with self-driving cars. Why would you buy a car in a large city if it'll be 2.50 to get to work in a self driving, all electric car? In California there are toll roads all over the place. How are the tunnels different from a normal toll freeway? Tesla could allow use of the tunnels for a fee. This fee will be the deciding factor between whether I take uber, google, lift or tesla. I am going to take whatever offer is cheaper. I'm suprised there isn't an app out there yet that lets you compare prices for your destination through various ride hailing services, but i'm sure there will be one in the future.

</comment></comment></comment><comment><USER54> Along these lines, there was just an interesting latimes article a couple days ago about a subway tunnel currently being bored in downtown LA which provides some insight into the current process: [http://www.latimes.com/projects/la-me- metro-tunneling/](http://www.latimes.com/projects/la-me-metro-tunneling/)

</comment><comment><USER55> I'm rather surprised that "are you boring yet?" isn't in the FAQ.

</comment><comment><USER56> One question I don't see answered in the FAQ is "Who owns the tunnels?"

Does the Boring Company own them? The municipality? How does one go about getting permission to tunnel below property owned by other entities?

</comment><comment><USER57> >Unlike flying cars, tunnels are weatherproof, out of sight and won't fall on your head.

Anyone from Boston can tell you that's not true. I don't think this sort of hyperbole helps the case for tunneling.

</comment><comment><USER58> The problem with this idea is not with throughput of the tunnels, but with the shafts that lead to the tunnel. Lowering one car to the tunnel will take time, and unless there is some kind of elevator with multiple carts you will only be able to lower one car at a time.

Let's say that the shaft is 20m height and let's allow 2 meters for each car. We could get ~ 10 cars "stored" in the elevator, but if it takes one minute to load and unload the car it will take ~10 minutes for the car to get to the tunnel. One shaft will be able to load only 60 cars/hour. This will not solve any traffic problems and it actually may make the traffic around the shafts worse (depending on how many cars are waiting to go into the tunnel, and how large "the Boring Station" is.

There are two solutions either load/unload cars faster - possible but unlikely, or have more elevators connected to each tunnel. The problem with the second solution is that these cars have to safely join the rest of the cars that are currently in the tunnel.

If you have 10 elevators, each unloading one car a minute, you would need a system that allows one car to join the traffic every 6 seconds. If the cars are traveling at 125mph the sleds would need to have a pretty good acceleration to get to that speed as quickly as possible, or you would need longer adjacent tunnels.

</comment><comment><USER59> This page forced me to find and install autoConvert Chrome plug-in, so that I can read the text without stopping to wonder what 14 feet is.

</comment><comment><USER60> When you make traveling easier for people, more people will do it - <USER2> demand. Why can't anyone grasp this concept? You want to create autonomous cars so that basically 100% of the population can be on the road at any given time and you expect traffic to go away because you built some single lane tubes?

</comment><comment><USER61> > out of sight and won't fall on your head

Tunnels are known for quite the opposite: [http://www.nytimes.com/2006/07/11/us/11cnd- boston.html](http://www.nytimes.com/2006/07/11/us/11cnd-boston.html)

</comment><comment><USER62> I wish them the best of luck but I can't help feel the entire premise of the company is based on a pun.

<comment><USER63> "When dad jokes go too far, Musk edition."

</comment></comment><comment><USER64> > The Boring Company is investigating technologies that will recycle the earth > into useful bricks to be used to build structures. This is not a new > concept, as buildings have been constructed from Earth for thousands of > years including, according to recent evidence, the Pyramids.

Yesssss.

</comment><comment><USER65> >A large network of road tunnels many levels deep would fix congestion in any city, no matter how large it grew (just keep adding levels).

A large network of highways many lanes wide would fix congestion in any city, no matter how large it grew (just keep adding lanes).

<comment><USER52> The difference is that it takes up existing infrastructure to do that. A freeway/Roadway in itself takes up huge amount of spaces from the city. A tunnel under the city would only take space at the "exit" points.

</comment></comment><comment><USER66> > No. Once a TBM is below a certain depth (approximately two tunnel diameters > – or 28 feet in this case), the tunneling process is almost impossible to > detect, especially in soft soil.

They missed an important FAQ, Will this tech increase bank heists?

</comment><comment><USER67> It troubles me that my mind keeps interpreting "boring" as an adjective and not as a verb every time news about this company pop out...

Leaving that aside, I believe the logistics about getting the cars on and off board of the electric sled will (in most scenarios) defeat the gains on speed once the cars are inside the tunnel.

For public transportation it may be a good idea, IF they are able to deliver all those technological breakthroughs...

Also, is 14 feet small enough for some people to get claustrophobic feelings?

</comment><comment><USER68> Then he will figure out that he can produce electricity with the geothermal vertical tunnels! And will merge the Boring Company with Tesla like he did with Solar City!

<comment><USER69> In the future I assume Tesla, Space X, Boring Co, etc will all become Mars Corp.

He's said again and again his true goal is to colonize Mars and everything until then is to get to that goal.

What happens when he does get there? Can be claim it? Become President? Or an area of it?

<comment><USER70> He will become the Elon of Mars [http://imgur.com/a/yhvDH](http://imgur.com/a/yhvDH).

</comment></comment></comment><comment><USER71> This feels a lot like the Shanghai Maglev [1]. Gets you between the airport and part of downtown for a relatively high fee. Built because they could, and wanted to show off. Not particularly useful, but cool. It'll be interesting to see what this turns into in reality.

[1] [https://en.wikipedia.org/wiki/Shanghai_Maglev_Train](https://en.wikipedia.org/wiki/Shanghai_Maglev_Train)

</comment><comment><USER71> All due respect, I'd rather just bring in the Hong Kong MTR corporation and let them run the entire LA public transit system instead as they do in Stockholm and Melbourne, among others ([https://www.mtr.com.hk/en/corporate/consultancy/railwayopera...](https://www.mtr.com.hk/en/corporate/consultancy/railwayoperation.html)).

</comment><comment><USER72> I believe digging tunnels on earth is Elon's way to practice on earth. The machine will be use to dig tunnel in Mars in the future.

</comment><comment><USER73> >* A large network of road tunnels many levels deep would fix congestion in any city*

heh, sorry Miami, Orlando, Tampa and I'm sure many others.

</comment><comment><USER74> What a great title. Before clicking, I fully expected to see things like "Why should I keep working here?" and "Will anything, ever, happen here?" and other questions about working in a boring, mind numbing job... Real topic is much more important, but still, I think we also need a real "Boring Company" FAQs list.

</comment><comment><USER75> Part of me keeps waiting for someone with the right clout and means to attack the elephant in the room:

Change the rules of the road.

Our roads can move far more cars per unit time than they do now. This is easy to see if you drive around Los Angeles for a fair amount of time. I drive the 405 corridor with some frequency and I can say it has gotten worst over the last few years.

Yet, the one common theme you see every day consists of these characteristics:

      - Cars driving everywhere at whatever speed they want
      - Cars driving slowly on the left
      - "Synchronized" driving, where two cars drive equally slow side-by-side
      - People who can and want to drive faster have to zig-zag through traffic
      - The carpool lane is inhabited by people who do nor carpool
        Just because a car has more than one person it doesn't mean they are
        carpooling.
      - The carpool lane has buses going slow and sometimes (often) empty
      - No penalty for slowing down when going uphill and causing backup

It's insane, there are no penalties for going slow and causing backups that trigger massive oscillations that lead to the entire freeway going through these nodes where speed grinds down to zero. This wave travels backwards and it can be triggered by slow or insecure drivers. I've seen in time and time again.

If I were to generalize, the rules of the road are not designed or evolved to optimize flow. You can't even say they are optimized for safety because there is nothing safe about a moron going 55 on the fast lane while people are swerving all over the place to get around him.

What we need is a new mentality: Caltrans and CHP need to work together to optimize flow, not get in the way of it. The carpool lane is a disgrace. It takes-up 20 to 25 percent of the road's capacity for no gains whatsoever. We need a layered system where slow drivers get out of the way and don't impede others. I am not saying go full autobahn but there's merit to the idea that slow drivers should not be allowed to impede others. I've watched the 405 grind to a halt because of a few (two or three) drivers who manage to lock-up an area. It always gets worst before it gets better.

Tunnels? Sure. But first fix the real problem.

This is where self driving cars might do an amazing job. We will be able to extract far more capacity out of the existing infrastructure by increasing speeds and layering them from right to left.

</comment><comment><USER76> I love the punchy writing style of the FAQ - so full of Elon's spirit and go- getter attitude!

I hope these guys do a great job!

</comment><comment><USER77> All of Elon's ideas and actions: tunnels, hyperloop, solar, AI, electric cars, space launches and travel - are useful for getting to other planets and settling there. The investigation and ideas can be proved out in parallel here on Earth, and then applied in other planets.

</comment><comment><USER78> Given the name of the company and how that FAQ reads, I feel there's a good chance it's satire.

</comment><comment><USER79> Whoever wrote this, I'd like them to evaluate my life and write me a mission statement as well.

</comment><comment><USER80> Doesn't a tunnel under a building significantly increase the chances of the building falling down?

What about flooding?

<comment><USER81> No clue why this is downvoted, these are valid concerns.

Measuring and avoiding ground settlement consumes an enormous amount of engineering and contracting resources in every urban tunneling job.

Flooding too can lead to work stoppages or long delays. You should have seen the Queens Bored Tunnels and Structures Project after Hurricane Sandy. It was pretty soupy.

Source: Was a tunnel boring engineer in NYC, where we had an abundant supply of both buildings and groundwater.

<comment><USER82> Any large project is likely to have difficulties of some sort that need to be taken into account to overcome: it's the nature of the beast. You're right, these are valid concerns. Asking the questions as your parent does implies that those at the Boring Company—while they may have not solved them in all cases—are not aware of them, especially as these aren't new problems. I speculate that the downvotes are a reflection that your parent isn't granting them this benefit of the doubt. One can infer from the FAQ that they _are_ thinking of this in part from the R&D bullet point:

> _Tunneling R &D. In the United States, there is virtually no investment in > tunneling Research and Development (and in many other forms of > construction). Thus, the construction industry is one of the only sectors in > our economy that has not improved its productivity in the last 50 years._

</comment></comment></comment><comment><USER83> Unfortunately this is never going to work in Rome, where there's a whole underground city already

</comment><comment><USER84> How can a company produce something coherent like this?

Usually it's really hard to understand what a company is doing from their web page because it's hidden behind so much meaningless marketing speak "We help you solve problems and be awesome!".

</comment><comment><USER85> But what to do with all the dirt?

<comment><USER63> I laughed at "disposal".

Perhaps they aren't fully aware of the volume disturbed soil takes up. Logistics of moving it could be a cost not necessarily considered.

</comment></comment><comment><USER86> Couldn't we have a problem with tunnels that cross a tectonic plate? During an earthquake, if one plate moves up or down and the adjoining doesn't move, wouldn't that sheer the tunnel closed?

</comment><comment><USER87> My theory is that these tunnels are truly being built to support the Hyper Loop. It's only a matter of time before they acquire one of the companies that did all of the R&D work.

</comment><comment><USER88> Make these tunnels cycling only, and sell electric bikes specially designed for such tunnels, and provide resting/charging stations in the tunnel. Higher throughput, even smaller tunnels.

</comment><comment><USER89> If he reduced the tunnels even more by a factor or 20 instead he could put schweebs in the tunnels.

[http://shweeb.com/](http://shweeb.com/)

</comment><comment><USER90> How are vehicles secured to the "electric sleds"? Seems like any obvious method would be super-unsafe and/or time-consuming and/or likely to scratch the paint.

<comment><USER18> Have you ever seen a car on a flatbed tow truck?

<comment><USER90> That's far from an instantaneous process. Would hold up traffic quite a while. And there are no people riding inside, and the speeds are far less than 125+ mph, so mishaps aren't nearly as risky.

</comment></comment></comment><comment><USER91> I love how Elon is just fucking going for it. No time to waste.

<comment><USER92> I've been a little skeptical of Tesla lately but I love how quickly The Boring Company has gone from a tweet that seemed more like a joke than a real plan, to a hole in the company parking lot, to now actually working on prototypes and real plans.

Also SpaceX is killing it. I'm not a Musk fanboy but IMO he's 2/3 right now in the companies he's working on and Tesla still has a decent shot of bringing that back to 3/3

</comment></comment><comment><USER93> _Tunnel construction /operation is silent to anyone on the surface._

I am pretty sure the neighbours of the Copenhagen metro construction sites would wholeheartedly disagree.

</comment><comment><USER94> >By placing vehicles on a stabilized electric sled, the diameter can be reduced to less than 14 feet.

Interesting. No chance of large commerical vehicles in tunnels at that size.

<comment><USER22> Nothing carrying objects more than 14 feet in their shortest dimension (minus whatever the sled wheels take up), but that is only a very small portion of commercial traffic.

</comment></comment><comment><USER95> "To solve the problem of soul-destroying traffic, roads must go 3D"

I question this. Does anyone know why/how The Boring Company came to this conclusion?

</comment><comment><USER96> When everyone thinks about flying cars, this is a good thought. At least things won't fall in my head when I go out for a burrito.

<comment><USER97> That's like comparing oranges to apples. And planes, indeed fly over your head all the time; there is probably hundred of thousands of them in the air as we speak - how many of them are falling on your head?

If I have a choice of an autonomous emergency parachutte -deployed landing done by my mid-air broken aircar, and being stuck in the heart of Earth with no air and very high temperature literally feeling like a needle in someone's body, I chose the falling cars.

</comment></comment><comment><USER98> Isn't this basically the same design as the Circuits of Time from Bill and Ted's Excellent Adventure?

</comment><comment><USER99> "Tunnel construction/operation is silent to anyone on the surface."

so... nothing like the tube then? :P

</comment><comment><USER100> Doesn't the $1B/mile include station costs? That's the real killer for subways.

</comment><comment> steve-benjamins As an aside, I love that The Boring Company is a Squarespace website :D

</comment><comment><USER101> Building tunnels in California and LA is great and all. But I'd like to see him do it in Houston, honestly, where common knowledge ( _cough_ ) says that you can't dig deep in Houston because it's a swamp.

Houston has, arguably, worse traffic than LA

<comment><USER102> > you can't dig deep in Houston because it's a swamp.

That just means you need to dig deeper!

<comment><USER103> No, the ground water level is ~2m. This is a swamp, tunnels would be too expensive. And Houston is too big.

Houston had a working public mass transport system, but big automotive pressure/corruption destroyed it. That's why Houston is unique. The mayor is elected every two years, because corruption is so rampant.

The now widest highway worldwide, the I10 to Katy once had a railroad track in the middle. They even had a star system and park & ride before WW2.

<comment><USER101> > Tunnels would be too expensive

> Houston is too big

Sounds like a job for Musk, to be quite honest. He's pretty good at driving down costs.

> corruption

Now there's a statement I can, sadly, agree with. :(

</comment></comment></comment></comment><comment><USER104> Does Elon wake up in the morning and say to himself "what kind of company should I make today that is both marketable and is achevable to increase my brand?". It seems like he is spreading himself too thin . Why not focus on Tesla QA or improving working conditions at his other engineering projects ?

<comment><USER105> >Why not focus on Tesla QA or improving working conditions at his other engineering projects ?

Bluntly, because I would imagine because he realizes that he is going to die eventually, and has a limited amount of time to do the things he wants to do.

</comment></comment><comment><USER106> If speed is key, what about developing nuclear-powered TBMs?

<comment><USER81> Many TBM's are already nuclear powered, in that the grid power they consume was generated in a reactor somewhere. There is no reason to bring the reactor closer to the dig site.

Also, see e.g. [https://en.wikipedia.org/wiki/The_Core](https://en.wikipedia.org/wiki/The_Core) for prior art /s

<comment><USER106> Using the grid there must be a lot of transformers and cabling involved. Plus with massive amounts of power _in situ_ one might be able to process the waste rock differently (e.g. if it's looser material with fissures, compress it against the sides of the tunnel or perhaps even melt it rather than removing it. Admittedly I'm rather ignorant of soil and rock physics.)

<comment><USER107> Nuclear reactors require a heatsink, usually a large amount of water.

If you put a nuclear reactor underground, you have to pump water back up. This takes a lot of energy. Whereas, electrical energy travelling through cables is not affected by gravity.

<comment><USER106> What if you used the heat to melt rock?

</comment></comment></comment></comment></comment><comment><USER108> Wall bricks from earth from the dig? I still think they should buy from [https://www.theoceancleanup.com/](https://www.theoceancleanup.com/) and press them from molten reclaimed plastic.

</comment><comment><USER109> > Since concrete production accounts for 4.5% of the world's greenhouse gas > emissions,

there is no way this is even close to being correct. For a point of comparison, "Airlines account for about 2 percent of global emissions".

just how much concrete does this guy think is being produced. come on. He probably misreported a figure that said concrete production accounts for 4.5% of all _construction-related_ greenhouse gas emissions.

<comment><USER110> Concrete production actually does have crazy CO2 emissions. Wikipedia says it's up to 5% globally:

[https://en.wikipedia.org/wiki/Environmental_impact_of_concre...](https://en.wikipedia.org/wiki/Environmental_impact_of_concrete)

<comment><USER109> That's shocking. The Wikipedia page gives a 2002 reference (for the sentence you cite), so I guess in order of magnitude it must be correct.

It seems to say that the reason for this is that it must be heated to absolutely insane temperatures, which is, obviously, energy-intensive.

5% is huge though. I still have trouble believing it. I wish I could see a pie chart with the major sources of CO2 emissions. After things like cars, planes, factories, POWER GENERATION, etc, I would have thought those were the major ones.

if you Google "pie chart of co2 emissions" it's hard to see where just concrete fits in. Oh well.</comment></comment></comment>


Thoughts on "Silent" Browser Upgrades - <AUTHOR> http://davidwalsh.name/silent-browser-upgrades

<comment><USER2> _> The Internet Explorer Example_

This is simply wrong. It wasn't people at home not upgrading that is the main problem. It _is_ a problem, but the biggest factor especially this far in is corporates who won't change no matter what. Some of our clients, large banking organizations, have only just upgraded from IE6 to IE8. And one of them "plans to this year". Silent updates would make no difference here as those environments will be the first to make use of methods to block said updates.

</comment><comment><USER3> I wish browsers updated their code without needing to restart. Ksplice made it work for the Linux kernel. Why can't it work for user-space apps?</comment>


To Post or Not to Post - <AUTHOR> https://dev.to/samborick/to-post-or-not-to-post-19m5 <comment><USER2> I "solve" that by preferring to post without connecting the posts to my identity. I noticed that this has allowed me to still get my voice heard, without tying my ego to it or risk problems or degradation of my pulblic personae.

Be it pure cowardice or something else even when I was much younger I understood that having something published under my name can bring me harm. In today's climate this is even more so even though my thoughts are far from the current topics.

As mentioned above it also helps to divorce it from your ego as much as it can be done, since as all the blame goes so does all the praise, and it allows you to both satisfy your need to vocalize your thoughts or ideas but also to see it just as one dimension of yourself that many readers ( including myself) fail go do when they generate opinion about the totality just by the excerpt or your thought in that time.

Also letting something sit for a while will help you immensely in seeing if this writing represents the you in the spur of the moment or is it something of more importance, maybe even bigger than you.

At the end of the day from me is more important that an idea or thought is made manifest than that there was a specific person that created that thought. Once "on the paper" for me the ownership of that is no longer mine its its own, as much as that can make sense.

<comment><USER3> How do you do that? i'd like to try, but don't feel i can be truly anonymous.

<comment><USER2> Well it depends on the media but let's say it is a blog. First just write about something, anything that catches your fancy. Leave it for a day or two at least then reread it and if you seem that it is something you wish to publish pick a random blog site or medium and create a username not attached to you and just post it there, and if the several blog posts after that seem to be under the similar subject or idea your blog has got an overarching topic or theme.

Then just continue to post there when you want to say something and over time you will get wuote a collection and probably a few readers as well.

Now this is how it is done from a standpoint of a person that just wants to write and doesn't want to profit in any way from it rather than to have a place where they can manifest their thoughts, so if you are in it for something more I don't have any useful advice.

One of my first post, in retrospect, where so shallow and badly written but I am fond of them because it I'd because of that person that I am able to now much better express my thoughts, so don't fall in the trap of perfection, it is that imperfection that makes it unique. All perfection is the same, as such it has no room to grow, and that kinda misses the point for me.

Good luck, be honest yo yourself about your creation but dont be judgmental, see it as a learning process that will just happen to last your whole life :)

</comment></comment></comment><comment><USER4> Long time lurker. Making my first HN post because of this article. Thank you.

<comment><USER5> Hey, welcome!

</comment></comment><comment><USER6> Original source: [https://borick.net/articles/post/](https://borick.net/articles/post/)

<comment><USER7> Not sure why this is downvoted. I used this to subscribe to the author's RSS feed.

<comment><USER6> > _" Not sure why this is downvoted."_

The guidelines ask us to not comment on downvoting. In the future, if you find a comment that you think is undeservedly downvoted, you can give a compensatory upvote if you feel so moved.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment><comment><USER8> I'm not sure which ones they are, but I'm sure some of the most impactful things ever published had this moment of hesitation involved.

</comment><comment><USER9> > I have to publish the stuff that I think no one will care about because I'm > probably wrong. There's a whole lot of people out there, someone is going to > get some value out of what I have to say.

Folks, can we please not flag new people as they open up under this post? This article encourages lurkers to post and partake in online conversations. It's ironic that there's a dead comment at the bottom by a confessed lurker who tried to say hello.</comment>


Vivaldi launches its first beta - <AUTHOR> https://vivaldi.net/en-US/teamblog/66-the-first-vivaldi-beta <comment><USER2> Wow, nice news! But this browser worked good even in apha stage!</comment>


In Y Combinator, everybody knows you're a dog. - <AUTHOR>

<comment><AUTHOR> One of my favorite quotes about startups, which I original attributed to PG (due to [1]) but really belongs to Peter Steiner [2] is "On the internet, nobody knows you're a dog."

The big idea is that so long as you're hiding behind the magic of servers and networking, your business even as a young, fresh-out-of-college startupper looks just as legit as any other business on the web. Maybe even more legit, if you put in the work to look super stodgy.

The odd thing is everybody knows all of the YC companies are run by "dogs," and that's where the fun is. In fact, I'd say the human interest story of college kids making millions from only $20k of funding is the biggest selling point for a lot of the YCombinator companies. Not to demean their products, but I can't remember the last time my mom got excited about, say, her Oracle online calendar. On the other hand, Kiko's a really interesting story.

All of this leads me to believe that simply being a part of YCombinator alleviates suspicion of all of the bad aspects of being a dog (lack of credibility, obvious inexperience, youthful stupidity) and also exposes all of the good aspects (mostly, the publicity, and perhaps the fact that you're more in touch with what's new and hot).

In the end, I think this is a net win for folks like me. To what I think will be a large extent, companies doing something obviously YCombinator-like will catch all of the YC benefits simply by association. I wonder, though, if companies that are branching out into new areas who can't manage YCombinator- style support will still have to struggle with being taken seriously.

And I still find it ironic that PG's the main reason something he's said previously is being proved irrelevant.

[1] <http://www.paulgraham.com/hiring.html>

[2] <http://www.unc.edu/depts/jomc/academics/dri/idog.html>

</comment><comment><USER2> I think there is something very wrong with the current state of conversation on the web. I don't know if there are a lot of ways to make money off solving the problem, but I also don't always think a for profit solution is the best way.

Here are some of my thoughts on the topic: <http://www.digitalkarate.net/?p=20>

</comment><comment><USER3> Not only that, but everyone knows you're also a Pomeranian or a Chihuahua. A very smart one, but small; the majority are "web 2.0" sites with a 3-month ramp-up.

A few are a bit larger, like Lassie.</comment>