What's all this fuss about Erlang? (2007) - <AUTHOR> https://pragprog.com/articles/erlang/ <comment><USER2> > Your Erlang program should just run N times faster on an N core processor

But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.

If your program has sequential or less parallel phases or needs to communicate then you are subject to Amdahl's law like you always were.

Armstrong has that claim in the Erlang book and I was gobsmacked to see it written down with no caveat or mention of the limits from Amdahl's law whatsoever. I was sure it was a joke and it would be followed by 'ha ha ha of course not - nobody knows how to achieve that despite decades of intensive research', but no it's a serious claim made with a straight face. Erlang's solved it!

Erlang helps you write parallel programs... but only if you program is entirely parallel in the first place.

<comment><USER3> >> Your Erlang program should just run N times faster on an N core processor

> But only if your program is embarrassingly parallel with at least N times > available parallelism in the first place! If you have one of those it's > already trivial to write a version that runs N times faster on N cores in C, > Java, multi-process Python, whatever.

You've made two claims, one irrelevant and one false:

1\. _only if your program is embarrassingly parallel_ is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.

2\. _it 's trivial to write a program that's faster in X language_ I'm not sure how toot define trivial, but I've yet to find a language that can communicate between threads as performant-ly. Even languages like Clojure which use similar thread semantics can't do what Erlang can because the underlying threads aren't as lightweight. Spinning up a million threads in Erlang isn't even unusual, whereas in any of the languages you mention it's either crippling-ly slow (Python or Java) or very difficult to synchronize (C most, but Python and Java aren't easy).

<comment><USER4> >only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.

OK. Not an Erlang user, but I can't let this statement go.

I've studied parallel numerical algorithms. Many/most of them _will_ involve blocking because you're waiting for results from other nodes.

If you're saying Erlang has somehow found a way to do those numerical algorithms without having to wait, then I'd love to see all those textbooks rewritten.

Amdahl's Law reigns supreme.

<comment><USER5> I'm not devishard, but I parsed his statement slightly differently. He's not saying that Erlang makes things parallel magically. Rather, he's saying that Erlang forces tasks that /could/ be parallel to be parallel by default. Thus, Erlang will tend to maximize the sections of your program that are run in parallel compared to other languages.

<comment><USER4> Which would make the original commenter's point valid:

>Your Erlang program should just run N times faster on an N core processor

No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.

<comment><USER6> Not really. Think about every object you'd have in Java that's being passed around your system. Now imagine each of those objects are their own processes and you're passing around references to them.

Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation to spread each part of this workload over not only more cores but more machines across the network.

And then realize that you can deploy updates to this codes individual parts while other parts continue running without taking down the whole system.

Then you get Erlang.

<comment><USER4> None of what you said will prevent the need for waiting for the majority of numerical algorithms.

No one's disputing Erlang's prowess at parallelism. What the critic in this thread was saying was that you can only get Nx speedup on an N core processor for a limited set of algorithms. Most parallel algorithms will not fall in this category. Amdahl's law is a general truth - it doesn't matter what your architecture/language is. There is nothing special about Erlang that will make any parallel algorithm scale linearly with nodes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I posted this in another thread on what I like about Erlang (I'll shamelessly copy and paste it here):

* A better concurrency model. Lightweight processes vs callbacks and futures. Or even channels. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process.

* Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning.

* Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years.

* Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge case.

Some people might prefer Elixir and that's fine, they are great friends. I personally like Erlang, I think it is simpler. Someone new coming from Python or Ruby might like it better and also it has very beginner friendly community. Jose Valim and and other authors really put user-friendliness and approach- ability at the forefront. I really like that, mad props to them.

</comment><comment><USER8> Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1]

[1] [https://startlearningelixir.com/elixir-for- rubyists](https://startlearningelixir.com/elixir-for-rubyists)

<comment><USER9> Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that's the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it looks like something which it isn't. It looks like Ruby and gives the programmer the feeling that he's right at home, except it is in fact a very different beast with very different semantics, Erlang semantics, as opposed to Ruby. Therefore, if you want to program on the BEAM (the Erlang virtual machine) you better make sure you actually understand the system, its design, principles and also some of the semantics of Erlang itself, point at which you might as well just learn Erlang. I'm not saying that you cannot learn those things coming from Elixir, I'm just saying that if you want to build systems of reasonable complexity (like the ones that Erlang is known for) on top of the Erlang virtual machine, as opposed to CRUD web applications, then you must understand a lot more than just Elixir or Phoenix.

<comment><USER10> Elixir is prettier than Erlang but it really mess up on certain things.

Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end.

Erlang's:

-module(recursive).

-export([fac/1]).

fac(N) when N == 0 -> 1;

fac(N) when N > 0 -> N * fac(N-1).

You can tell fac(N) both are in a group of pattern matching cause ';' and '.'. The '.' denote the last pattern matching function.

Elixir:

defmodule Factorial do

        def of(0), do: 1

        def of(n), do: n * of(n-1)

end

You can't tell because there is no ';' and '.'. This is a trivial case but when your Elixir's module have a tons of function in it, this issue become relevant.

<comment><USER11> I think you make the Erlang definition look unnecessarily awful.

fac(0) -> 1;

fac(N) -> N * fac(N-1).

Or is there a particular advantage to write it using guards?

<comment><USER12> having a semantically significant distinction between ; and . is unnecessarily awful. That kind of crap is one of the reasons Elixir has so much support.

<comment><USER9> What you said is equivalent to a Python programmer saying that adding semantical value to the "end" keyword in Ruby is unnecessarily awful because you can achieve the same by giving meaning to the indentation level. It's an entirely subjective matter.

I would also like to point out that Erlang has also very good support and has seen adoption in some very critical systems as opposed to CRUD web applications which is the main domain of Elixir. Most of Ericsson's products use Erlang to a certain degree, there are a lot of banking systems and aviation systems which make use of Erlang as well, quite a few Internet companies use it to great success, and many more.

And by the way, the semantic meaning of ";" and "." is an awful lot similar to their use in the English language, you are blowing it out of proportions. This is a trivial thing which you learn after a 10 minutes introduction to Erlang. For me, personally, if one has a problem understanding the meaning of ";" and "." or learning a new syntax for that matter, I can easily conclude that I probably should not give that person any decision power in designing systems.

</comment></comment></comment></comment></comment></comment><comment><USER13> A practical language based on well-researched first principles. Details in the armstrong_thesis_2003.pdf

       * java is unsuitable
       * no pthreads, please (wrong concept)
       * immutable data (no locks - no problem)
       * isolated lightweight processes (share nothing)
       * communication by message-passing (grom Kay's OOP)
       * dynamic typing (good-enough, quick prototyping)
       * pattern matching (on receive)
       * supervision hierarchies (fault tolerance)
       * reusable components for server development

I probably forgot something

<comment><USER14> I've not found immutable data to be the big win people tout it as. In most of what I do acting on _stale_ data is just as bad, which means I wind up needing a lock anyway.

Doing a < b and taking an action based on that result is as harmful with stale data.

<comment><USER15> I'd like to tell you that stale data will always be a thing in any serious application because light only travels so fast. Therefore, you'll need to have sensible logic in the face of stale data either way, so it's not so bad as you think.

...and while that's true, I'd still like to hear the opinion of someone more knowledgeable because it's an issue that's been bugging me too.

</comment></comment></comment><comment><USER16> This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.

<comment><USER17> I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them to vendor it in as you're supposed to.)

Now that I think of it, Canonical's push toward "snaps" (sandboxed and vendored—but not fully containerized—software bundles, as a package format) might bring a flourishing of Erlang-based application software, given that it's much more compatible with Erlang's style of release-management.

<comment><USER18> I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs.

I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim would have served it better — but it's certainly a step in the right direction.

The Erlang toolchain has a ton of ergonomic issues that could have been polished down a long time ago, but haven't been. Erlang simply _feels_ oddly quirky and antiquated for anyone used to modern GNU tools or modern REPLs.

For example: Lack of Readline support (needs rlwrap to be usable, at least on Ubuntu), lack of GNU-style long options, the obnoxious ctrl-C behaviour that doesn't respect Unix conventions and gives you a prompt with confusing options (quick, what's the difference between "abort" and "kill"?) that seem aimed at developers and are completely wrong if you're just a user of an Erlang tool. (Couldn't they have relegated this to USR1 or something instead of INT, like a normal program?) On the server, the epmd process is a thorn in the side of any system administrator. Erlang devs also seem to think that emitting Erlang stack traces is a good replacement for proper English error messages, and if you're not an Erlang dev, you haven't seen stack traces until you've seen the kind of monstrous, obscure, deeply nested contextual dumps that Erlang programs can produce.

And so on. Little things, but important things that can completely kill the joy when you're a potential adopter.

Erlang shouldn't need Elixir to modernize, but there's probably very little incentive within the community to change quirks that they're all used to dealing with by now.

(I encountered similar issues with OCaml, which has many parallels to Erlang: Quirky, odd syntax, antiquated toolchain, etc. Facebook's cleanup effort [1] looks very promising.)

[1] [https://facebook.github.io/reason/](https://facebook.github.io/reason/)

<comment><USER17> Oh, sure, there are plenty of things getting in the way of developers being _excited_ about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang.

But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterprise-y bloatware-apps and business-process servers that make Java's market-share so large.

Because Enterprise software gets designed top-down, how _excited_ developers are to be using the (dictated) language aren't very relevant. How easy the language is to _learn_ is relevant; how many engineers you can either hire or train to code in the language is relevant. But whether they enjoy their day- to-day lives writing in the language isn't, really.

Thus, I think, why things like deployability are more important to Erlang: for the type of software projects Erlang _would_ be good for, considerations like deployability (and maintainability, remote debugging, easy hot-patching, etc.) are what guide language choice. Erlang wins on most of those fronts (as it should: its OTP framework is effectively "30 years of ops best-practices constraining development"), but for various reasons, [non-embedded] deployment has always been a pain-point.

<comment><USER18> But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks.

Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data processing where a lighter language like Ruby will not do well. There's nothing in Erlang that _conceptually_ prevents it from being a general-purpose language; it's just that its ergonomics don't really "scale down" to the stupid, simple stuff.

I remember, years ago, trying to write a basic parallel non-OTP log-processing pipeline for some log files, thinking Erlang would be ideal... and being surprised at the number of roadblocks I had to deal with. Around the same time, Tim Bray went through the same process, but spent a lot more effort on it than I [1].

[1] [http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang](http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang)

<comment><USER19> I don't think it helps that the largest non-Ericsson commercial entity that attempts to curate and bounding-box the community has a kind of identity crisis around whether or not it's a services or products company.

For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Neither relx, nor rebar, nor erlang.mk, etc. were born out of said commercial entity, despite those kinds of things being _perfect_ candidates for a services company to produce to make their own lives and the lives of potential new users easier.

There have been some _huge_ high-profile Erlang use cases that would normally feed a Silicon Valley/Hacker News style hype-cycle, but somehow those came and went with almost nothing to show for it. It almost feels like if Elixir hadn't shown up on the scene to attract new users and splinter off a chunk of the massive Ruby community that the Erlang side of the world would all but dead already. Sometimes I wonder how it is one goes about blowing a 15+ year technology lead and 10 years of huge and publicly visible wins, but that's sorta what's happened.

In the curation of said community there's also been an overtone of nostalgia for "the good old days" & "yeah, that part is _supposed_ to be painful", and a sort of long-running tone deafness around on-boarding, usability, general- developer-ecosystem-friendliness, etc. complaints that certainly could have had a lot more done to be ameliorated by the commercial entities who stood to gain the most by Erlang having broader adoption.

Frankly, much like Elixir breathing a bit of new life into aura around Erlang, if it weren't for people like Fred, Tristan, Alisdair, Garrett and a few others (who again aren't part of the core supports for Erlang commercially) being really passionate against all odds about making Erlang easier to use, and to explore new use cases, and to meticulously and engagingly document all of it... Erlang would probably be dead already.

All of which might be overly harsh, but I'm having a very acute existential crisis around Erlang at the moment. I love it. I love developing in it. I love introducing it to teams and projects. And as time goes on I feel rapidly and increasingly more guilty about that given the decline it seems to be in and _has_ been in if I'm being honest with myself in retrospect.

Blargh :-(

edit: look at the increasingly dwindling sponsors list of Erlang Factory San Francisco over the last several years as an indicator of the above rant/cry- for-help.

<comment><USER18> Thanks for the insight. Out of interest, what company are you referring to in your first paragraph?

<comment><USER19> Erlang Solutions

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'm not well versed in the entire (phone) network space. Ericson switch uptime (powered by Erlang) is always cited and admittedly initially drew me to the whole ecosystem. Well mostly the "it's used in a network that has basically worked all these years so it must be rather robust one way or another" line of thinking.

However what I'm wondering is...there's other vendors and Ericson isn't powering the entire network. What software stacks are used by other vendors? I'm assuming it's mostly C-ish stuff with some ASM sprinkles like in Cisco IOS?

<comment><USER21> Ericson makes a switch that some other networks use. That switch contains lots of Erlang inside it.

</comment></comment><comment><USER22> Incidentally, does anyone have a screenshot of the "all Erlang" HN front page of similar vintage (perhaps 2009 or so)?

</comment><comment> aaron-lebo I think the "more cores == faster" benefit is overstated.

Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off.

I suspect other languages are going to fold the good parts of Erlang/BEAM into them and limit its long-term adoption.

<comment><USER23> _I think the "more cores == faster" benefit is overstated._

I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel.

 _It 's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so._

For what value of "mostly scale as well?" For me, that means doing a little extra design/architecting to break out your Golang server process into multiple worker processes.

 _it 's 10 years later and we haven't seen massively parallel architectures take off._

Because there are still barriers that are a bit too large. You either wind up having to do weird things to do what amounts to efficiently passing data between cores, or you end up using a slower language that's a bit far from the computing mainstream.

<comment><USER24> Can you elaborate on how you implemented those servers? Would you still use Clojure or Go for them now? If not, what alternative do you suggest?

<comment><USER23> My first attempt was a server for a dungeon crawler that superficially looked like a rogue-like, but was actually 12 frames/sec realtime instead of turn based. It started out on Clojure, but I afterwards ported it to Go. In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Processing would happen in two stages: 1) local data processing, where each entity got updated in a loop, sending out updates to clients and 2) collision resolution/movement. If I had to do it over again, I would relax the grid's invariant properties, and make each 80x24 subgrid completely independent, which would eliminate the collision resolution step.

In my current server, I'm basically sharding my space-game into star systems, with free travel between star systems though "Hyperspace." There is a farm of "worker processes" that is coordinated by a master server. Any instance of a star system can be idempotently spawned when a client is attached to it. < [https://www.emergencevector.com](https://www.emergencevector.com) >

I think Go is a good option for writing a game server. You'd have to be pretty profligate to make the GC pause overrun one 16.66 ms tick, and if you miss a tick here and there, who cares?

<comment><USER25> > In this server, the world was divided into 80x24 subgrids that did most of > their processing in parallel.

Is there any reason why you do update() in parallel? There is certainly some interesting challenges to solve there but did you have a reason to make it parallel other than intellectual curiosity (e.g. better performance)?

Afaik a game loop's update() is not the intense part in the game loop (maybe that's different for games with lots of world information update, like roguelikes), but rather render() and IO() are so I am wondering what your design thoughts are.

