Why Erlang looks like it does - <AUTHOR> http://erlang.org/pipermail/erlang-questions/2015-December/087223.html <comment><USER2> This is a quite beautiful post about engineering in general, actually. You try to solve a practical problem as best as you can, and you get sort of an unintended-beneficial-consequences effect and end up creating principles that have a more universally-applicable nature.

I personally hope Elixir helps thrust Erlang into ever more success. (But not so much success that it becomes a victim of it...)

<comment><USER3> Two sides to every story.

What is not beautiful is that:

\- the people who conceived the original idea of the 'Actor model' were not appreciated enough, and their work had to languish in obscurity, during the OO (object-oriented) hype era, before it was rediscovered and later the dots were connected.

\- 'reinvention of wheels' is bad because it's inefficient.

\- Not to mention original OO idea by Alan Kay, in Smalltalk, was actually the 'Actor model' but it ended up being very misunderstood when implemented in C++, Java, etc, with the term OO being hijacked.

<comment><USER4> > Not to mention original OO idea by Alan Kay...

i was kind of curious about this statement, so i looked up the history of programming languages ([http://cdn.oreillystatic.com/news/graphics/prog_lang_poster....](http://cdn.oreillystatic.com/news/graphics/prog_lang_poster.pdf)).

if you take a look, it would seem to _suggest_ that smalltalk borrows from both simula-67 and lisp. wikipedia page for simula-67 suggest that it (simula-67) "introduced objects, classes, inheritance and subclasses, virtual procedures, coroutines and discrete event simulation, and features garbage collection..."

now it might be _just_ possible that simula-67 was the first language to incorporate those features in a language, and that alan-kay originally came up with that idea, waaay before simula-67 came into being.

<comment><USER5> No, I didn't come up with the idea before Simula -- but it did happen before Simula-67 (which doesn't matter at all here).

How it happened is well chronicled in the history paper I was asked to write by the ACM in 1992-3 "The Early History of Smalltalk" (i.e. why speculate when most high res answers are available online?). Ivan Sutherland's Sketchpad was the big first hit for me in 1966, and I saw the first Simula a week later.

Some of the confusion here is explained in the above link I wrote explaining that what is called "O-O" is nothing like I had in mind. The term was "colonized" because what we had been doing at Parc was powerful and we called it "object-oriented". But the "low-pass filter of O-O" was that Bjarne Strousrup decided to "do to C what had been done to Algol to make Simula". This was a perfectly reasonable idea. We were quite a bit more radical at Parc because we needed enormous amounts of expressability to invent personal computing (and we could and did design and build hardware that was matched to the radical ideas).

An interesting historical note is that the two inventors of Simula had completely different views of what they were doing and how it should be used for programming. Dahl was brilliant and conservative, and later wrote papers about using class definitions to make Abstract Data Types (and that is how a lot of so-called OOP programming is done today). Nygaard on the other hand was quite a wonderful wild man and visionary -- beyond brilliant -- and was into the abstract "simulate the meaningful structures" idea. Dahl was trying to fix the past and Nygaard was trying to invent the future.

During the 1978 HOPL conference time, we were visited at Parc at two different times, first by Dahl and Tony Hoare, to whom I showed and tried to explain Smalltalk: they didn't get it, and this was very frustrating. A few days later Nygaard showed up, and it was completely different: he got everything, and was finishing my sentences after 5 minutes!

Back to the origins in '66: besides the biological metaphors I had under my belt, I was also interested in the "virtual machines" ideas that were being used to do multi-processes and time-sharing in a safe way via hardware memory protection schemes (none of which I had had any involvement with inventing). One of the things that popped into my head while contemplating Sketchpad and Simula was that it would be just incredibly good -- and a huge improvement in systems designs -- to be able to use protected processes as the sole building blocks communicating only by messages that were not commands, but only "suggestions".

I think I'd call this not an invention, but a "realization" \-- that the recursive machine idea was already around, and what it lacked was scalability downwards, so that all entities could be "protected virtual machines". A lot of what I now have to call "real OOP" turned out to be some years of software engineering in order to create a practical systems material that could scale in all directions.

<comment><USER6> I had no idea that Dahl and Nygaard ever visited you at PARC, that's fascinating. Growing up in Norway and learning programming in school, Simula was revered as a proud if distant national accomplishment, in an field where there weren't much else to be proud of (though this was also around the time when Norsk Data [1] collapsed, and people weren't really talking about how innovative they had been). I wish I had learned about Smalltalk back then; I didn't really look closely at it until I learned Objective-C.

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

<comment><USER2> "Throughout its history Norsk Data produced a long string of extremely innovative systems, with a disproportionately large number of world firsts."

Still seems like something worth being proud of. It just got sideswiped by the personal computer industry (a lot of things did).

<comment><USER6> Definitely. For example, not a lot of people know that Tim Berners-Lee developed his first hypertext system, ENQUIRE, an ND machine (the NORD-16 minicomputer running the operating system SINTRAN) [1].

[1] [http://history-computer.com/Internet/Maturing/Lee.html](http://history- computer.com/Internet/Maturing/Lee.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> My favorite thing about Erlang is that the syntax is so simple and terse. And none of it is optional. So its either necessary or it isn't there, and this saves me from a lot of ambiguity issues.

I also like that it practically reads like bulletpoints. There's no cruft or decoration around function definition or internal statements. I was even able to write my CV in Erlang after attemtping 3 other languages first (Elixir, Rust, C) and Erlang was the only one where it didn't look like a jumble of weird code and syntax, and was consumable by executives, engineers and headhunters alike.

My only wish would be that Erlang adopted Elixir's atom syntax, or that Elixir adopted Erlang's variable syntax, because then I could look at my code and know immediately at a glance what was a function, what was a Variable, and what was an :atom.

As it stands in Erlang atoms and functions look superficially the same, and in Elixir the functions and variables look the same.

<comment><USER2> I thought Erlang looked weirder than Elixir (to the extent that I was turned off until Elixir came along), but fortunately, both of our opinions are compatible as everything compiles down to BEAM and is interoperable :)

From a semantic persopective I've found that I almost automatically understand Erlang just from working with Elixir. Some things like OTP are pretty much identical. Plus you get "real" macros :)

<comment><USER8> Yeah good point, Elixir is not just Erlang with a different syntax. It has streams, macros and a few other nice things. I believe Jose Valim likes to emphasise that point as well.

Now I personally prefer Erlang's syntax. I like that it is different because I know semantically stuff behaves differently. I would be more confused and disturbed by it if it looked like Java for example. I also like the immutable variables aspect..

However at the end of the day I am very happy to see Elixir grow. It really has one of the friendliest and most welcoming community. It will hopefully bring more people to the BEAM VM ecosystem.

<comment><USER2> > I also like the immutable variables aspect.

Elixir has the same immutable variables. I don't know why this is such a misconception. Erlang conflates rebinding and reassignment, Elixir does not, and the tradeoffs seem to (overall) be better in Elixir's case. Here, read the language creators' explanation as to why that is, it's the best:

[http://blog.plataformatec.com.br/2016/01/comparing-elixir- an...](http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang- variables/)

Very succinct and (hopefully) puts this misconception to bed.

</comment></comment></comment></comment><comment><USER9> _Simple in the sense that there should be a small number of basic principles, if these are right then the language will be powerful but easy to comprehend and use. Small is good. This we managed to do._ \- this is what packer's mindset would never understand. Nature doesn't work the way they think Java should.

This, by the way, is the universal principle. As simple as possible, but right. People who studied viruses and molecular biology in general would understand.

The protein expression/DNA repair machinery is where one should look for insights. That world is everything-is-a-firstclass, pure-functional, strongly but dynamically typed (everything has its unique structure, which could be used as a type-tag) and even duck-typed (if something binds to a receptor it triggers an action), loosely coupled, asynchronous, timeless.

It should be easy to model cells and even organs in Erlang because it has been based on the right smallest possible set of basic principles, or, at least, close to it.

MIT Scheme sub-culture also has great insights about putting the right principles first. So were Smalltalk or Plan9 guys.

</comment><comment><USER10> I've been playing with Elixir on the side and have picked Elixir as my singular choice to migrate to after (or alongside) Python. Elixir/Phoenix looks like a true "upgrade" and I really hope someday I'm in a position at a company to initiate its adoption.

Unlike so many other newer technologies, even a new language like Elixir running on BEAM bytecode is technically more mature than Node or Go. I could make a very strong business case to adopt it within any organization.

And probably even end up making JVM based tech look like some sort of new upstart project.

</comment><comment><USER11> About this:

"Again our goal was to solve the problem, not design a language with a predefined set of primitives."

I have the sense that Scala has followed exactly the opposite approach.

<comment><USER12> But that's not necessarily a bad thing!

I took a language design class in collage, and Scala was a great learning language in that application.

<comment><USER4> > But that's not necessarily a bad thing!

hmm, i have a diametrically opposite opinion about it. languages (successful ones at least) are designed to solve a problem, not prove a point :)

for example, lisp, c etc. all came into being because the designers found nothing which would help them do whatever they were doing e.g. for lisp, describe an abstract notion of computation, and for 'c' write fairly low level code without dropping down to assembly etc.

if teaching 'language theory' etc. is the end goal of a language, and it's not an unworthy goal at all, probably more 'syntax free' languages e.g. oberon, scheme, lisp etc. might be better ?

[successful languages: imho, are the ones that have just stood the canonical 'test of time' and i would include only 3 here: fortran (blaspheme!), lisp and C]

<comment><USER13> You really would limit your definition of successful languages to only those three?

</comment></comment></comment></comment><comment><USER14> Interesting. I've worked with Akka heavily over the last 3 years and that was built borrowing many of Erlang's designs. I'm sort of suprised to see that the language was not built with the intent of implementing the actor model. Fault tolerance through supervision was introduced into the actor model here but the way that state can exist and is isolated for high concurrency systems makes the actor model very easy to build into and reason about in concurrent scenarios.

Akka's addition to the actor model - location transparency - takes the actor model a little further and coupled with Scala makes a really nice language and concurrency pairing. Akka has the actor model as a library added where Erlang has all of the qualities built into the language. I'd like to learn erlang still but the contribution of the Erlang/OTP team in building fault tolerance into the Actor model has been an incredibly important contribution. As highly concurrent applications are becoming the norm with multicore CPUs being everywhere, I can't see the actor model going away any time soon.

<comment><USER15> One difference is that Erlang's concurrency and error handling in the language is more basic than Akka's and does not directly provide fault-tolerance through supervision but does provide the primitives to implement. All of OTP is implemented in Erlang with these basic primitives. These primitives are actually very simple, the difficulty was getting the right set of simple primitives on which to build the rest.

Also I think you will find that a lot of features which are very similar of Akka's location transparency were built-in to the distribution mechanisms which are part of Erlang. We were at least thinking of distribution from a very early stage.

</comment></comment><comment><USER16> I don't have any experience with Erlang but on a side note Elixir is really an awesome language. Pattern matching is one of the neatest features I have ever used and I recommend anyone to try it out.

<comment><USER15> They got that from Erlang :-)

<comment><USER17> Who got it from elsewhere ;D

<comment><USER15> Who got it from elsewhere. ;-) The sequential part of Erlang is basically a simple functional language with nothing really unique, except maybe for binaries. It is the concurrency and error handling where the really good bits are.