<comment><USER23> _Is there any reason why you do update() in parallel?_

I wanted to come up with an architecture that could support an arbitrarily large world given enough resources. Up to a certain density (from 150 to 250 users per "subgrid") I was close to succeeding.

 _Afaik a game loop 's update() is not the intense part in the game loop but rather render() and IO()_

"Render" in the context of a server like this is the IO. One thing you should know, is that this game supported Conway's Life cellular automata at 12 frames/second, completely shared and multiplayer.

</comment></comment></comment></comment></comment></comment><comment><USER26> Erlang's secret sauce is OTP.

<comment><USER27> OTP is what makes Erlang Web Scale™.

</comment></comment><comment><USER28> Are there online classes (eg MOOCs) teaching Erlang? I looked at Coursera, EdX, and Udacity recently and didn't find anything.

<comment><USER29> There are some good introductory videos at [https://www.cs.kent.ac.uk/ErlangMasterClasses/](https://www.cs.kent.ac.uk/ErlangMasterClasses/).

</comment></comment><comment><USER30> For folks who like Erlang, also check out Pony.

</comment><comment><USER31> How to make sure I don't read your post:

> Our site has been optimized for use with newer browsers. We also require > that your browser has JavaScript enabled.

> It looks as if your browser has JavaScript disabled.

> This site has information about enabling JavaScript, if that's something you > want to do.

Really? I am just trying read a few paragraphs of text on a fairly static- looking site.

<comment><USER32> It's even worse than that. It is static. It would work without javascript if they didn't put

          <noscript>
            <meta http-equiv="refresh" content="2;url=https://pragprog.com/no_js">
          </noscript>

<comment><USER32> As a slight followup: In the Advanced settings panel for NoScript, there's an option to disable <meta> redirects in <noscript> blocks.

</comment></comment></comment><comment><USER33> "How do programmers fix these problems? They don't. They pray." :D LOLed at this!!

</comment><comment><USER34> > How do programmers fix these problems? They don't. They pray.

Ah! No, Joe, that's what _you_ do.

Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe.

And yes, that was already true in 2007.

<comment><USER35> Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming.

(Also, Erlang has a compile-time static type checker, if type safety is something you're after.)

<comment><USER34> I'm well aware of the literature.

The fact is that still today, we have millions and millions of lines of code that work in parallel and a crushing majority of it is operating in mutable languages (C++, Java, Javascript, C#, ...).

Pushing immutable languages as the silver bullet to solve concurrency problems is trying to solve a problem that nobody has.

We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past.

<comment><USER36> I think immutability isn't really that important for concurrency in Erlang, since there's conceptually no shared state between Erlang processes -- if you use the mutable process dictionary, no other process could see it anyway[1]. In reality there is ets which is mutable with locks, and refcounted binaries which become immutable once there's more than one reference.

That Erlang forces you to build a shared nothing system is the real win for concurrency. Of course, you can do that with other languages too.

> We've moved on to higher abstraction grounds (fork join, work stealing, > coroutines, etc...), Erlang is still stuck in the past.

Erlang can do fork/join, the schedulers can work steal, and erlang processes are approximately equal to coroutines -- I don't understand what you think is stuck in the past (other than the Prolog like syntax, but you get used to that).

Immutability is a big win for garbage collection and memory allocation however, since there are no circular references, mark and sweep isn't required and a simple (generational) copying collector can be used instead.

[1] actually you can look at other processes' dictionaries if you want, but that requires a lock on the destination process.</comment></comment></comment></comment>


Centralizing distributed version control, revisited - <AUTHOR> https://blogs.janestreet.com/centralizing-distributed-version-control-revisited/

<comment><USER2> This is a good brief on how _a_ serious business manages its version control. Thanks!

</comment><comment><USER3> Could you explain why you think the recursive strategy is a bad one for working out criss-cross merges?</comment>


New Standard Deal - <AUTHOR> https://blog.ycombinator.com/new-standard-deal/ <comment><USER3> Great that YC is simplifying their deal and making it more standard and easier for founders to understand. Also great that they're switching the standard SAFE to be a post-money SAFE, as this will eliminate a lot of confusion around dilution that resulted from the complicated math of the old standard SAFE.

Interestingly, unless I'm understanding this incorrectly, this change might mean a worse deal for founders going through YC. As the post mentions, when calculating the dilution taken from a post-money SAFE, all other money raised on convertible instruments before an equity raise are excluded.

Functionally, what this means is that while investors on standard SAFEs are diluted by other SAFE investors before an equity round (as are all common holders), investors on post-money SAFEs are not diluted by other investors on SAFEs before an equity round.

So unless I'm misunderstanding this, I believe this means that YC (which was previously a common holder like the founders) will no longer be diluted by the money founders raise on convertible notes or SAFEs before an equity round, whereas before they were diluted by that money.

To demonstrate this, I modeled out a scenario where a company goes through YC, raises $2m on a $10m cap pre-money SAFE after demo day, and then raises a $10m Series A equity round at a $30m pre-money valuation. Scenario A shows the old YC deal where YC has 7% common, and Scenario B shows the new YC deal where YC invests on a post-money SAFE

Scenario A: [http://angelcalc.com/model?mod=802&dispShare=0e55666a4ad822e...](http://angelcalc.com/model?mod=802&dispShare=0e55666a4ad822e0e34299df3591d979)

Scenario B: [http://angelcalc.com/model?mod=803&dispShare=8a50bae297807da...](http://angelcalc.com/model?mod=803&dispShare=8a50bae297807da9e97722a0b3fd8f27)

Note: click "Model" to see the results. In Scenario A, YC is listed as "YC" and in Scenario B YC is listed as "Post SAFE-0 (2.1mm)". As you can see YC ends up with 1.575% more equity in Scenario B.

The simplicity of this change is great but it's important that founders understand the downside as well. Team YC, if I'm misunderstanding this, please let me know.

<comment><USER4> It's clear you put time and thought into this post, so it deserves an equivalent amount in response. I think you've understood some things correctly, but not others, but that's why we're on HN - to help clarify.

(1) The modeling you've done for the premoney safes is correct, but it's incorrect for the postmoney scenario. That's because Angelcalc hasn't been updated yet for postmoney safes that track the one we released. Angelcalc includes the Series A option pool increase in both flavors of safes, because what people were doing when flipping standard premoney cap safes to postmoney cap safes is they were just changing the pre to post, and nothing else. We deliberately took out the Series A pool increase for reasons that are all detailed in our post. That means both we and the safe holders share the Series A pool increase with the founders, which is not how it's working on Angelcalc (but we will update it soon).

Also, in your postmoney scenario, the valuation cap for the $2M safe needs to be adjusted to be a $12M postmoney cap safe.

So if you update the postmoney scenario using all of your variables based on the postmoney safe we released, the results are different. I did it by hand on excel - here's a screenshot:

[https://imgur.com/m4V51SH](https://imgur.com/m4V51SH)

Happy to send you a copy of the excel file. Also, to be perfectly transparent, these examples are somewhat artificial because they assume a 0% option pool issuance in both cases, which is unlikely to be the case. Safe investors will do better than in the screenshot I sent the more options that are issued before the Series A round. They also have the option now to ask for a template side letter to participate pro rata in the Series A round itself.

(2) The YC deal should be viewed together with the money founders will raise at demo day, i.e. as one continuous round, and thus the combined % of the company you end up selling. That combined % for YC and demo day safes was often too high in the old deal because founders had a hard time understanding how dilution was unfolding. Safe rounds may not have been priced correctly because of that lack of clarity. With these new changes, the days of raising on safes and not knowing how much you owned are over. The days of planning a Series A fundraise not knowing how much you've already been diluted are over. We strongly believe that founders will end up less diluted by the combined % of YC and demo day safes. It's interesting that you would characterize an uptick in YC ownership as "downside" for the founders. I don't think founders look at our ownership - they look at theirs.

(3) An underlying assumption of your post is that the safes and YC deal are changing, but everything else — valuations, option pools, amounts people raise and dilution transparency (or lack thereof) — will remain the same. The point of us doing this though is that we expect it to change all of those other things. Everything is tied together. As Michael already pointed out, once you can see what's happening, both investors and founders can take better actions on both fronts. High-res fundraising should also become easier, as Carolynn points out on [http://ycombinator.com/documents](http://ycombinator.com/documents).

<comment><USER3> Thanks Jason for the thoughtful reply, and thanks also for your work on simplifying and improving the YC SAFE. I think these improvements will benefit the entire ecosystem (founders & investors & employees) by making it easier for everyone to understand SAFE dilution.

Still not clear on how (in most cases and assuming there is not a 0% option pool pre-equity round) this will not lead to increased expected dilution for founders from the YC deal as compared to the old deal, so would love to play around with your Excel sheet. My email is my HN username at gmail.

<comment><USER4> Sure - just sent to you.

<comment><USER3> Played with your excel and while the difference is not the same as I calculated with AngelCalc, it still seems the dilution from this new YC deal will be greater than the old YC deal post-equity round in basically every circumstance.

Essentially, with this new deal, after equity financing YC will own 7% minus the dilution from the equity round minus dilution from any options pool increase [1]. Previously, after equity financing, YC would own 7% minus the dilution from the equity round minus the dilution from the SAFE round.

While it's true founders are getting a little bump on YC absorbing the dilution from a Series A option pool re-up, in my experience these are typically 5% to maximum 15% increases. Whereas the dilution from post-YC SAFE rounds are typically 15% to maximum 30%. So YC is assuming a potential 5-15% dilution in their ownership while avoiding a 15-30% dilution in their ownership. Translation: YC will own more post-equity financing than they would in the old deal.

This puts a burden on the founders to make up for that increased dilution by raising the post-YC SAFEs at a higher valuation than they otherwise would, which will likely make those raises harder. Alternatively, they can raise their Series A at a higher valuation than they otherwise would to make up for YC's extra ownership, but that will make those raises harder than they otherwise would be. So there is a real dilution downside for founders here.

1: in reality YC will continue to own 7% after the equity round because they'll exercise their pro-rata right during the equity round but that doesn't change the underlying point being made here so will ignore it for simplicity.

<comment><USER4> I answered your first model comparison with point #1. Can't use it here since I don't know what other scenarios you're modeling out.

I think points #2 and #3 continue to apply. You can't say that the new framework will result in more dilution in "basically every circumstance," because that assumes all of the surrounding aspects of the circumstances will continue to remain the same. I can model out a scenario for you as well that shows a thoughtful founder now able to better plan out a round using a series of escalating valuation caps, rewarding the earliest investors, to raise the same amount of money but for less overall dilution, in precisely the manner described by PG in his original post. Or another scenario where investors are ok with slightly higher valuations because they have certainty of ownership. Or another scenario where a founder who previously would've raised an unnecessary extra 5% now doesn't, because the dilution math is clearer.

Your point about safe dilution being 15-30% is exactly right, and exactly one of the reasons we're doing this. The high part of that range is too high. People are raising too much, on too dilutive terms, because of the lack of transparency. Founder dilution is driven by what everyone else on the cap table is getting, not just us. If that sum total of "everyone else" is still less, founders are still net better off. If you want to frame the dilution aspect all indexed to YC ownership, that's ok, but the outcome was already pre-figured by your choice of framing in the first place. We can agree to disagree on that.

That said, I think one thing we can definitely agree on is that the success or failure of this new framework will be judged by whether founders are more or less diluted in the end, and have a harder or easier time raising money. We've already made our bet, so there's not much to do here but let it play out.

<comment><USER5> For us mere mortals following along... I don't necessarily understand what you guys just debated about the impact of options pools but I did grok this from the spreadsheets: In the new model,

Founder stake goes 48.8% -> 49.6%, a modest 1.63% increase.

YC stake goes 3.68% -> 4.55%, a whopping 24% increase.

Other SAFE investors stake declines 12.5% -> 10.8%, a 13% decrease.

So while the immediate impact on founders appears negligible (assuming all variables stay the same), it would seem that this new model represents a fairly large transfer of ownership from other SAFE investors to YC.

Wouldn't this be a cause of concern for founders? If SAFE investors have a particular percentage ownership in mind, wouldn't this push founders to raise more from them (or give a discount, etc.) and thus increase dilution?

<comment><USER3> You've nailed it. Becaise of YC's increased ownership, founders will either have to raise less from SAFE investors or take more dilution, because this change won't make those SAFE investors be willing to pay higher valuations. That's the downside.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> > $500k safe at a $10 million post-money valuation cap means the founder has > sold 5% of the company.

This is a common oversimplification, but it's somewhat dangerous and I would be happier if people were more cautious in what they said here. It simply doesn't mean what you said; it means the founder has sold _at least 5%_ of the company. If you're going to either raise 50m or shut the company and ditch your investors, then it's a wash; but if find yourself in a low-money scrappy situation, which realistically is where most non-YC companies are, it's very significant.

Convertibles and other structurally similar securities, in contrast to priced equity rounds, essentially have built-in down-round protection for investors. They have advantages, too, not least the speed in which deals can be done, but if you can do a priced round or a convertible round at similar speed and at similar cost, give serious consideration to taking the priced round.

<comment><USER4> Everything you say is fair. On the point about "at least 5%," this is addressed in footnote #3 to the blog post. It's true that it's a simplification, but that's partly what makes the construct easier to work with.

I think the other thing to take into account is that if you're doing a comparison of safes, notes and priced rounds, it's not just a matter of seeing if speed and cost are equal, but what else you might have to give up in terms of rights. Priced rounds can come with downround protection too (often do), as well as board seats and investor vetoes on financings, sales of the company, etc. Convertible notes are debt so the investors will have a technical right to demand their money back after a set time (maturity).

<comment><USER6> Yep. I'm essentially arguing that simplifying here is dangerous, _no_ construct is easy to deal with, and I'd rather more care were taken (broadly across the entire industry, not singling out YC here) in representing that.

Also: these terms are completely reasonable and under normal circumstances if I were doing a startup – and this valuation made sense – they'd be terms I'd be happy to take. For the avoidance of doubt, all of this is about the marketing, not the substance; the substance is above reproach.

As you say, speed, costs, rights (board seats, information, pro-rata, drag- along/tag-along, you name it), pref structure, etc are all real things. I just prefer addressing those all up front.

<comment><USER4> Cool. Appreciate the thoughtful feedback.

</comment></comment></comment></comment><comment><USER7> I'd love to see YC or someone release a definitive recommendation on fair equity distribution among the employees of the company. Maybe there'd be a few variations on it to handle differing scenarios, and even if it's really hard to have a one-size-fits-all I think it'd be similar to their SAFE note which tries to offer a pretty good deal to all involved.

<comment><USER8> One of your favorited links is "Holloway Guide Equity Compensation"[1] and it has a section of typical percentages. It also mentions some higher percentages for employees which are not typical.

As for "fairness", it's going to ultimately be in the eye of the beholder. You could give employee #12 a 5% stake (which is CEO level at other startups) and yet that employee still feels it's "unfair" even it's explained that he's getting more than anybody else in SV. It's human nature for the employee to think he's worth _more_ , and for the employer to think he's worth _less_ \-- and therefore, they negotiate.

[1] deep link to the employee ownership percentages: [https://www.holloway.com/g/equity- compensation#_there_are_no...](https://www.holloway.com/g/equity- compensation#_there_are_no_hard_and)

<comment><USER7> Thanks for reminding me! I've thought about this a lot from time to time, and I realize I forgot to mention something else besides just the equity distribution.

I've heard plenty of stories of nasty ways companies wrangle hard-earned equity out of employees. I think it'd be great for YC or someone of similar stature to encourage companies to use very standard terms to avoid a lot of the unkind ways employees get screwed. One example would be terribly short windows for exercising options.

<comment><USER4> re: short windows for exercising options:

[https://triplebyte.com/blog/fixing-the-inequity-of- startup-e...](https://triplebyte.com/blog/fixing-the-inequity-of-startup- equity)

[https://blog.samaltman.com/employee- equity](https://blog.samaltman.com/employee-equity)

[https://news.ycombinator.com/item?id=11198991](https://news.ycombinator.com/item?id=11198991)

[https://a16z.com/2016/07/26/options- plan/](https://a16z.com/2016/07/26/options-plan/)

[https://dangelo.quora.com/10-Year-Exercise-Periods-Make- Sens...](https://dangelo.quora.com/10-Year-Exercise-Periods-Make-Sense)

</comment></comment></comment></comment><comment><USER9> What does "safe" mean in this context?

<comment><USER10> Simple Agreement for Future Equity ([https://en.wikipedia.org/wiki/Simple_agreement_for_future_eq...](https://en.wikipedia.org/wiki/Simple_agreement_for_future_equity_\(SAFE\)))

</comment></comment><comment><USER11> Overall, simplifying how to understand one's cap table is great. It gets in the way of many founders understanding their business in really pernicious ways.

I do believe this will change the dynamic for YC founders dramatically 1 - <USER2> years out if not ready for a Series A (equity round) but need more capital (seed extension). I know many people who raised $500K - $3mm more on SAFEs. Because they were pre-money, the dilution for stacking SAFEs worked. Now, that will be much harder. The next round of financing will need to be an equity round to convert SAFEs to equity. I don't know if this is good or bad, but it will push people very heavily towards an equity round if they need any more funding.

<comment><USER12> It would still be very easy to raise a bridge round on SAFEs at a higher cap (or the same cap). Not sure why there would be a push to equity round. Even better, you'll know your dilution after the bridge round which will better allow you to plan for the A.

<comment><USER11> My understanding is that additional post-money SAFEs dilute solely common, whereas additional pre-money SAFEs dilute common and other pre-money SAFEs. So if you want to do a new round, by doing an equity round, you can dilute the post-money SAFEs with common. But if you do a 2nd post-money SAFE round, solely common gets diluted.

Since keeping cap flat is logistically / emotionally easiest for both sides to swallow, the founder dilution is worse under a "flat" scenario. In the pre- money world, if you did pre-money $10mm cap and raised $2mm, then later another $2mm at same cap, common would own ~71% (10 / 14) on conversion (assuming A is high enough). In post-money world, if you do $12mm cap and raise $2mm (so equivalent to old world in 1st round), then later raise another $2mm with same cap, common would own 67% (8 / 12). That's just 4 - 5%, but a real difference.

So I believe the incentive is higher to do an equity round to convert the post-money SAFEs so they can be a part of the dilution of the new round. Unless I am mistunderstanding how they'd convert or something else here. The math is complicated (which I guess is the whole point of why moving to post- money will improve founders' understanding).

</comment></comment></comment><comment><USER13> YC Safes are great way to raise money for early stage startups. It allow them to focus on business which is most important during early stages.

This is right step in simplifying it even further.

<comment><USER14> We raised on safes, it was harder because some VCs don't like them as they've not really been litigated yet (or something) - but I tend to agree they're a great convertible security. Lets end this pre-money nightmare, cap table hell.

</comment></comment><comment><USER15> What is a "safe" exactly?

<comment><USER12> [http://www.ycombinator.com/documents/](http://www.ycombinator.com/documents/)

<comment><USER16> Michael, do you know where can I find stats for the number of founders per company accepted in YC?

Edit: I found it here. [https://blog.ycombinator.com/common-misconceptions- about-app...](https://blog.ycombinator.com/common-misconceptions-about- applying-to-yc/)

<comment><AUTHOR> The average for the last batch was 2 founders.

<comment><USER17> This is one of those cases where the word "average" is kind-of unhelpful. Mean? Mode? Median?

<comment><USER18> I would guess Median is also 2.

</comment></comment></comment></comment></comment></comment><comment><USER19> Great to see this happen again after the original "The New Deal" in 2014[0]. I'm a big believer in having enough capital to not have to worry about day-to- day costs so you can focus on actually running and growing your business, and this feels like a good sort-of "cost of living" increase.

[0] [https://blog.ycombinator.com/the-new- deal/](https://blog.ycombinator.com/the-new-deal/)

</comment><comment><USER20> Nice to see the offer getting better! I wonder about moral hazard in early stage funding. What if YC were to offer rent and salary for founders for 12 months? This would similarly change the dynamics around founders worrying about money while avoiding some of the temptation to over-spend and generally waste funding before building a product.

<comment><USER12> Seems like the founder should be the one who figures out how to best spend the money no?

<comment><USER21> Someone should do a study to see if the lottery effect--where winning the lottery leaves you worse off because you don't know how to handle that much money--is at work with VC funding.

</comment></comment></comment><comment><USER22> > But startup costs have undeniably increased over the past few years. We > thought a $30K increase was necessary to help companies stay focused on > building their product without worrying about fundraising too soon.

I didn't realize that this was true. I'm interested in hearing more about what has caused the increase in startup costs.

<comment><USER23> Primarily cost of living increases for the founders. Things like hosting and other services have gone down.

<comment><USER22> Ah, that makes sense. Thanks.

</comment></comment></comment><comment><USER24> I fail to understand how the YC deal operates as a SAFE with 7% equity?

If the SAFE is a non-priced round, then the amount of equity the investor gets is decided when the conversion happens, so it is an unknown, which is why a cap exists.

Is YC taking 7% + the conversion?

</comment><comment><USER25> That's friends and family size money. Why get a VC at that scale?

<comment><USER26> > _Why get a VC at that scale?_

A dollar of VC is generally worth, _ceteris paribus_ , more than a dollar of friends & family money. The coaching, connections, reputation boost when talking to other investors, sales prospects, potential employees, the media, _et cetera_ are meaningful.

<comment><USER27> That seems certainly to be true of YC, but I'm less certain about VC in general. YC aside, the major benefit of VC money is that it can make getting _more_ VC money easier, since it's bundled with social proof.

</comment></comment></comment><comment><USER28> How representative are the terms outlined in the example? 18.25% for 1.6M where the lead paid 1m for 6.25%? I've never raised money before so I don't know.

<comment><USER4> Michael's other blog post has some numbers:

[https://blog.ycombinator.com/yc-has- changed/](https://blog.ycombinator.com/yc-has-changed/)

</comment></comment><comment><USER29> What are the practical implications of "post-money cap safe"?

Could someone please explain this in laymans terms?

<comment><USER4> Both you and your investors will have much better visibility into what % of the company you are selling and they are buying when you are fundraising. It really is as simple as that.

</comment></comment><comment><USER30> So $150,000 is enough runway for what: 0.6 man-years? Sounds legit.

<comment><USER27> The idea isn't that you go for years on the YC 150k. For most YC startups, the idea is that the social proof of getting through YC buys you access to the market for syndicated convertible debt rounds, which, while talked about extensively on HN, are not all that easy for first-time founders to access without YC's help.

So really, YC is giving you some money to get through demo day, at which point you'll raise real "runway" money from seed funders.

There's a cohort of YC founders that only do YC (or, at least, rely on YC's money for a long time before raising further); those companies get to break- even cash flow quickly and often aren't (or aren't yet) on the "shoot the moon" trajectory VCs are looking for. But those companies aren't made or broken by YC's decision to "fund" them.

</comment></comment><comment><USER31> Let me stay in Medellin, and you're on.

</comment><comment><USER32> Standard deal does not have a discount?

<comment><USER33> no need for a discount if there's a cap. Discount is nice if you don't want to try and set a cap/price, but if you're OK setting a cap then it effectively grants a discount

<comment><USER34> Incorrect. A cap means that above the cap, no discount matters. Below the cap, however, the discount is applied.

Example: raising 1M at 10M cap, 20% discount.

Scenario 1: next priced round at number below 10M - the cap doesn't apply, the discount does.

Scenario 2: next priced round at number between 10M and 12M - the cap doesn't apply, the discount does.

Scenario 3: next priced round at more than 12M - cap applies, discount doesn't.

In short, either cap OR discount are applied, whatever is the most beneficial to the investor.

<comment><USER4> I think Daniel was working off of a different understanding of 'discount.' I think he meant a discount off of the price of the next round (Series A). If the Series A is $30M pre but you set a valuation cap on the safe of $20M post, you are getting a 'discount' on the conversion of the safe in the Series A (because it is lower than $30M pre).

You're right though that there's a flavor of safes that contain both a discount and a valuation cap, and the investor gets the benefit of whichever approach results in more shares, and your explanation is good.</comment></comment></comment></comment>


Move deliberately, fix things: How Coinbase is building a cryptocurrency empire - <AUTHOR> https://www.washingtonpost.com/business/economy/move-deliberately-fix-things-how-coinbase-is-building-a-cryptocurrency-empire/2018/05/17/623d950c-587c-11e8-858f-12becb4d6067_story.html <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=17110865](https://news.ycombinator.com/item?id=17110865)</comment>


Ask HN: Cognitive Science vs Computer Science - <AUTHOR>

I have been debating changing my major from Computer Science to Cog Sci with a specialization in human computer interaction.
I feel that the traditional computer science education stifles creativity and ignores important emerging areas such as web and mobile application development.
The question is would you hire a web developer out of college who did not major in computer science but had real world experience including internships at major companies. <comment><USER2> I did undergrad degrees in both CogSci and CompSci. Both have been virtually irrelevant to me in my software development career so far. Both were valuable to me for reasons of self-actualization. I would advise you to do what you find personally valuable.

I would not say that CompSci "stifles creativity", nor even that it ignores web development entirely (although that's a murkier point, and mobile is too new for most universities to teach it, which is just how it goes). But I would say that the overlap between what universities know how to teach, and what is relevant to working software development (in emerging areas and in well- travelled areas) is very small indeed, perhaps a few percent of each.

When advising my lead on a hire/no-hire decision, I would give absolutely no weight to the degree or lack thereof, and would give weight to a combination of 1) real experience, and 2) my (flawed and subjective) judgement of intelligence and skills.

All that said, apparently some companies still value the piece of paper. I think there are three levels of degree-ness from those companies' perspective: correct degree (cmpt, eng, maybe math), other degree(english lit, archeology), no degree. And I think that those companies will see a CogSci degree as virtually equivalent to a History degree: "Oh, I guess he's got a degree, so that's nice, but the content of the degree is not what we might hire him for".

Does anyone take academic HCI seriously in industry?

<comment><USER3> > Does anyone take academic HCI seriously in industry?

Microsoft, Yahoo, IBM, and Google have fairly big academic-leaning HCI groups as far as I can tell; they even publish quite a bit at places like CHI. Apart from machine learning, graphics, and storage systems, it's one of the easier areas for a Ph.D. to get hired in industry.

</comment></comment><comment><USER4> I feel engineers are born, not made, so if you don't have it in your blood, you are probably better off just picking and choosing a few good CS courses, or maybe getting a minor. It also depends on the school. Many schools have pretty lame CS programs and you're better off taking a finance class or an HCI class vs. filling out your electives with dumbed down "software engineering" curricula or boring "data structures III" classes. I switched my major to math because the first couple CS courses I took were duds and it hasn't hurt my career.

It depends on your personality, but personally I think HCI makes for a better career these days. The product managers I know make more money than engineers, work banker's hours, and don't have to deal with the stress of putting out fires or getting replaced by younger versions of themselves at age 35. You do have to go to more meetings, though.

</comment><comment><USER5> Absolutely yes, provided they can do the job I need, and can demonstrate that they can do the job I need.

The job I need is adding value to the company, usually by programming.

Of the programmers I've hired, less than half have degrees in computing. It's interesting seeing the interactions between them, and seeing that each brings something useful to the discussions. When I interview, I'm looking for someone who can program in any relevant language, not just the ones we use, but who has an interest in a range of topics within computing, including a passing acquaintance with more than one language, more than one paradigm, and more than one context.

Can you write working code?

</comment><comment><USER6> I am a philosophy major.

Algorithms are fundamental to good arguments, and in fact, knowledge in general.

Doing philosophy (especially logic & analytic philosophy of language and mind) has enabled me to see through the bullshit and know where the really interesting areas are to pay attention. Often a bunch of folks will turn off in class when discussing something that they see as just some sort of industry standard, and doing philosophy enables me to see the logical reasons why a particular strategy was adapted.

I can't imagine how anyone does computer science seriously without a philosophical interest in it.

</comment><comment><USER7> Actually it depends what classes you take. To learn web and mobile application development you mainly have to teach yourself. What I would do is try to go to a mobile / web user group and still get your cs degree. Note I am a student.</comment>


The Fake Americans Russia Created to Influence the Election - <AUTHOR> https://www.nytimes.com/2017/09/07/us/politics/russia-facebook-twitter-election.html <comment><USER2> An even better idea: find a candidate that people like, someone who could beat the least popular candidate in history. That might work better than endless excuses about marginally relevant sideshows.

<comment><USER3> Don't you think it would be better to both 1) get better candidates 2) stop foreign states from successfully interfering in our elections via propaganda and hacking private systems?

edit - disappointed this got flagged, it's only political because certain parts of the users turn it into flamewars. Russia intelligence was attributed as the hackers behind the DNC intrusion by top firms, and is accused of systematically coordinated the timing of damaging info with Wikipedia, the Trump campaign, and networks of social bots to successfully flip the election. Then Trump damaged NATO alliances and softened his part's platform on Ukraine/Crimea, among other things. Regrettable that we can't have a mature conversation about this critical and topical subject.

<comment><USER4> Do you not recall the number of foreign Hilary supporters pushing on social media and chat rooms?

<comment><USER3> I don't, post some citations. How's that related to anything I wrote, though?</comment></comment></comment></comment>


Google+ bug exposing user emails - <AUTHOR>

Go to a Google+ profile and click on Photos. If that person has tagged anyone else in a photo you can view source and search for "@gmail.com" and you can immediately see their e-mail address.<p>Probably not a good thing. Also noticing that the Google spider is picking it up as well. <comment><USER2> [http://www.googleplustalk.net/forum/google-news/40-google- ex...](http://www.googleplustalk.net/forum/google-news/40-google-exposing- user-email-addresses-right-now.html)</comment>


The SpaceDrive Project – First Results on EMDrive and Mach-Effect Thrusters - <AUTHOR> https://www.researchgate.net/publication/325177082_The_SpaceDrive_Project_-_First_Results_on_EMDrive_and_Mach-Effect_Thrusters <comment><USER4> Given that reactionless thrust is even less plausible on a theoretical basis than superluminal neutrinos, I really hope this doesn't come as much of a surprise to anyone.

<comment><USER5> Not a surprise, but certainly a disappointment. It would have violated our understanding of physics, but it's not like that's never happened before.

<comment><USER6> > It would have violated our understanding of physics, but it's not like > that's never happened before.

I've heard this sentiment a lot when it comes to the EMDrive, but honestly I think it really misunderstands how science progresses in general. For EMDrive to be real, virtually everything we know to be true about physics would have to be false: if you're saying conservation of momentum can be violated, or conservation of energy can be violated, then basically all of modern physics would have to be wrong.

When science, and especially physics, advances, it is very rarely, if ever since Newton's time, that the settled physics is 100% wrong. Instead, the "old" physics tends to be an approximation under most conditions, or there is a new phenomenon that can be explained without really violating the old rules. For example, conservation of momentum still holds under special relativity, it's just that we discovered things without mass can have momentum.

Thus, the only explanation that would really be plausible is if there is "something else" going on with the EMDrive where momentum and energy are still conserved, just that there is something happening beyond our current understanding of "energy" or "momentum". I haven't seen any explanations that even try to postulate what that could be. All I ever have seen is "but the old physics could be wrong!" without an explanation of _how_ it could be wrong.

<comment><USER7> Horsefeathers. To name two examples. The Einstein-Podolsky-Rosen's paper on entanglement "Can Quantum Mechanical Description of Physical Reality Be Considered Complete?" (Einstein et al. 1935) ignored as trash for decades. The Casimir effect was predicted from quantum theoretical calculations, but again, no-one did the experiment for decades because they felt it was a trash prediction that couldn't be true 'cause it ignored basic physical laws that everyone knew had always held and always would. Empty space just couldn't do that. And on and on and on - I've just covered this century a tiny bit, not all the time since Newton. Dark energy anyone?

Knowledge of the mechanisms behind X doesn't always precede discovery of X (why would anyone think it would always do so?) Lack of a known mechanism was why John Newlands version of the periodic table was greeted with contempt, and Mendeleev didn't find it easy sledding at first, either. But the contempt was unjustified. Birds were able to fly before the airfoil was discovered or airflow understood. Electricity was a broad field of study (Maxwell's equations, etc) long before the electron was discovered. The how usually trails the what in the history of science.

I won't be shocked if the Emdrive is a wrong turn, but the idea we could _know_ that in advance is sciencism - the satanic inversion of science - <USER2> empirical science.

<comment><USER8> There is still some place for using theoretical predictions to guide experiments. For example, I have developed a rune that may be used to cast Fireball - it consists of three triangles carved in to a very expensive gold- titanium laminate. If that test fails, I suppose we also ought to try four triangles, a triangle and a circle, the word 'fireball' engraved on the perimeter of a hexagon, three triangles engraved onto a momentum-nonconserving cone...

More seriously, there was a good reason to strongly suspect that the EM drive wouldn't overturn physics: we have probed electromagnetic interactions at energy densities far higher (gamma ray scattering) and far lower (radio telescopes) and everything in-between, and they all seem to be points on a continuous surface defined by Maxwell's equations applied to quantum mechanics. A working EM drive would actually be very close to the magic rune I described above: a wildly noncontinuous point where the laws of physics became massively different for one particular arrangement of matter, and then go right back to normal if you step in any direction around it.

<comment><USER7> The general use of experiments in science (as opposed to a Homo Erectus experimenting with rock types when making hammers) is to test what we think we know, to see if it's really so. IIRC the "inventor" of the Emdrive had a theory of his own to go by that led him to his device. We probably agree that it's the use of theory to preempt and prevent any experimentation that is pernicious.

(reply to below comment) While not all experiments are equal, there's no right answer, and plenty of room for good and bad luck. The marketplace of ideas ensures enough variety that we don't miss toooo much (maybe.) Yet very often, it's those with the most eccentric and false ideas, such as Keplar, who stumble onto the right path because at least they're looking where nobody else is, for correlations no-one else thought to! So my bias is toward the most novel experiments that are still extremely likely to fail, as I think you agree.

Just this week I was reading up on the Stern-Gerlach Magnet experiment, which discovered spin; something the experimenters absolutely weren't looking for. The idiots (or recipients of blind luck) win a lot of rounds in science, 'cause they're at least trying something genuinely new.

Slightly different alloy = slightly different string theory?

<comment><USER8> > _We probably agree that it 's the use of theory to preempt and prevent any > experimentation that is pernicious._

So, there's a point about philosophy of science to be made here. If you test one bronze alloy for antigravity, and then test a slightly different bronze alloy for antigravity, and so on, finding all of them to fall when dropped, how can you know when it's reasonable to stop testing bronze alloys for antigravity? Presumably, you should eventually say "this idea has already been tested," and then stop. However there will always be a new ratio of metals to try: the only way to say "this has been tested" or "this hasn't" is to establish enough of a theory to make predictions about the effect of gravity on _every_ bronze alloy, and then trust it when it says it will not become negative (at least, trust it enough to let it rule out potential experiments from grant approval.) When we say, "a new arrangement of photons will still conserve momentum," we are performing exactly the kind of interpolation from other experiments involving photons in cavities that, previously, stopped us from making more and more bronze bars in the search for antigravity.

<comment><USER9> Sure, but is that line of reasoning similar to the situation with the EMDrive? I thought the interesting part was that there was an actual as-yet unexplained result / measurement. So, going back to the bronze alloys, it's more like "crazy person X has found a bronze alloy that almost seems like antigravity, and it seems to break all fundamental laws of physics". Should we disregard, or humour it look into it? It was always very likely to be some kind of error, but it's a fundamentally less silly exercise.

<comment><USER10> _there was an actual as-yet unexplained result / measurement_

      1. "actual" isn't that actual if enough independent
      scientists aren't duplicating it using scientifically
      accepted testing procedures.

      2. "actual" isn't that actual when the quantity is down
      at around noise level.

_crazy person X has found a bronze alloy that almost seems like antigravity_

You're using words like "almost seems" that just don't match up to the results seen, especially considering the flawed testing methods used.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Poor title. It is sad to see academic descend into click-baitness. Even the abstract does not tell you the key point of the paper. The most one gets from the abstract is:

Our results show that the magnetic interaction from not sufficiently shielded cables or thrusters are a major factor that needs to be taken into account for proper µN thrust measurements for these type of devices.

Reading the paper one can finally get to what we want to know, "Do these thrusters work?" The answer is no and/or can't tell yet.

Under the EMDrive section:

This clearly indicates that the "thrust" is not coming from the EMDrive but from some electromagnetic interaction.

Under the Mach-Effect section:

This again indicates that there must be some electromagnetic interaction or thermally induced center of mass shift that is masking any real thrust value.

Edit - I did not read the whole paper but skimmed for these descriptions of if they found any real thrust signal.

</comment><comment><USER12> I think everyone that hopes for a bright future wishes the EM drive worked--an Epstein Drive in our own time! Alas, wishes do not make it so...

<comment><USER4> Reactionless drives are even "worse" than Epstein drives, since they break conservation of momentum entirely. Epstein drives just have wildly implausible characteristics- while they might break all known laws of, say, material and nuclear science, they don't break conservation laws since they require reaction mass.

<comment><USER13> Given what appears on screen, the Epstein Drive doesn't even have that problem. It "only" acts like an electrostatic confinement fusion reactor with a hole in the confinement, slight enough for only the fusion products to escape, where the nozzle points.

(Edit footnote: only seen s1/2, anything surprising in s3 is unknown to me).

<comment><USER4> The "Eros incident" does imply that the aliens have an interesting relationship with momentum, since ordinarily accelerating something that big that fast would grind everything to a pulp.

</comment></comment></comment></comment><comment><USER14> I want to believe the same way I suspend disbelief when I read S.F. -Its temporally applied. Stop reading the S.F.? no time travel or FTL.

So my wishes aside, I feel like this is very tenuous, and is going to come down to "better measurement isolated an effect causing this" more then "there is now a tractable reactionless drive at scale for big things"

</comment><comment><USER15> I don't understand how the EMDrive came to be a serious topic.

First, someone proposed a design that violates both conservation of momentum and conservation of energy, but that's cool because you know, fuck physics. Then there was a hoax and yellow journalism and in the end, several experiments failed to confirm/reproduce the effect, but that's cool because we have this awesome theory we are trying to confirm, right?

By the way, I am looking for a team of physicists that will confirm my revolutionary Tooth Fairy Drive(tm).

</comment><comment><USER16> _Testing of propellantless propulsion concepts requires a highly sophisticated thrust balance that must be able to reliably detect very small thrust with a resolution down to the nano-Newton range, block electromagnetic interactions as much as possible and limit any balance-vacuum chamber wall interactions._

The thrust, if any, is so weak it's down in the noise. For a propulsion system, that's a big problem. It's like cold fusion in that way.

<comment><USER16> Nano-Newtons. For comparison, the tiny rockets used for attitude control on satellites have a thrust of about four Newtons. Falcon 9 booster, about 7,000,000 Newtons. This thing, if it works, maybe 0.00000001 Newton.

</comment></comment><comment><USER17> The fact that no-one has conclusively disproven this yet gives me hope. My desperate desire for this to be real has nothing to do with that hope whatsoever.

I feel like, if this is real, it's one of those sci-fi MacGuffin technologies. Literally changes everything.

</comment><comment><USER18> The tldr for emdrive: having verified that changing the direction of the engine the thrust direction also changed, but when they attenuated the power to just the drive component, which should have changed the thrust, but it did not. Therefore the thrust being seen was not being produced by the drive itself.

For the piezo one the predicted thrust was below the noise threshold in their final tests (specifically below center of mass movements that were also - <USER3> my reading - due to the control electronics)

</comment><comment><USER19> I think it's reasonable to speculate that the air force is already carrying out live tests. The reason for this is that NASA went through a substantial amount of effort to trial and test the EM drive to their greatest ability, and it came out on top with everything they could throw at it. And it's just been a black out since then. That was about 1.5 years ago.

In the interim the air force has sent up the classified X-37 [1]. They've stated it's mission purpose is _" risk reduction, experimentation, and operational concept development for reusable space vehicle technologies, in support of long-term developmental space objectives"_. That's certainly a horoscope style description, but at the same time it does seem to fit quite well for live testing of propellantless drives, even if not as a primary mission.

Furthermore, if the EM-drive did work, it would have a beyond revolutionary impact on everything and so it would not be surprising that it would end up getting classified after passing the initial slew of tests thrown at it.

[1] - [https://en.wikipedia.org/wiki/Boeing_X-37](https://en.wikipedia.org/wiki/Boeing_X-37)

</comment><comment><USER20> I'm still convinced EMDrive is the latest cold fusion, perpetual motion, panacea, whatever they are calling it these days.

</comment><comment><USER21> Since you can launch cubesats for comparatively little money these days, someone should actually launch one.

<comment><USER22> Unfortunately it would have to be a little further from Earth's magnetosphere to get a good test. Cubesats are kind of atmosphere skimmers.

</comment></comment><comment> c-smile Damn, the picture "killing of glorious idea by disgusting facts" again.

Sigh, will wait for the next "deformator of space/time curvature" device for the human race to reach stars ...

</comment><comment><USER23> Assuming the effect of the EMDrive were real and practically exploitable, what does that say about the Fermi paradox?

<comment><USER24> As a sci-fi writing prompt? "We're first," with all the disappointment and responsibility that implies.

</comment></comment><comment><USER25> I always doubted the reactionless drive aspect of this, but has anymore research gone into the apparent spacetime warping effect that one NASA group discovered? Even if it can't do anything more than disort light more effectively than lots of magnetism doesn't make it useless

</comment><comment><USER26> There goes my hunch that it was rectified DC currents in the cavity.

</comment><comment><USER27> In other news, prepetual motion machine found not to work.

<comment><USER28> No. Nothing was found (nailed down, proven) here except that error bounds need to be improved.

</comment></comment><comment><USER29> Edit: Title has been changed, leaving this for posterity.

Apologies for formatting, but the title doesn't match the conclusion of the paper.

"First measurement campaigns were carried out with both thruster models reaching thrust/thrust-to- power levels comparable to claimed values. However, we found that e.g. magnetic interaction from twisted-pair cables and amplifiers with the Earth's magnetic field can be a significant error source for EMDrives."

There was no experimental validation of this, just speculation based on their observations. They propose a simple fix, run the experiment in a magnetically shielded environment. They suggest Mu metal for maximum shielding, which would be good, but I'm a little skeptical that the vacuum vessels used in previous tests would have allowed a substantial flux of earths magnetic field through the environment. Using my phone's basic magnetometer, I get an order of magnitude reduction in field strength by placing it ~8" inside my oven and leaving the door open.

In any event they are probably on to something here. Certainly a more plausible explanation than any of the alternatives.

<comment><USER30> There was kind of. When they turn the EMDrive on its side the thrust doesn't come from the cone anymore it comes from an angle meaning that the angle at which the EMDrive/cone is placed has no relevance to the thrust's vector.

Imagine turning a rocket from horizontal to vertical and finding it still goes up, despite the exhaust from the engine going sideways.

<comment><USER31> That's not what Fig 13 says.

</comment></comment></comment><comment><USER32> I am surprised that nobody has yet to attempt the "simple" solution for testing something like this.

The simple solution being to put it in space, turn it on, and see if it 'stays' in space.

The claimed amount of thrust is significant enough that it will either obviously succeed or fail if you actually put it in space.

<comment><USER33> That's not "simple". It's very, very, very expensive to put things in space. Trying to figure it out on the ground first makes sense for a number of reasons.

<comment><USER34> They should have asked Elon to toss it in the back of his roadster.

<comment><USER22> Damn it, that would have been a great idea. We could have gotten rid of this silly concept for good. Musk, it's time to launch another car!

<comment><USER35> Well, to be fair, Elon _did_ offer a free payload to NASA but they were too old and grumpy to accept the generous offer so Tesla nailed a car to it at the last minute instead.</comment></comment></comment></comment></comment>


The end of the conference era - <AUTHOR> https://marco.org/2018/01/17/end-of-conference-era <comment><USER2> And yet, what happens "around a conference" (socializing, meeting people, discovering new things) only happens at conferences. The human interaction is dominating.

I don't agree that the talk format is bad, either - the problem is that, at many conferences, many non-professional speakers (and those include a bunch of seriously good developers) are simply unable to structure and deliver a good talk.

But, if we find another system to deliver the content in-person, it'll be a nice addition.</comment>


There isn't much left of Marissa Meyer's golden parachute - <AUTHOR> http://www.bloomberg.com/news/articles/2016-03-24/there-isn-t-much-left-of-marissa-mayer-s-yahoo-golden-parachute <comment><USER2> I actually feel a bit sorry for her; I think she's a victim of both the Peter Principle and luck; had she continued serving in VP and director-type roles that she'd have had an excellent career.

She's certainly brilliant, but she seems to have been terribly ill-suited for her role at Yahoo. I don't know if anyone could have succeeded at that roles, but she sure hasn't.</comment>