<comment><USER18> Who did it come from? Haskell? ML?

<comment><USER4> according to wikipedia ([https://en.wikipedia.org/wiki/Pattern_matching](https://en.wikipedia.org/wiki/Pattern_matching)) SNOBOL in '62

<comment><USER19> SNOBOL pattern matching is on strings; SASL is the origin of pattern matching on algebraic data types.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> For anyone interested in Erlang or Elixir, Virding has a great talk on the Erlang VM. It's a good look on how BEAM implements its concurrency. [https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be](https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be)

</comment><comment><USER21> Once you learn it.. It's very easy and basic. This is what happens when you choose the path less traveled.

</comment><comment><USER22> > If you seriously look at the Erlang syntax you will find it is very simple, > concise and consistent

You're serious and I'm not, gotcha. This adversarial attitude you assume, isn't helping. Work on that first.

> I know and have used about 9-10 so far so what is really the problem?

The problem is that you think it's trivial and other developers overwhelmingly don't. To be fair, it's only the first barrier to entry. After that you learn the sad state of Erlang data structures and expected language interoperability.

<comment><USER23> jack9, isn't it a privilege to be able to interact with folks such as Robert Virding (one of the co-developers of the Erlang language)?

I know of few other forums where such interaction opportunities are offered.

The fruits of their labour impact our lives and the lives of millions of others implicitly every day.

Let us atleast be civil in our discourse.

I think they have done enough to earn some respect from us all regardless of our personal opinions on their work.

<comment><USER24> > jack9, isn't it a privilege to be able to interact with folks such as Robert > Virding (one of the co-developers of the Erlang language)?

Or, at least, people who take on such names on pseudonymous message boards.

</comment></comment></comment><comment><USER22> The "look" of Erlang (and Elixir didn't really address this) isn't about the primitives, but about the surrounding syntax and structures (records!). Nobody looks at Erlang and asks, wtf is an atom. They look at the horrible mess of the prolog structures and say "it's not worth it to learn" or worse, "let's just rewrite it".

Also, the link seems strangely mistitled.

<comment><USER15> If you seriously look at the Erlang syntax you will find it is very simple, concise and consistent. We wanted to keep it simple. Yes, it different from most OO languages, most functional languages look different, but that is not surprising as the semantics of Erlang and other functional languages are very different from the semantics of your typical OO and imperative languages like Jave, Ruby and C. If it is doing different things why should it look the same? That would just be confusing.

Also, if you again look seriously at the syntax you will see there is actually very little Prolog in it, most of that disappeared along the way when it became functional. What is left are variables, atoms and lists. Records are a bit messy although they are very logical and consistent (again) but no one has come up with an alternative that works. They also fit the language semantics.

Also I personally don't see the problem with learning another syntax. I know and have used about 9-10 so far so what is really the problem?

And I rather like Prolog syntax, it simple, concise, consistent and truly homoiconic though with operators.

<comment><USER25> >> And I rather like Prolog syntax, it simple, concise, consistent and truly homoiconic though with operators.

I first got interested in Erlang because of its Prolog-like syntax. I was a little bit disappointed when I realised it doesn't actually use unification. That would have been a great feature- why was it left out of the language, I wonder?

<comment><USER15> It was originally in the original Erlang interpreter written in Prolog but you could use it for back-doors in the communication so we removed them. If you sent an unbound variable in a message then the receiving process could reply by binding the variable. We wanted all communication to be explicit.

I agree though that unification is cool. And I still like Prolog and other logic languages, and have implemented Prolog in Erlang, of course.

We also gave some thought to laziness but felt it just didn't fit as for the type problems in which we were interested. For those problems _when_ things are done is critical, not just that they are eventually done. That would have meant a lot explicit evaluation which defeated the point of laziness.</comment></comment></comment></comment>


Chrome to force .dev domains to HTTPS via preloaded HSTS - <AUTHOR> https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ <comment><USER2> .test is an official IANA reserved special-use domain name that will never be delegated out. Use it. Problem solved.

I don't know why people thought they could start using random TLD's on their own, there was always the risk they could be delegated officially.

[https://www.iana.org/assignments/special-use-domain- names/sp...](https://www.iana.org/assignments/special-use-domain- names/special-use-domain-names.xhtml)

<comment><USER3> > I don't know why people thought they could start using random TLD's on their > own, there was always the risk they could be delegated officially.

If a company has its own internal network with its own DNS, does it still need to conform to ICANN's name assignments? I thought it doesn't...?

<comment><USER4> You're free to do whatever you want on your local network. If you have collisions with resources on the global Internet, however, and you local network is connected to the Internet, them you're setting yourself up for problems. Hence why it's a best practice to not do that.

<comment><USER5> Except for things like this issue, where you'd be affected when using Chrome or Firefox - even if your local network were completely disconnected from the internet.

<comment><USER4> Chrome and Firefox are primarily designed for use on the World Wide Web. If you're going to use a locally modified network you may need to use locally modified browsers as well, just as you'll need your locally configured DNS.

<comment><USER3> > If you're going to use a locally modified network

Except (correct me if I'm wrong), this is not a "modified network", it can be another disconnected network that's just as "correct" in the standard conformance aspect as the Internet. It's more like Chrome is "modified" to support one network better than others - or rather, to possibly break on other networks.

In fact, it seems to me like the very idea of HSTS preload list isn't friendly with UAs working on multiple separate networks.

But yeah, you're right that this is what they are designed for after all. (I'm also probably slightly biased, since some of our test environments use .dev domain in our LAN.)

<comment><USER4> Chrome is primarily an Internet browser though, not a random network browser. It wouldn't be a good idea to prioritize random network browsing at the expense of useful security features to secure browsing on the Internet.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> Hey everyone. I'm the Tech Lead of Google Registry and I'm the one behind this (and likely future) additions to the HSTS preload list. I might be able to answer some questions people have.

But to pre-emptively answer the most likely question: We see HTTPS everywhere as being fundamental to improving security of the Web. Ideally all websites everywhere would use HTTPS, but there's decades of inertia of that not being the case. HSTS is one tool to help nudge things towards an HTTPS everywhere future, which has really only become possible in the last few years thanks to the likes of Let's Encrypt.

<comment><USER6> One of greatest things about the Web is how easy it is to write HTTP clients and servers. I see why HTTPS everywhere would be helpful, but I also think it would be a shame to lose this simplicity. Has there been any thought put toward simpler alternatives to HTTP+TLS?

<comment><USER4> That's way outside my area of expertise. I don't think HTTPS is that bad anymore, not now that certificates are easy to obtain. What are your biggest pain points?

More broadly, I think it's worth incurring some inconvenience for the sake of security. Go too far in the other direction and you end up like Equifax.

<comment><USER7> I think he's just wistfully hoping for a return to simpler times, when it was easy to construct your own HTTP server, just using sockets APIs.

<comment><USER4> Security's complicated, is the real answer :/

But you can't exactly just skip it (witness Equifax).

</comment></comment></comment></comment></comment><comment><USER8> Use .localhost pointing at 127.0.0.1 for local development. It is reserved for this purpose and obvious to everyone unlike .test.

For reference your options are:

                       .test
                    .example
                    .invalid
                  .localhost

[https://tools.ietf.org/html/rfc2606](https://tools.ietf.org/html/rfc2606)

With only .localhost fitting the purpose of most people's usage of .dev.

<comment><USER9> So what if I want to test a website under development from my phone? .test is more correct.

<comment><USER10> This sounds like a really useful thing to do. How do you set something like this up in a dev environment?

<comment><USER11> If you use Chrome and have an Android device which also has Chrome installed, you could check out this tutorial: [https://developers.google.com/web/tools/chrome- devtools/remo...](https://developers.google.com/web/tools/chrome- devtools/remote-debugging/)

</comment></comment></comment></comment><comment><USER12> Just commented over at Matthias' blog, I'll just copy-paste it here:

First of all I think this is generally a good move. If people use random TLDs for testing then that's just bad practice and should be considered broken anyway.

But second I think using local host names should be considered a bad practice anyway, whether it's reserved names like .test or arbitrary ones like .dev. The reason is that you can't get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that's messy and complicated.

Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don't want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I'd say you just shouldn't consider hostnames to be a secret.)

<comment><USER13> I've been wanting to experiment with something like this for my own dev environments for a while, and have been eagerly awaiting wildcard cert support from Let's Encrypt.

One thing I'm not quite sure about is if this means we need to be using the same wildcard cert for both dev and prod? I don't suppose the cert can be considered valid by the browser if otherwise?

If that's the case, I'm wondering if there are any best practices around securely distributing valid production certificates to dev machines across a team and keeping them up-to-date with Let's Encrypt's auto renewing mechanism? Ideally in a way that's transparent to each individual developer? I'm guessing committing them directly into a repo is probably a bad idea, especially for open source projects.

<comment><USER14> You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production service.

<comment><USER15> To go further on this though, wildcards usually only allow one "level" of wildcarding. so if you had a wildcard cert for *.internal.domain.com no one could use it to impersonate www.domain.com (which is good, you should consider a cert that every developer has on their machine not trustworthy)

<comment><USER13> Thanks for the clarifications. This is all starting to make a lot more sense now.

Though I'm still curious how people usually distribute a cert like that internally and update it to keep it in sync with Let's Encrypt automatic renewal mechanism?

As far as I understand, Let's Encrypt requires a public facing web server on the matching domain to renew certificates, so we'd have to actually set up a server solely for the purpose of certificate renewal on a 2-levels deep subdomain, expose it to the public internet, and then propagate the updated certs from that server into every dev machine every time a renewal is triggered?

It sounds like there's little security risk with this approach as long as we use a wildcard cert at least 2-levels deep as you've described, as we don't have to trust this cert for real production traffic at the root domain. But I'm still wondering if there's some tooling I could adopt to streamline this process a bit? Or should I just bite the bullet and script it all myself?

<comment><USER16> You can issue/renew via DNS. I have a bunch of valid certs for domains that only resolve internally using this method. I believe the plan for wildcard certs is to only support DNS-01 challenges.

<comment><USER13> Awesome. Renewing via DNS sounds like exactly what I need. Thanks!

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> They should do the opposite. There should be a .insecure domain where browsers accept HTTP or HTTPS with wrong or no certs, and pretend it is HTTPS with all consequences (e.g. loading of HTTPS third party resources). I wouldn't put it on the open net, but rather let people set it up internally for testing.

</comment><comment><USER18> Just as a note; .dev is not _yet_ an official TLD, it's on the status "proposed" which means that google is basically the highest priority on the waiting list.

.foo is delegated and thusly a full TLD, yes.

On the other hand, you should not be using .localhost if the target is not running on your loopback interface, resolving localhost to anything but loopback is considered harmful.

I find .test or .intranet to be more useful for such installations, they are either designated as "cannot be a TLD" or are very very unlikely to become a TLD, respectively.

<comment><USER19> I think you are wrong:

* DEV is listed on the "delegated strings" page of ICANN[0]

* `dig dev. ns +short` returns a couple of nameservers, the one of Charleston Road Registry: Google's registry.

[0]: [https://newgtlds.icann.org/en/program-status/delegated- strin...](https://newgtlds.icann.org/en/program-status/delegated-strings)

<comment><USER18> [https://icannwiki.org/.dev](https://icannwiki.org/.dev)

The ICANN Wiki specifically lists the .dev domain as proposed, not delegated. Which means they can also just kill it and Google won't have it.

<comment><USER20> Who do you want to trust more, the DNS root servers or a wiki (which might be outdated, because "This page was last modified on 1 August 2014, at 10:04"). Is the wiki even ran by ICANN, given it's on a separate domain, or by a separate entity or volunteers?

<comment><USER18> Then I might be wrong, yes.

</comment></comment></comment></comment></comment><comment><USER21> For my development needs, I try to either:

* Publish mDNS records to give myself extra `.local` names, or * Get a wildcard published in the organisation's internal DNS

If you can't do either of those, _please_ use `.test` as your test TLD, as it's explicitly set aside for that purpose so you know you're never going to collide with anyone.

[https://tools.ietf.org/html/rfc2606#page-2](https://tools.ietf.org/html/rfc2606#page-2)

<comment><USER22> I would recommend against funky things on .local. It's not a great idea either. I recommend just using a subdomain on a TLD you control.

<comment><USER23> What's funky about .local? It's an officially-registered special-use domain:

[https://tools.ietf.org/html/rfc6762](https://tools.ietf.org/html/rfc6762)

<comment><USER24> The .local TLD is reserved for mDNS requests, as the RFC states?

</comment></comment></comment></comment><comment><USER5> The article mentions as workaround:

 _That means your local development machine needs to;

\- Be able to serve HTTPs

\- Have self-signed certificates in place to handle that

\- You'll have to click through the annoying unsecure site window every time

Such fun._

Part of HSTS is the requirement that certificate warnings become unskippable. So the above wouldn't work - you'll need an actual CA-signed certificate that is accepted by the browser, otherwise, you won't be able to access the site.

<comment><USER25> Or don't use .dev and use .test or .localhost instead. Those were reserved by rfc2606 for such purposes nearly two decades ago.

</comment></comment><comment><USER26> This is perfect and great. I'd love to see gradually (yes, GRADUALLY, without breaking anything!) all TLDs do this.

".localhost" has existed and been popular for local development for MANY years. I've no idea why somebody would use `.dev, but now that it's a registered TLD, using it locally is just asking for trouble.

Also, you can just use 127.0.0.1, 127.0.0.2, 127.0.0.3, etc.

<comment><USER27> You can't show your app build to other people on the same LAN if you use .localhost.

(Well _technically_ you can, but it would be confusing ;)

</comment></comment><comment><USER28> Another option is not using Chrome as the main dev browser. Firefox replaces it just fine.

<comment><USER29> Web developers test their code in all the browsers their audience use. Switching to a different browser isn't a solution. This isn't about what we use for personal web use.

<comment><USER28> This is why I said __main __. Most webdevs don 't continously test in each browser they target, they usually just use Chrome and then check if things break in other browsers. And some don't even check at all.

<comment><USER29> It makes me a little sad that there are still devs who haven't discovered the magic of [https://www.browsersync.io/](https://www.browsersync.io/)

</comment></comment></comment></comment><comment><USER30> With all the hacks that people have put in place for using .dev locally, who in their right mind would want to even register and use a .dev domain? :P

<comment><USER31> As a developer, I never used .dev for development and I don't know anyone who does. The number of developers around the world is a small percentage of all users, let alone if not all of them have this redirect. And those who do probably use /etc/hosts, so your specific host needs to be in there (since the hosts file does, unfortunately, not do wildcards)... yeah, I think people are not going to have any second thoughts registering .dev domains.

<comment><USER32> Basecamps open source project POW ([http://pow.cx](http://pow.cx)), specifically configures rails projects to be automatically available at projectname.dev

From the homepage "That's it! Your app will be up and running at [http://myapp.dev/](http://myapp.dev/). See the user's manual for more information."

I'm sure basecamp won't love this change and I'd guess many rails devs won't like this either.

<comment><USER33> Let's hope this issue gets some traction: [https://github.com/basecamp/pow/issues/545](https://github.com/basecamp/pow/issues/545)

It's a bit unnerving that the project hasn't seen an update since 2014, and has 100 open issues.

</comment></comment></comment></comment><comment><USER34> I've never used .dev - but going back five or six years we set up a .dev sub domain of our domain and use that exclusively for development.

dev.ourdomain.net is a web-accessible server on our local network, configured as the dns server for that sub domain and is our internal CA trusted to issue the certs we use for development.

</comment><comment><USER35> We have always used local.{site}.com as a sub domain rather than tld. Makes CORS rules simpler, and we actually have a real dns record pointing to 127.0.0.1 so we don't have to bother with HOSTS

</comment><comment><USER36> With .test thrown around a lot, would there be any complementary support from browser vendors for that TLD to be specifically a development tld? localhost is recognised to be one by chrome for example, that's the only domain where html5 geo api works without https, and "your passwords are transferred via plain text" is not displayed. In order to help shift to .test google might alter it's heuristics to recognise .test as a common tld used for development.

<comment><USER23> From [https://tools.ietf.org/html/rfc6761#section-6.2](https://tools.ietf.org/html/rfc6761#section-6.2) :

 _Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names._

</comment></comment><comment><USER37> The main issue here is how much of a PITA it is to work with HTTPS locally (totally true that .dev is the wrong thing to use for dev boxes here). Self signing certs and forcing /etc/resolver/ configs is only half of it. Then you run into trouble with mobile emulators, proxying, etcetc.

We have an automated setup of it for devs, but it's out of necessity rather than anything else. It's a pain to deal with.

</comment><comment><USER29> I don't really see this as a problem. In fact, I wish Chrome would do that for _every_ gTLD, but obviously that's not going to happen any time soon. Secure by default would be great.

The real issue (for me at least) is that it's far too much of a pain to run an SSL secured site locally. It can be done, but doesn't work well across teams given you need to register your certificates locally. Being able to serve a site from a Vagrant box or a Docker container over https in a way that a browser will accept (or even just pretend to accept) would be immensely helpful. I'm sure web developers and browser vendors are trying to resolve the problem already, but it can't come soon enough in my opinion.

</comment><comment><USER38> *.localhost is a cool idea, would be cool if it allowed self-signed certificates as valid, or even have the browser do some magic and pretended it had an ssl certificate.

</comment><comment><USER39>
      Sorry for top-leveling a grand-child comment, but reading between
      the lines, this is the attack vector:

      > And for the last question: Again, there are no .dev domain
      > names. There never have been. It's never been available for
      > registration. The recommendation for a long time has been to
      > only use either (a) domain names that you actually own, or (b)
      > domain names that are reserved for testing and are guaranteed
      > never to exist a la RFC 2606. Using domain names for testing
      > that don't yet exist but could in the future is a huge security
      > hole that you must fix now. Do it now while the domain names
      > still fail to resolve. Once they resolve, and you don't own
      > them, then your security situation gets a lot worse.

      Google is concerned with nation-state attacks.  This means they
      have to assume ninja-assassin-scuba-divers have tapped all their
      cables underground.  They're also concerned about
      ninja-assassin-usb-stick-droppers, and all kinds of other use
      cases.

      What they're doing is:

      1) Requiring *.dev to match PRE-LOADED HSTS certs.  This allows
      google to "safely" boot up a computer from scratch.  Just so long
      as "clone-a-computer-from-scratch.dev" matches  the
      public/private handshake for HSTS/HTTPS then google knows that no
      MITM, no nation state DNS takeover, etc. is possible.

      So long as the VERY FIRST CONTACT WITH THE INTERNET is a *.dev
      domain, then that computer can be "as secure as possibly known".

      2) Forcing people to bounce "off" of invalid TLD's as a network
      administration method.

      Remember, google is concerned about nation states.  Remember
      wanna-cry?  How it was disabled by some random researcher
      registering xyz-abc-123.com?

      That attack costs $15.  Now imagine a nation-state, intentionally
      registering a gTLD of "\*.haha-now-your-company-infra-is-pwnd"
      which they somehow glean is the gTLD your developers use for
      local development / testing / intranet portal.

      If you could spoof IBM's intranet by doing something like:
      "http://www.welcome.ibm" or "https://www.welcome.ibm" (b/c the
      *.ibm wasn't cert-pinned.....) then you could trivially cause
      *.ibm to resolve to some sort of spoofed site to collect
      passwords.  Or what if they're catching `mysql -uroot -pxyz
      staging.product.ibm`?  Whoops.

      Or... perhaps another gTLD we'll see google register is "*.go" or
      maybe their internal builds of chrome already do cert-pinning on
      that.  (Reason is I've seen/heard they allow
      'http://go/my-internal-shortlink' ... I know that other tech
      companies have had similar setups).

      Same attack vector.  You control the DNS, you control ALL
      responses. And when somebody types www.microsoft.com, it may be
      _impossible_ to know if that "Down for Maintenance" banner is
      real or fake if their DNS is controlled by somebody who really is
      your enemy.

<comment><USER40> FYI your comment is unreadable: [https://pasteboard.co/GKOcbiR.png](https://pasteboard.co/GKOcbiR.png)

There is something about how you've formatted it that requires unreasonable side-to-side scrolling.

<comment><USER39> Unfortunately n.y.c can fund billion dollar startups, but can't let you put STAR DOT EYE BEE EMM in a discussion about domain names. ¯\\_(ツ)_/¯

</comment></comment></comment><comment><USER41> I test with HTTP, locally.

This forcing of opinionated things goes on my nerves. How about develop the browser, and let the mass decide what they use. Amazon was 100% HTTP for 20 years (except the single login page) - it worked very well.

<comment><USER42> Same here. Time to check out firefox :)

<comment><USER43> Mozilla uses Chrome's HSTS preload list. (Microsoft too.)

<comment><USER44> I've never quite understood the preload list. Is its only job to save the initial 301 redirect from http > https on first load?

Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use?

I'm sure I must be missing something, because this doesn't seem very logical to me.

<comment><USER45> In a way yes, it's trying to avoid the initial redirect. But not in order to save you from the potential latency of the initial redirect:

> These sites do not depend on the issuing of the HSTS response header to > enforce the policy, instead the browser is aleady aware that the host > requires the use of SSL/TLS before any connection or communication even > takes place. This removes the opportunity an attacker has to intercept and > tamper with redirects that take place over HTTP.

Read this: [https://scotthelme.co.uk/hsts- preloading/](https://scotthelme.co.uk/hsts-preloading/)

> Also, wouldn't bundling (tens of) thousands of domains start to add up, and > slow down first page load for regular browser use?

Why would it? Checking in a data structure if the domain the user requested should be loaded over HTTPS can be done in a perfectly efficient way. A hash table would give you O(1) lookup times on average and there's other things you can use to mitigate the worst case lookup of O(n).

<comment><USER44> Good answer, thanks.

I was hoping the article would cover the scaling aspect a bit more. I guess it's just meant to be a mid-step towards browsers defaulting to HTTPS at some unknown point in the future.

<comment><USER43> The maintainer of the HSTS preload list wrote a detailed report on the current state of HSTS preloading last year, covering the list size aspect[1].

[1]: [https://docs.google.com/document/d/1LqpwT2aAekrWPtLui5GYdHSG...](https://docs.google.com/document/d/1LqpwT2aAekrWPtLui5GYdHSGlZNMNRYmPR14NXMRsQ4/edit#)

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> The most annoying part here is that Google isn't even using .dev as public TLD – they purely use it for internal testing, and all registered .dev domains resolve to 127.x.x.x addresses.

.dev should have been entirely reserved, or made available publicly. Registering a TLD just for your own internal testing, and forcing everyone to switch away, is the most user unfriendly move you can do.

<comment><USER4> We're not using it for internal testing.

And specifically, the wildcard DNS entry for 127.0.53.53 is for ICANN's Controlled Interruption process. See here: [https://www.icann.org/resources/pages/name-collision-ro- faqs...](https://www.icann.org/resources/pages/name-collision-ro- faqs-2014-08-01-en)

<comment><USER46> So, why is this not documented with the TLD, or in any of the informational material?

(And why is Google in the TLD market at all? Google's already far too large as company – impossible to democratically control, any further growth of Google should be immediately and forcefully stopped).</comment></comment></comment>


ShowHN : Code documentation following the spirit of literate programming - <AUTHOR> http://groc.co/ Grocco helps easily build documentation for your awesome code. It takes your documented code, and in an admission that people aren't machines, generates documentation that follows the spirit of literate programming. <comment><USER2> Sounds good , what does the actual codebase processing in the background , can you through some light on it !!

<comment><AUTHOR> Its built on an opensource project form github [https://github.com/nevir/groc](https://github.com/nevir/groc) , The application logic is written in django, Celery processes the queue of generating documentation.</comment></comment>


Ask HN: Has anyone taken money from family and had it totally backfire? - <AUTHOR>

We seem to always hear about success stories, especially where financing is concerned. I especially wonder about taking money from family and friends, a typical way to jumpstart a company. I know it's a sensitive subject, but I'd love to hear about the other side and what to watch out for. <comment><USER2> When you take money from family, you have to _feircly_ manage expectations. Your family may not quite grok what "investing in Junior's company" means. The most common mismanaged expectation is that it's a kind of loan and they expect to be paid back in relatively short order.

Even with family, put it in writing. And always be willing to sacrifice nearly everything to just "pay it back" if you want to prevent a potential permanent family schism.

</comment><comment><USER3> No, but I have lended money to friends and in so doing destroyed said friendships. I refuse to lend money to any entity but my own business as a result. Human beings are fundamentally untrustworthy in the absence of explicit contracts, when it involves money.</comment>


Computer Random vs. True Random : See the difference in how random numbers are generated. - <AUTHOR> http://www.boallen.com/random-numbers.html <comment><USER2> _it's obvious the PHP's rand() function is using the operating system's random number generator, because as the results from Window's are awful (the image doesn't change when re-running the script), the results from the Linux environment are far superior._

Chances are, the Windows version not changing is a feature, not a bug. Random number generators require a seed. The same seed always provides the same stream of pseudo-random numbers. This is useful if you're, say, debugging a simulation that depends on pseudo-random numbers.

I don't do Windows system programming, but I'll be there's a way to change the seed, and then change the stream of numbers. So, I find it more likely that the people who implemented php on Windows were using the generator incorrectly, if the intention was different number streams.

<comment><USER3> This is exactly right. The windows implementation of ANSI C89 rand() was done with a 16 bit linear congruential generator back in the win16 days, and left unchanged for compatibility reasons. It's really not an insane choice on their part. Lots of applications really do rely on PRNG repeatability, and you wouldn't want a platform upgrade to interfere with that.

The real lesson is that applications with solid randomness requirements need to be relying on their own generators (there are lots to choose from) or an OS-supplied RNG (e.g. /dev/urandom) and not ANSI C, which is underspecified.

</comment></comment><comment><USER4> Pay close attention to the bit about being generated on a WAMP system. This is clearly an issue with PHP using a faulty random-number generator on the Windows platform, and not a general fault that necessarily exists in _all_ programming languages' random number generators. (Just for the record: Windows has a number of random number generator functions in its cryptographic libraries, some of which are on-par with those that ship with *nix. It's just that PHP on Windows isn't using them the right way)

<comment><USER5> Yes, glibc in particular uses a very nice PRNG with 992 bits of internal state and good randomness of high and low bits, though it is not cryptographically strong like /dev/urandom. I don't know what one gets on Windows, but from the graph it looks like it's got some tricky squaring thing in it that turns out not to be very good.

</comment></comment><comment><USER6> "There are some tricks to improve the randomness of the computer generated numbers... For instance, you could have the program sleep for a randomly generated amount of milliseconds before grabbing the next random number... or add, subtract, divide, and multiply the random numbers with other random numbers."

I'm no PRNG expert but I think I read somewhere that those techniques wouldn't significantly improve the quality of pseudo-randomness, if at all. You can't mix 2 bad wines to get a good one.

<comment><USER7> If you just want a PRNG for a game, then sending the output of a bad PRNG through a hash function like MD5 will almost always give you good results. That would've been better advice. Also, the mouse is a readily available source of randomness which can also suffice for a game. As far as PRNGs for cryptographic purposes, that's something else entirely.

(By conincidence, I am going to be writing a game which uses cryptographically secure algorithms to generate random numbers for a procedurally generated game world. (A Galaxy of 400 Billion Stars!)

<comment><USER7> If the PRNG is really bad, then even this won't work. But PRNGs _that_ bad are generally deliberately made that bad.

</comment></comment></comment><comment><USER8> Is there really anything that is truly random? I've always wondered about this. If you define random as meaning "when rand() is called many times in a row, you will most probably get a different number each time" then both the Perl function and random.org are random, but to different extents.

But if you define random to mean something like "caused by unexplained or mysterious forces" or "non-deterministic", then how can anything in the universe be truly random? Even atmospheric noise is created by a sequence of deterministic events, right?

A dice roll is too (brain fires synapse, I move my hand forward and release the dice, dice interact with air in certain way, dice hit table and F=ma predicts their movements, etc...). Maybe since we don't have the facilities yet to watch a person throw some dice and predict what the outcome will be, this process is non-deterministic simply because we lack the technology to sketch it out. But with sufficient technology to scan the situation and chart the end result of the dice roll based on the initial conditions, doesn't the process become completely deterministic, and not random?

But maybe I'm just stretching the definition of random to mean something that it was never meant to mean.

<comment><USER9> You are in a state of sin :-) Don't talk about random sequences, talk about random generators. There's an unambiguous definition of "true random number generator" in terms of probabilities, joint probabilities etc., but there's no way to determine if a given string of numbers is random, and in fact no definition of a "random string of numbers" other than "the output of a random number generator".

<comment><USER10> I am reminded of Borges's "Pierre Menard, Author of the Quixote" (<http://www.coldbacon.com/writing/borges-quixote.html>) (and what do you know, Borges even slips George Boole into it).

"He did not want to compose another Quixote —which is easy— but the Quixote itself. Needless to say, he never contemplated a mechanical transcription of the original; he did not propose to copy it. His admirable intention was to produce a few pages which would coincide—word for word and line for line—with those of Miguel de Cervantes."

</comment></comment></comment><comment><USER7> A more informed and informative source on the subject:

[http://www.schneier.com/blog/archives/2006/06/random_number_...](http://www.schneier.com/blog/archives/2006/06/random_number_g.html)

</comment><comment><USER11> People have been generating this kind of graph of years, often with more meaningful techniques. For example, you can get another dimension of information by looking at the difference between one number and the last one generated, and plotting it on the z- or color axis.

<comment><USER12> However, even that isn't enough to measure true randomness. What this article doesn't mention is that you quickly run into trouble trying to visualise non- random behaviour in RNGs. At the higher end, the analysis isn't quite so easy.

<comment><USER11> Yeah, you need actual math to get anywhere. The pictures are mostly for prettiness and visual proof of non-randomness. But even with math you aren't measuring "true randomness". The best you can do is to confirm statistical properties that random information would also have. It's impossible to tell in general whether a string is "true randomness" or, say, a sequence of bits from pi.

<comment><USER13> FFT and Chi-square tests, simple bits/bytes distributions are all more interesting tests probably but actually a good generator will pass all this tests while being predictable. The only way to check if a PRNG is of cryptographically use is to analyze the way and sources used to generate the output.

</comment></comment></comment></comment><comment><USER14> As the author points out, php's rand function is garbage on some systems. mt_rand (based on the Mersenne twister) has been the suggested replacement for many years; it's built in, fast, and consistent across platforms.

<comment><USER15> Indeed, the first thing I thought was "hey that's PHP! Oh, did he just use rand()?" It ought to be common knowledge in the PHP world that you always use mt_rand().

On OSX, the results aren't very noticeable, probably because the underlying libs are higher quality than Windows, but mt_rand() definitely produces something comparable to his random.org image.

Not sure why rand() isn't simply replaced with mt_rand() under the hood, since improving randomness will hardly break b/c... Maybe PHP9 will have that ;)

</comment></comment><comment><USER16> Any reputable gaming site uses an Intel hardware random number generator.

</comment><comment><USER17> It's an interesting article and comparison, but (in general) I think people tend to obsess a bit too much over "true" randomness. I am not worried about my random dice having a _seemingly_ repetitive pattern. If I am flipping a coin or even rolling dice, I might observe certain reoccurring patterns in the results of the coin flip -- perhaps out of sheer randomness.

<comment><USER11> The right question to ask is whether a source is random enough for your purposes. The weaker source might be ok for a game, but the patterns in the visualization were certainly not caused by chance. That level of predictability would not be ok for crypto.

<comment><USER18> Games are surprisingly demanding when it comes to random number generation. Especially in the realm of computer graphics, the human brain is excellent at picking out underlying patterns which can result from insufficiently random data. Even with a good generator, mishandling of the results can ruin things easily.

</comment></comment></comment><comment><USER19> For comparison:

rand() on Linux: <http://www.therealnewsfeed.com/randimg.php?fn=rand>

mt_rand() on Linux: <http://www.therealnewsfeed.com/randimg.php?fn=mt_rand>

To me, at least, these are pretty indistinguishable from the "true random" image, so it seems like the bigger issue here is the faulty rand() on Windows.

</comment><comment><USER20> Excellent visualization!

It would appear that there is some kind of flaw in the pseudo-random generator used, since once can see definite patterns in the output.

<comment><USER21> Yeah, you can see it has a small period from the presence of a repeated pattern. I think if he had used the Mersenne twister algorithm the output would be indistinguishable.

<comment><USER20> That would be a cool project-- to compare the patterns for various pseudo- random number generator algorithms...

</comment></comment></comment><comment><USER22> Couldn't you see the grid in the first one? It's in the middle, you can tell by the density. There are 9 sectors in it.</comment>


The 7 Habits of Highly Effective Developers - <AUTHOR> http://blogs.msdn.com/johnwpowell/archive/2008/05/22/the-7-habits-of-highly-effective-developers.aspx <comment><USER2> "If You Don't Know the Answer, Know Someone Who Does" - with google around everyone "knows someone who does" :)

<comment><USER3> I know you are saying it tongue-in-cheek, but you still need to have a decent amount of knowledge of the domain in order to craft a good query and be able to separate the wheat from the chaff.

<comment><USER4> In some limit cases, that's true, but I've literally heard the following two questions asked in the last week (one directly to me, one in the same room I was in; these are not FoF cases):

What is SCOM? What is MRTG?

In both cases, knowing nothing about the domain gets you exactly the answer you want. I think far more often than it doesn't, a relatively naive query to Google with a followup query or two with certain words excluded will get you what you need.

</comment></comment></comment><comment><USER5> I thought this was a bit of a puff piece.</comment>