Linux Namespaces and Go Don't Mix - <AUTHOR> https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix <comment><USER2> Author of the go netlink library here. I've run into this issue a number of times. There has been conversation in the past about adding some kind of new runtime command like LockOSThread to prevent new threads from being spawned, but it didn't gain any momentum.

Even though I am a big fan of go, I've personally built two container runtimes in other languages do to the namespace clumsiness.

Personally, I think rust is an excellent alternative for namespace utilities.

EDIT: there is more information and links in the issue in the netns library: [https://github.com/vishvananda/netns/issues/17](https://github.com/vishvananda/netns/issues/17)

<comment><USER3> >" I've personally built two container runtimes in other languages do to the namespace clumsiness."

Can you share any details on those other container runtimes?

<comment><USER2> One was a simplified runtime in c, similar to a stripped down version of systemd-nspawn. I can hopefully share the other one in a few weeks. I'm going through an open source approval process for it.

<comment><USER3> Thanks. It's an interesting topic. I hope you post it on HN then.

</comment></comment></comment></comment><comment><USER4> I think the proper title is: Linux Process and Threads Don't Mix.

The Linux syscall interface exposes certain functionalities that are much more easy to reason about at the process level such as namespaces, capabilities, seteuid and so on. However these syscalls all operate on the thread level (since the kernel treats threads pretty similarly to processes). Therefore in order to perform these operations safely you need some sort of process wide mechanism to apply the operation on every thread (and don't forget error handling!)

This is _not_ just a golang problem or an M:N threading problem as many comments suggest. The kernel really needs to provide new syscalls for these features that operate at the process / thread-group level. The current syscalls are extremely difficult to use correctly in any multithreaded context in any language. When you consider the security implications of these features it makes the problem even worse.

Check out [https://ewontfix.com/17/](https://ewontfix.com/17/) for a really good analysis of the difficulty musl libc has faced making a multi-thread safe seteuid on Linux. There are also many bugs in glibc related to this as well. Linux makes userspace responsible for patching up the leaks in the kernel's process abstraction and that's really not a job that userspace is in the right position to take on.

<comment><USER5> The M:N problem in Go is that you cannot control which thread runs which code. So yes, you could wish the OS exposed different APIs, but presently you can manage this situation in languages that let you manage threads.

<comment><USER6> The person you're replying to has already made that clear. It's, in fact, also possible to manage the problem in Go with some finagling. But like Go, if you have multiple threads, it's difficult

I've hit this exact problem with multithreading in C and setuid and just because it _can_ be managed in C doesn't make it easy or straightforward.

Therefore, I mirror the sentiment that there needs to be a way to operate on a process level, even if that has some interesting consequences.

(P.S.: In C, if you're using glibc, it DOES actually patch this issue up on its own using one hell of a nasty hack.)

<comment><USER7> > P.S.: In C, if you're using glibc, it DOES actually patch this issue up on > its own using one hell of a nasty hack.)

I too love reading the code for nptl(7). It's a riot. :D

</comment></comment></comment></comment><comment><USER8> This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows".

I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. I'm not saying one _should_ use Go for containers/namespaces programming, but a lot of people are with some success (probably also banging into the namespaces issue now and then), I'm just saying it's not obvious to me what the better alternative would be.

<comment><USER9> > I mean, what's the better alternative to Go for this work? Maybe Rust? It > is, at least more controllable at a lower level...but, not as easy to pick > up for people coming from a C/Python/Perl/Ruby systems and ops background.

You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowledge here and there when writing C extensions for my Python applications. I'm a fairly experienced programmer at this point. To the point:

I tried picking up Go one day because I was hearing so much about how it could replace Python as network glue code with better performance and reliable concurrency. I can't really validate or invalidate those claims. That said, I found Go to be sort of difficult. The syntax is really simple. Compiling is really simple. Concurrency is even simple. However, need to do something in a different way than Go decides is correct? Well, you can't. It won't even compile. The difficulty in Go is in learning about what the compiler thinks is OK. I don't really like that. You don't really know if your code will work until you compile. Basically, I just think Go isn't really flexible enough for modern programming. I find that Nim can do Go's job better than Go can for my use cases anyways.

<comment><USER10> Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now).

Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actually write software that makes them money.

<comment><USER9> > Yes but the problem with languages like Nim is lack of support and maturity.

Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning.

> Go is more versatile and at the same time more mature than anything out > there.

This is objectively incorrect. In fact, Go aims precisely to be non-versatile for the sake of simplicity. That is why Go does not have generics for instance.

> It is a different design and it excels in what it does (considering all > tradeoffs now)

I don't think it's design is all that different. It looks like a stripped down version of C and it's definitely not the first PL focused on concurrency.

> Will Nim be as versatile and solid as Go in the future?

Nim is already leagues above Go in the versatility(I assume you mean flexibility?) department. As far Nim being as "solid" as Go, I'm not entirely sure what you mean. If you're asking about stability, I believe that Nim can reach a similar level of stability as Go, yes.

> You need a solid financial backing and certain amount of adoption where > people actually write software that makes them money.

I agree with this. However, it's not always a quick process. The only reason Go is as popular as it is is because of Google's size and reputation(edited). Every programmer on Earth heard of Go within a few days of it's official release. Nim is taking a slow roll approach. Look at Python. It took almost 15 years before it started getting really popular.

All that said, I didn't come into this thread to argue about Go vs Nim. I've been accused of shilling Nim in the past. I'm sorry that I like talking about PLs I enjoy using.

<comment><USER11> It's more than fine to be enthusiastic about programming languages. However, some of your points about Go are dubious.

The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented.

I also don't believe Google's marketing budget contributed much if anything to supporting Go. The _reputation_ of Google and the Go authors was far more important. (Personally, when I saw people like Brad Fitzpatrick try Go and rave about it making programming fun again, I decided to try it.)

You can happily accuse me of shilling Go if you like :-)

<comment><USER9> No, I encourage you to shill in fact.

> The reasons Go doesn't (yet) have generics are practical rather than > philosophical. And well-documented.

Can you give an example? I guess I fail to understand why a statically typed language would choose to forgo all of the advantages generics provide. Does it have something to do with Goroutines?

> I also don't believe Google's marketing budget contributed much if anything > to supporting Go.

I didn't necessarily mean their marketing budget. I should probably edit that. I meant that anything they do is news.

<comment><USER11> > Can you give an example? I guess I fail to understand why a statically typed > language would choose to forgo all of the advantages generics provide. Does > it have something to do with Goroutines?

Like I said, the objections are practical, not philosophical:

They published four past design docs for generics in Go that simply didn't pass technical muster ([https://github.com/golang/proposal/blob/master/design/15292-...](https://github.com/golang/proposal/blob/master/design/15292-generics.md#proposal))

Also, rsc stated he plans to understand generics better in 2017: [https://research.swtch.com/go2017#generics](https://research.swtch.com/go2017#generics)

Also, bradfitz said recently on the GoTimeFM podcast that doing Generics and Go2 together makes sense.

> I didn't necessarily mean their marketing budget. I should probably edit > that. I meant that anything they do is news.

I feel like the comments from others about Dart give the lie to this one. Go is fantastically, dramatically, massively more popular than Dart, which is also from Google.

<comment><USER12> > Like I said, the objections are practical, not philosophical

Russ Cox and Rob Pike keep repeating this mantra, but I don't buy it. No, I don't believe they object the idea of generics itself. And yes, generics pose practical complexities and a plethora of issues that have to be resolved.

But so does every other language feature. The features you choose to add reflect your philosophical values and priorities.

Go chose to bake some hitherto very niche features that could have been as libraries into the language. Channels in particular, are a language construct only because Go doesn't allow operator overloading and generics for user types. But channels get them, because channels are demonstratively important for Rob Pike[1].

There's nothing wrong with that of course, but that's a philosophical decision. Why channels can avoid the vagaries of interface{} boxing, but not sets, linked lists or queues?

The reality is that every modern statically typed language except Go has generics, and they all implemented them very well. The ML languages and Ada were already doing it in the 80s, and OCaml and Eiffel managed to combine generics and polymorphism back in the 90s.

It seems to me that when originally designing Go, Pike, Griesemer and Thompson just didn't think generics are worthwhile enough for the effort it takes to properly research them.

When Go was started, its authors mostly looked to languages which implemented generics later in their lifecycle (namely Java and C++) and their implementations suffered from problems due to other, rather obvious, design defects: [https://research.swtch.com/generic](https://research.swtch.com/generic)

I'm happy to see that this attitude is changing, and other languages are looked at.

[1] [https://swtch.com/~rsc/thread/](https://swtch.com/~rsc/thread/)

<comment><USER11> > The reality is that every modern statically typed language except Go has > generics, and they all implemented them very well. The ML languages and Ada > were already doing it in the 80s, and OCaml and Eiffel managed to combine > generics and polymorphism back in the 90s.

> It seems to me that when originally designing Go, Pike, Griesemer and > Thompson just didn't think generics are worthwhile enough for the effort it > takes to properly research them.

Are you arguing that it's easy, and they just haven't done it? Or are you arguing that it wasn't important enough at first, and so the implementation developed in directions that preclude straightforward implementations now? I can believe the latter, but after reading the multiple, detailed proposals from Ian Lance Taylor, I don't believe the former.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> this is just a more complex version of the issue where go can't safely do the daemonize dance for a privileged port

<comment><USER14> There's a simple-ish workaround for the privileged port issue if you can't just use CAP_NET_ADMIN: [http://play.golang.org/p/dXBizm4xl3](http://play.golang.org/p/dXBizm4xl3)

The namespace issues are unfortunately a lot tougher to address.

<comment><USER15> It's only reliable if none of your dependencies are spawning goroutines during initialization. If this is the case, some goroutines (yours' or the dependencies') can end up with increased privileges.

<comment><USER14> The workaround functions by opening the privileged socket and re-executing the binary as an unprivileged user with access to the filehandle. Any background goroutines would exit with the privileged parent.

Also: please don't spawn goroutines during init(). There's generally a better time and place, and in the event that you justifiably need a package-level background routine you can spawn it on demand with a sync.Once.

</comment></comment></comment></comment><comment><USER16> I've ran into this problem before. IMO this issue has nothing to do with go and the solution is straightforward. Simply create a sub-process whenever entering a new namespace because the operation isn't concurrency safe within a process.

Note that you'd run into this bug within any multithreaded process, whether the code was written in go, Java, c, or whatever.

</comment><comment><USER17> This is discouraging considering go was initially designed as a systems programming language. I wonder if there is another way for go to handle blocking syscall such that this use case would become reliable.

<comment><USER18> I think Go was designed as a server programming language more than a systems programming language.

<comment><USER19> Go was retconned into this role, but originally it was marketed as a systems language.

</comment></comment></comment><comment><USER20> I read this crap in language design and despair. This is why C is my only recourse for systems programming in *nix environments.

<comment><USER21> This is what I cannot understand about Go: how did a newly-designed programming language end up as such a muddle?

<comment><USER22> Because this isn't really a language issue. It's an OS issue. Go assumes that all threads are equal and therefore any Goroutine can run on any thread and threads are all equal. Linux got late to the thread party and its threads are kind of like processes that haven't decided if they want to be processes or threads.

It's true the Go runtime could give users more control over goroutine and thread scheduling but that would kind of defeat the purpose of not needing to know about it and having Goroutines as the only flexible unit of concurrency.

I think the kludge here is on the Linux side. Having some magic properties bestowed upon threads doesn't make sense. The property should be accessible via a handle that can be shared amongst all threads.

<comment><USER23> >Go assumes that all threads are equal and therefore any Goroutine can run on any thread and threads are all equal

This isn't true in Linux or Windows so I don't see why Go would make this assumption other than poor design.

>The property should be accessible via a handle that can be shared amongst all threads.

It literally is. The namespace information is shared with all threads in a PID group globally available in the /proc fs.

\---

What OP is doing is effectively having 1 program run part of itself in 1 container, and another part outside of that container.

Go isn't a systems programming language so this level of fine grain control isn't possible. Hell its pretty difficult in a C/Rust/C++ environment.

<comment><USER22> What's an example of it not being true in Windows?

I think it's mostly true in Linux and the situations where it isn't true are subtle and require expert knowledge in some specific areas. It's not like there's a big sticker on Linux that says threads are generally not symmetric.

I get the bit of half the process being in one space and half in another. I just find it odd. Can half the process run as root and half the process run as another user? Maybe yes? Can a file be open in half the process and not open in the other?

At any rate, I think it's not black and white. Green threads do make sense in general and introducing different thread types and more granular control makes things more complicated.

I think you're missing my point about APIs and handles:

      handle = open_namespace("test")
      syscall(handle, "yes")

if handle can be used across threads then this sequence will run correctly regardless of what thread is executing it, it doesn't rely on anything bestowed on a thread.

(EDIT: thread local storage I guess is an example of asymmetry between threads but it's intentional/clear asymmetry designed for specific purposes and something you don't need to access in Go e.g. because you don't use threads directly).

<comment><USER24> Maybe your assumption of symmetry is just backwards? If you look at the clone syscall then threads are more akin to processes that just happen to share virtual memory and some other things such as IO priorities, file desciptor tables, cgroups, .... Many of those things can be shared individually. In other words they are considered orthogonal features that, when taken together, happen to function as threads.

</comment></comment></comment></comment></comment></comment><comment><USER25> alternate title: developers who don't understand user level threading don't understand user level threading.</comment>


Ask HN: Please AWS team, make links work with control-click - <AUTHOR> Hey AWS team,
If you are reading this, please please make CTRL-click to open a new page. It's really frustrating to try to open a link in a new page just to see that the page navigated, and then if you click the back button, you end up nowhere near where you were before.
I really love the new UI, it's really good! and with this feature we could be more productive and use AWS even more!! <comment><USER2> Websites breaking core functionality is mildly infuriating but Google Drive's desktop app disables CMD+C (copy to clipboard) on MacOS. And this is in a window whose _sole purpose_ is to provide a sharable link to the user.

You read that right. A "native" app over-riding core operating system functionality to prevent users performing the _very task the window is designed for_.

Let that sink in for a moment.

(Since the window is a webview you can see (and debug) the JS code doing it. They are aware of the problem but not interested in fixing it.)

</comment><comment><USER3> Please $SITE, stop breaking $BASIC_FUNCTIONALITY.

In Firefox, you can often avoid various hijacking by holding Shift.

<comment><USER4> or scrollclick in any browser.

<comment><USER5> But not any website :(

</comment></comment></comment><comment><USER6> I've seen this on a few sites, my suspicion is that it's caused by some kind of marketing analytics JavaScript that attempts to track clicks on outbound links by intercepting the click, logging the analytic event and then navigating to the destination using location.href=something.

Not sure what's causing it here - could be Marketo Munchkin perhaps?

<comment><USER7> It's probably more just that sites are using SPA frameworks that use onClicks in JS instead of hrefs in HTML. Can't control click a link that isn't a link, it's a span pretending to be a link.

<comment><USER8> In which case I wonder if the burden can be placed with the browser.

Control click on opens a new tab with identical state and executes the click there.

</comment></comment></comment><comment><USER9> Oh jesus, Today I was messing around with Athena and S3, very cool product btw. In the new s3 control panel, I was having the hardest time selecting the bucket and path I was on so I could copy it. Its 2017, wtf?

<comment><USER10> The new UI is uneccessary and incomplete. The old UI was a fine flat, plain design ala Goole. The new UI lacks many features of the old and feels more clunky; it should not have been enabled yet.

</comment></comment><comment><USER11> I just re-wrote some navigation on a single page app personal project and this post reminded me that I'd definitely broken this functionality. So, thanks very much!

For those with a similar problem, the fix is super easy: [https://github.com/marcusdarmstrong/mockdraftable- web/commit...](https://github.com/marcusdarmstrong/mockdraftable- web/commit/e88ebd36e0bd72389306323f94f9b09aabd2d30e)

</comment><comment><USER12> Ugh. Need a hall of shame for this.

Links are the essence of the web ( _H_ TML and _H_ TTP).

</comment><comment><USER13> I have this exact problem with Microsoft Azure as well. Changing pages always takes 5-10 seconds and you can't open in a new tab to open new tables concurrently. Makes working in their portal really inefficient.

<comment><USER14> Azure has probably the worst UI ever created...

</comment></comment><comment><USER15> AKA lol Angular. Curmudgeonly amusing that a team in charge of ads on the web builds a product that requires so much care to make something as basic as the link continue to work.

<comment><USER16> It's not difficult at all to write Angular apps where links can be opened in new tabs. I would imagine the same is true for all the major SPA frameworks.

</comment></comment><comment><USER17> Try right-click > open in new tab. Nobody traps right-click in JS :]

Yes, unbelievably annoying, but I've encountered this kind of behavior on a lot of websites.

<comment><USER18> An increasing number of websites force me to right-click to follow links; maybe JS can't trap it yet? In some places, the basic process to follow a link has become right-click, copy link, paste into text editor, filter URL through script to remove tracking crap, open new tab, paste result into URL bar.

Web 3.0, baby!

<comment><USER19> JS can trap right-click, at least in certain situations; for example, if you right-click in gmail, it brings up a HTML menu, not the OS-native one.

<comment><USER20> In this case, my current workaround is to duplicate the tab then continue from there.

</comment></comment></comment></comment><comment><USER21> It's JavaScript ruining the world

</comment><comment><USER22> Every UI for every product is managed independently by each product team, if you look at the source, some are angular, some are plain HTML and some are backbone.

</comment><comment><USER23> the only place it doesn't work for me is S3, and if I remember correctly s3 has always worked liked this, it's not the new ui specifically.

</comment><comment><USER24> Haha I go through this problem when I'm in S3

<comment><USER25> they updated s3 recently.. sadly not solving the problem

<comment><USER10> Did that update solve any problems? Other than perhaps for someone who didn't like accessing advanced properties like object metadata? Or maybe people just really wanted a too dark blue color scheme? I switched back to the old after giving it a try and getting frustrated; wasn't ready for prime time.

</comment></comment></comment><comment><USER26> use the api (which is also not perfect)

</comment><comment><USER27> The title sounds like you can please the AWS team by making links ctrl- clickable.

<comment><USER28> Grammatically, that would require a semicolon.</comment></comment>


JSR 376 (Jigsaw in Java 9) Public Review Ballot *not* Approved by EC - <AUTHOR> https://www.jcp.org/en/jsr/results?id=5959 <comment><USER2> What is the effect of this poll result?

<comment><USER3>
      If the Public Draft Specification Ballot fails, the Expert
      Group will have 30 days to update the draft in response to
      the concerns raised by the EC and to submit a revised version
      to the PMO. If a revised draft is not received within 30
      days, the original decision by the EC shall stand and the PMO
      will declare the JSR closed. If a revision is received, the
      PMO shall forward it to the EC and initiate a Public Draft
      Specification Reconsideration Ballot.

From: [https://jcp.org/en/procedures/jcp2#3.4.5](https://jcp.org/en/procedures/jcp2#3.4.5)

Be sure to read the comments on the votes though. Most votes offer an opening for reconsideration, since progress was already made since the version that was submitted for the Public Review Ballot.

<comment><AUTHOR> re: comments in vote log. Thanks for pointing that out! Possibly because it is 4:30 am, I didn't realize the text area contained lots of info. Readers: be sure to stretch it out to see everything.</comment></comment></comment>


What should you do every day to improve your life? - <AUTHOR> http://www.bakadesuyo.com/2012/05/what-10-things-should-you-do-every-day-to-imp/ <comment><USER2> At the risk of sounding too harsh, I'll admit that I was expecting some kind of groundbreaking insight on improving my life. Instead, all I got was the same generic "exercise" and "laugh more" bullshit. Gosh, perhaps I should just tickle myself!

At the abstract level, I find it a bit depressing that the blogosphere seems to be chock full of people who regurgitate common knowledge and attempt to present it as something new. There seems to be very few people who have unique insights worth following and sharing.

My rule with my personal blog has always been: don't write it if it is not new, original, or at least somewhat interesting. This is perhaps why I stopped doing it. :P

<comment><USER3> Do you exercise daily? Do you take walks in nature? Do you keep a gratitude journal? Do you meditate?

Because if there is a single one of these that you don't do, maybe the problem is that you don't execute on the good advice already around you.

<comment><USER4> Am I the only one who almost literally vomits when I hear the phrase, "gratitude journal"?

Maybe it is just me, and I'm some kind of happiness hating troll (I really don't think so, though!) but there's a certain point at which I feel like a person keeping gratitude journal is trying to stave off a deeper and more problematic depression that ought to honestly be addressed with more serious activities besides writing down what you're grateful for every day.

<comment><USER5> I never heard of the concept until a few moments ago and I already know that I don't like it.

EDIT: Now I reflected why I didn't like it. And it is the word gratitude. Granted, I am not a native English speaker but Wikipedia tells me this: "Gratitude, thankfulness, gratefulness, or appreciation is a feeling or attitude in acknowledgment of a benefit that one has received or will receive. " In other words, it implies that there is someone in the other end of a happy feeling to be feel thankful to. And sometimes there is, but being grateful for nice weather, hearing birds singing or being able to walk (not being disabled) implies to me that there is someone "larger" (read a God) out there to be grateful to. And that does not sit well with me. For example, I can be happy to be in good health, but that does not imply that gratitude goes with it.

<comment><USER6> Meh. I'm not religious but I feel grateful and thankful for precious time I get to spend with my kids, for beautiful weather, etc. That doesn't mean I'm grateful to anyone or anything in particular.

Honestly, some people are so militantly anti-religion that they get up in arms (so to speak) at anything that could even be construed as having religious connotations.

</comment></comment></comment></comment></comment><comment><USER7> here's a list that i've compiled over the years.

Daily Habits:

get rid of idle internet time

morning self reflection: what structual and systemic things can be improved today (improve one of the systems)

mental excercise: pick a subject, try to come up with 40 ideas.

go over goals

learn 1 thing before work (could be done in 15 min of reading)

throught the day, stop and classify thoughts as "useful" , "not useful"

do the hardest thing first.. before breakfast..

step out of the comfort zone at least once. (challenge promotes growth)

work on verbal communication (5-15 min practice)

get at least one thing done and off the TODO list

1 HR of quality reading

while being at work, WORK (be results oriented)

spend some time to clear mind clutter and BE IN THE PRESENT

short term sacrifices for long term rewards (expenses, nutrition, excercise)

plan out next day in advance (next week, month)

before taking any action (or not taking action) project forward (30 seconds, 5 minutes, day, year, 30 years) would you be better off with different choice.

recharge emotional energy

<comment><USER8> How do you work on verbal communicaton?

<comment><USER7> English is my 2nd language so a lot of it is American English pronunciation exercises. I imagine native speakers would do something similar in the form of tongue twisters (the kind of thing anchors do to warm up). Or if you got that down, practice the Australian accent. Can never go wrong at parties :)

</comment></comment></comment><comment><USER9> I think the best reason to laugh is: you're laughing. You're exposed to something funny. Humans connect over laughter and funny things. How do you build your sense of humor if you aren't laughing?

I had a roommate last year that moved to Austin from Iraq. He was self- conscious and had trouble socializing. I introduced him to some of my favorite American TV comedies like "It's Always Sunny in Philadelphia". The transformation in his sense of humor was incredible.

One of my favorite things to do before a date is to watch something that makes me laugh. Totally changes my mood.

<comment><USER10> I find laughing difficult. Not because I don't have a sense of humour, I get jokes but I very rarely find something funny enough that I can't help but laugh out loud.

I'm not sure if I've ever laughed out loud at a sitcom, even ones that I enjoy. The same for stand up comedy, the rest of the room can be in stitches but my expression rarely changes beyond a slight grin.

This can sometimes be awkward when somebody is telling me an anecdote that is intended to be humorous, because I always end up feeling like I should force out a fake laugh.

<comment><USER11> I personally tend to have a lot of underlying "social abnormality," including being a chronic grouch, but not laughing at stuff is actually not a problem I have, surprisingly enough.

Do you think this is related to some other aspect(s) of your personality? If so, what? (if you don't mind sharing)

</comment></comment></comment><comment><USER12> I really believe that expressing gratitude every day has a positive effect, so much so that I made a clojure-based site, <http://gratefulplace.com/> (and wrote about the code at [http://www.flyingmachinestudios.com/programming/dissecting-g...](http://www.flyingmachinestudios.com/programming/dissecting- gratefulplace/)).

For the past year I've spent a few minutes every morning thinking about what I'm grateful for and it's had a big positive influence on my life. I'm definitely happier.

</comment><comment><USER13> I agree with most of the commentators below (especially enraged_camel)... I mean did the blogger put any actual thought into writing this post or did they just copy paste stuff that umpteen other blogs have regurgitated over and over a million times ?

I exercise regularly and it definitely helps me in other areas of my life but I wont just advise "exercise daily" as the solution to anyone and everyone who has any questions about getting better.

What has worked for me so far is to set just 1 concrete goal for the year or 6 months and break it down into the smallest possible pieces and act on it daily.

What doesnt work... 1\. Setting too many goals... I mean cmon are you going to start mediating, execising, going out in the nature, maintain a gratitude journal daily ? Sure maybe for 3 days..but once the novelty/willpower wears off, you will be back to square one...

2\. All or nothing... Either you exercise daily or you quit..All of us get trapped into the perfection trap and end up doing nothing.. I would rather exercise/meditate/scratch-my-ass 2-3 times a week until THAT becomes a habit.

3\. Giving up at the first sign of failure and blaming yourself... Too many people say to themselves "Oh I went on a diet but I ate that cookie..I am a failure... might as well eat the entire box and start afresh from tomorrow"/ "I just dont have the discipline, I am giving up".. Know that you will fail a few times before you get the hang of it..which goes back to #2...dont focus on perfection, focus on progress.

That's it... Just 1 goal to be broken into smallest possible pieces...something you can act on daily...or perhaps a few times a week...

</comment><comment><USER14> This seems like a great excuse to pimp my startup! <http://Beeminder.com> is a goal-tracking tool where you have to keep all your datapoints on a "yellow brick road" to your goal or we charge you (actual money). It's less perverse than it sounds though -- you can think of it as a fee for a service that happens to be waived if you never actually needed its kick in the pants.

It's perfect for things you want to commit to doing daily. In fact, it's all about that, as opposed to StickK which is not so data-oriented and just has weekly reports.

Our litmus test for whether you should beemind things like in TFA is:

        1. How certain are you that you *want* to do this?
        2. How certain are you that you *can* do this?
        3. How certain are you that you *will* do this?

If your answers are "absolutely", "definitely", and "given historical evidence, not entirely" then you'll probably think Beeminder is super great.

</comment><comment><USER15> Sounds like the people in this discussion need to do some exercise, have more sex and laugh a bit more.

<comment><USER16> Preferably at the same time.

</comment></comment><comment><USER17> var jq = document.createElement('script'); jq.src = "<http://code.jquery.com/jquery-latest.min.js>; jq.onload = function () {console.log($(".entry-content a[href*='<http://www.bakadesuyo.com]>).length);}; document.getElementsByTagName('head')[0].appendChild(jq);

Am I the only one who's turned off by this number? I understand that's what you're supposed to do and doing this is a nice way to get a bump on your traffic but being bombarded by the links just gives me the feeling that the entire content is there to do just that, rather than conveying any useful information.

</comment><comment><USER18> I would put writing right up there too. It forces you to think creatively and/or analytically and you become a better communicator. Communication can not be underrated as a key to successful relationships.

</comment><comment><USER19> Exercise 30 minutes.

Spend at least 15 minutes journaling the events of the day.

Spend at least 15 minutes planning out your schedule and goals for the next day.

Punch a velociraptor in the jaw.*

Each some greens.

*Optional

</comment><comment><USER20> Read Hacker News... Someone had to say it :-)

</comment><comment><USER21> eat more goji berries </sarcasm>

</comment><comment><USER22> Spend less time on social news sites.</comment>


Why does Fab's CEO keep building big companies that suddenly implode? - <AUTHOR> http://www.theverge.com/2013/11/26/5144184/the-rise-and-fall-and-rise-and-fall-of-jason-goldberg

<comment><USER2> That's crazy... I guess he is chasing something that doesn't exist. He wants to bring his company and product to a place it has no reason being. He needs to settle down, figure out what he wants to do, and just do that for like 2 years... If it's not working, ok, pivot, but don't just pivot out of nervousness and irrationality.

</comment><comment><USER3> "If you ask employees when they started to notice that something was wrong at Fab, they will usually mention the bike locks."</comment>


The Case Against Apple Is Just As Much A Case For Apple - <AUTHOR> http://www.techcrunch.com/2009/08/09/the-case-against-apple-is-just-as-much-a-case-for-apple/ <comment><USER2> It seems a lot of Apple junkies want to try to justify the failures of "their" platform (as if no one had anything better to do than be an apologist for what is, in the end, another computer manufacturer) by saying that the rest of the stuff that's not being complained about works nicely.

That seems to me like an extremely weak point. Computers may be mostly about appliance functionality but the real value of one lies in its customizable parts, and some things are not, in the opinion of a lot of people, negotiable.

Take iTunes. There was absolutely nothing that prevented Apple from implementing USB syncing, which practically every other music player has gotten right and there's no way in which anyone would claim it's Apple's fault if it doesn't work with a player. I don't see how that dilutes Apple's ability to control its own environment. Oh wait, that means I wouldn't need a crappy iPod and I could instead manage with any one of thousands of USB mass media- based players.

Which goes back to the iPod. Wow, was that an inferior product. Apple did not make a single iPod that was actually a superior player on technical terms until 2004. Before that a huge number of players from iRiver, Cowon, and many other smaller players swept the iPod in terms of capability. Hell, my old iRiver iHP-120 is the only portable DAP I know of that had a digital audio output, and until the appearance of the iPod Shuffle no other Apple player came anywhere close in terms of sound quality.

It's not even about the fact that there are better choices of music players; it's about the fact that a vendor is precluding me from using a component of my own because their proprietary implementation competes with it, even if I might not think that badly of Macs, and it costs them absolutely nothing on their part (save trying to strongarm me into buying their DAP).

By the same token one of the things many people want a phone with the power of an iPhone is to have a replacement to lugging a portable computer. That demands an open platform, and as we have seen, Apple has no intention of letting that happen.

What really surprises me here is the fanboys who can clearly hold the doublethink that is believing Apple control is better when they have shown they have no problem with inhibiting users from getting better software than what they have (Opera, Google Voice, Gutemberg Project, etc.).

I guess Apple is a fine company if you're the sort of complacent, couch-potato consumer who does what he is told even if it's not for his benefit. Just keep shelling out cash and you can keep buying into the illusion that you're part of the computer users who "think different".

</comment><comment><USER3> Some of these rebuttals are incredibly flimsy, where they actually even manage to form something resembling a rebut.

For example - How on earth is being prevented from using a flash-capable web browser (or any non-Safari browser) a case for using the iPhone?

<comment><USER4> With apple products, it's more about what you can't do with the products that makes them special.

Not being able to use flash is a feature....somehow.

<comment><USER5> The reason becomes more clear if you use a Mac. Adobe has only bothered to deliver bare-minimum performance on MacOS X, even on the newer Intel hardware. The thought that they could somehow pull off an ARM runtime that performs with modest battery draw seems extremely unlikely.

<comment><USER6> Flash for pocketpc seems to work OK. Shouldn't the user be able to decide if they can spare the battery power. Most people would have a charger handy at work so I don't see what the problem is if you do need to recharge anyway.

<comment><USER5> Flash for desktop windows is ok, too. Maybe Adobe's problem is that they won't allocate the necessary talent to get OSX right. One thing is for certain: if they can't make it fast on desktop OSX they'll not likely deliver on mobile OSX. If I were Apple I'd make Adobe fix their desktop version before I'd let them near my phone.

About giving users enough rope to hang themselves: for every one user like you that could make a conscious tradeoff there are thousands who would never connect the dots between Adobe and battery life.

That's not a business risk I would take if I were Apple. I can take a few ubernerds whining about flash off in some remote corner of the web. I couldn't take Jay Leno making battery jokes in his monologue.

<comment><USER6> > About giving users enough rope to hang themselves: for every one user like > you that could make a conscious tradeoff there are thousands who would never > connect the dots between Adobe and battery life.

People are too stupid to be trusted to make decisions for themselves. That's the Apple philosophy for ya.

<comment><USER5> Restraint is one of the most difficult virtues to practice, and it seems to frustrate and confuse those who don't understand its value. Adding a feature to a product is almost reflexive to most vendors; everybody is mindlessly chasing lists of checkboxes, while ignoring the inherent tradeoffs or pretending they aren't there. It amazes me how the simple act of saying 'no' can send people into such a tizzy.

<comment><USER6> Centrally imposed restraint is different from self control. We aren't talking them deciding not to add a feature. We are talking about them actively preventing others from being able to do so. That's not restraint. That's totalitarianism.

<comment><USER5> There is no imposition upon you. You are free to buy any competing phone that strikes a feature-tradeoff balance that is more to your liking.

<comment><USER6> True platforms that scale are more than just their physical manifestations of phone or computers. They are like ecosystems, marketplaces, economies, even societies. In the end the strength of a platform is the combined efforts of all it's 'citizens'. The systems that govern how those participants relate to each other is much like a government. As such I'm arguing that the iPhone has a poor system of government and will intimately be about as successful as the other large scale totalitarian systems.

Now if you were to argue that the iPhone shouldn't be viewed as a platform then you might have a valid point.

<comment><USER5> I always wondered what sort of tortured mental gymnastics were required to rationalize a sense of entitlement for flash runtimes. And all this time I thought I was picking up a faint whiff of Marx, and the muffled whimpers of baby-proletariat hungry for mother government to expose her teat.

Thank you, but I'll just vote with my consumer dollar for platform B if I don't like platform A.

<comment><USER6> Nice sentence structure. Bad Logic. Successful products usually DO fulfil a sense of entitlement for their consumers.

Some structures scale and others don't. Time wasted with a poorly structured system holds things back, just like Marxism did. Think of all those poor soviets with great ideas (for apps?) only for them to be rejected by central control.

I just want good stuff and in the long term, a locked-down system isn't going to deliver.

<comment><USER5> I don't think that word means what you think it means. Successful products usually fulfill expectations of legal rights or just claims? Really?

It may fulfill some needs or desires, but only rarely a sense of entitlement. If that's what you want a product to do, I suggest that you buy an Android- based phone, and perhaps contribute to the project. After all, if you think that's the recipe for product success, we'll soon see it eclipse the iPhone, right?

<comment><USER6> Do a search for "sense of entitlement" (quoted). You are the one who used the phrase first so you should at least try to understand what it means.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Hazardous Cravings - <AUTHOR> https://tinhouse.com/hazardous-cravings/?src=longreads <comment><USER2> >drinking water before purging

First of all, PSA that stomach acid is generally not more acidic than Coke.

Second, can anyone with some experience in chemistry and biology actually do the math as to how much drinking four glasses of water before purging actually helps? Assuming you double the volume of fluid in your stomach, I'd think that this would change the pH by less than 0.5. Is this significant?

<comment><USER3> Yes diluting something by half is significant.</comment></comment>


Automated line-call system at Wimbledon yields much useful data - <AUTHOR> http://www.spectrum.ieee.org/jun08/6400

<comment><USER2> Here's a short vid of the actual controversial line call in question: <http://youtube.com/watch?v=G2py2SlUBeg>

</comment><comment><AUTHOR> Web site of Hawk-Eye system: <http://www.hawkeyeinnovations.co.uk/></comment>


How to create loading image using CSS only - <AUTHOR> http://web-tricks.org/content/how-create-loading-image-using-css-only <comment><USER2> I'm sorry but this looks awful. it could be -> [https://jsfiddle.net/cp3r5bmk/](https://jsfiddle.net/cp3r5bmk/)

<comment><USER3> That isn't even relatively close to being the same animation.

If that doesn't matter, who not just (paraphrasing):

      <blink>...</blink>

<comment><USER2> you can edit the keyframes very easily

</comment></comment></comment><comment><USER4> The original author should really be credited for this: [https://github.com/dimsemenov/PhotoSwipe/blob/703c415b1b97e8...](https://github.com/dimsemenov/PhotoSwipe/blob/703c415b1b97e8983fff217644888062f07d308b/src/css/default- skin/default-skin.scss#L388)

</comment><comment><USER5> [https://matejkustec.github.io/SpinThatShit/](https://matejkustec.github.io/SpinThatShit/)

</comment><comment><USER6> If you're going to build a loading indicator, you may as well go for a skeleton UI rather than a spinner. It's better UX practice because it lowers perceived load times and is much less jarring to swap in and out.

See: [https://github.com/ksux/ks-design- guide/issues/38](https://github.com/ksux/ks-design-guide/issues/38)

<comment><USER7> The two are not mutually exclusive. Yep, a skeleton UI is great for filling out the canvas, but the addition of a spinner can indicate that "more stuff is coming".

<comment><USER8> I agree. A skeleton is good practice because you are progress and a spinner is great because it's allowing the user to understand the webpage is still loading which isn't always obvious.

</comment></comment></comment><comment><USER9> A collection of CSS spinners: [https://github.com/tobiasahlin/SpinKit](https://github.com/tobiasahlin/SpinKit)

Demo: [http://tobiasahlin.com/spinkit/](http://tobiasahlin.com/spinkit/)

</comment><comment><USER10> ok, now I'm asking... why? what this technique offer that a simple animated svg (or event a crusty .gif) don't? If the problem is the load time of the external asset you can still embed the image in the .css file directly...

<comment><USER11> I can think of a few advantages, the primary one being you do not need expertise in making graphic files to build this.

And once it is set up, it can be tweaked really easily from within the text editor you are already using for the rest of the project rather than having to jump out into Photoshop/Illustrator or ask the designer for a new asset.

<comment><USER12> You can modify and finetune the look and timing of the animation in CSS code.

While this is also possible with SVG animations, they tend to be not as widely supported as CSS animations and at least I need to google for information about this topic as SVG is not an everyday topic for me.

Regarding GIF animations: they are larger in size and you first have to find and use tools to generate them. When avoiding the additional request: data URLs are ugly.

</comment></comment></comment><comment><USER13> After a certain point, the size of this code becomes larger than the size of an animated GIF or SVG.

<comment><USER14> The thing about CSS is you can alter the properties very easily. You can use things like opacity to fake some things with gifs, but you can't change line thickness or color. My experience with SVG is that some things are easy to change with CSS and some aren't, depending on the browser. Support for SVG as background images is poor, so you have to have a bunch of tags declaring the file path or sprite in your markup if you need to use one graphic in multiple places. Using just CSS animation with pseudo elements, your graphic is declared in one place and can be easily changed and reused. Improvements to SVG support would make those advantages null, but that's why I have been using more CSS for small icons(eg indicators) and using SVGs for graphics(things like logos that will only show up on the page once).

</comment></comment><comment><USER15> Here's my article from two years ago about creating this same spinner with a single HTML element.

See: [http://chrisnager.github.io/simple-paper- spinner/](http://chrisnager.github.io/simple-paper-spinner/)

</comment><comment><USER16> Is there a need for BEM with this (or ever)? Also I'd probably use :before and :after pseudo elements to avoid extra markup...

<comment><USER6> Depends how much you value code readability vs. minimizing markup

<comment><USER16> Yes my __thoughts__ exactly; the __extra markup__ and __verbosity__ make things __much more difficult__ to understand.

</comment></comment></comment><comment><USER17> Can also be done with an animated SVG, like so: [https://gist.github.com/kentbrew/873fabf69f678a7b1d6127ea6e0...](https://gist.github.com/kentbrew/873fabf69f678a7b1d6127ea6e02d481)

</comment><comment><USER18> Not a spinner:

[https://andreapaiola.name/2015-02-css-loading- animation/](https://andreapaiola.name/2015-02-css-loading-animation/)

</comment><comment><USER19> I was going to do something similar, but decided just to implement <progress> instead.

</comment><comment><USER20> its very easy to inline a spinner image. thats another way to go.</comment>


Ask HN: Pagerank estimators are broken.  Anyone have an answer? - <AUTHOR>

I just tried checking the pagerank of several sites using the tools that come up when searching for "pagerank".<p>It seems as though every single checker has lost the ability to find out the page rank of a site.  Anyone have an explanation? <comment><USER3> Here's a ruby script that checks PR from the command line. It's working - <USER2> just tried it.

<http://snippets.dzone.com/posts/show/3284></comment>


The Best Algorithm No One Knows About - <AUTHOR> https://getkerf.wordpress.com/2016/03/30/the-best-algorithm-no-one-knows-about/ <comment><USER2> The article mentions the challenges of working with a deck of 2^64 cards, but I don't see how the algorithm helps - seems like it's going to encounter the limits of double-precision values well before that. For instance, the initial setup of "qu1real":

        qu1real = -nreal + 1.0 + Nreal

will behave poorly if N > 2^52 or so. The cited paper refers to this in the Appendix, mentioning that "Roughly log10(N) + 1 digits of precision will suffice", so 20 decimal digits worth versus the 15 available in doubles.</comment>


Why Erlang Matters - <AUTHOR> https://sameroom.io/blog/why-erlang-matters <comment><USER2> AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler.

All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge.

And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggregation), and it is still running with a few years uptime.

<comment><USER3> > And actor supervision is the best way to write reliable systems.

Need some citation there, because we've been writing extremely reliable systems (multiple nines) for decades in various languages (mostly C, C++ and Java).

All these languages (including Erlang) come with pros and cons to write such systems, but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

<comment><USER4> > but so far, Erlang has failed to deliver on most of the promises that its > advocates repeatedly make.

Speaking of citations...

<comment><USER3> Well, Erlang is a niche programming language, isn't that evidence enough that all these claims that Erlang will save us from the multithreaded hell are vastly overblown?

We're doing multithreaded programming just fine in a lot of very varied languages.

</comment></comment></comment></comment><comment><USER5> I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such enormous constant time penalties that the scaling can't overcome the hurdle until you're talking about thousands of processors.

Every single state change requires a function call, every function call involves a pattern matching algorithm that has to account for all of your program arguments (effectively almost the entire state of your thread!) and isn't even strongly typed. And then there is synchronization and data sharing between threads, which seems a bit handwavy and effectively requires a database running in your program that the threads can poll.

If your problem set is lots and lots of small independent tasks that don't have to finish overly quickly, then Erlang is fantastic. Stuff like switching voice circuits for example. But I'm trying to imagine manipulating a 1TB dataset with thousands of worker threads if you have to make a copy on the stack for every change every worker makes.

I know people do some big data stuff with Erlang, so these have to be solved problems somehow, but I can't help but to suspect that they have to compromise some of the ideals espoused in this article to make it work.

<comment><USER6> Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own.

It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but writing high-performing Haskell can be harder than you'd like. Rust shows you don't have to clone Erlang's immutability and all the associated issues it brings with it for inter-process safety, but Rust of course is "just" a standard programming language next to what Erlang brings for multi-node communication.

<comment><USER7> You could write NIFs in Rust (well not sure if you can now, but I don't see any reason it couldn't be supported) for the high perf bits and use Erlang to coordinate, I figure. At least Rust code is less likely to explode and bring down the whole VM than C.

<comment><USER8> Any idea if a network-level FFI has been started? I'm thinking along the lines of the Haskell erlang-ffi [0].

        Speaks the Erlang network protocol and impersonates
        an Erlang node on the network. Fully capable of
        bi-directional communication with Erlang.

NIFs still limit you to < ~1ms computations, from what I understand, but impersonating a node (on another machine, even) seems a lot more flexible. Just wondering; NIFs in Rust are still a great idea.

[0] [https://hackage.haskell.org/package/erlang](https://hackage.haskell.org/package/erlang)

<comment><USER9> Have you seen c nodes[1]? That may be what you're looking for?

[1] [http://erlang.org/doc/tutorial/cnode.html](http://erlang.org/doc/tutorial/cnode.html)

</comment></comment></comment></comment></comment><comment><USER10> I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant.

Is Erlang too esoteric?

<comment><USER11> Having spent quite a bit of time searching for Erlang packages on Github recently, I've found quite a few Erlang packages haven't had commits since around 2013. I believe there was a spike in adoption around 2012-2013 which resulted in a bunch of activity on Github. Which seemed to have tapered off recently. But you still find many core packages that are active - things like JSON parsers, templating libraries, and web frameworks are all lively. And OTP and Erlang itself are always being improved.

Plus there is an up-to-date package manager/global repo ([https://hex.pm/](https://hex.pm/)) which is used by both Erlang and Elixir. Plus Rebar3, the primary build tool for Erlang projects, is actively developed.

But Elixir packages are very active in general since it's relatively new and these packages can be used within Erlang apps relatively easily as well. Plus the Erlang packages from 2013 that I've used have all been pretty stable. The quality of libraries available on Github have all been very high from my experience. I believe Erlang attracts experienced developers, which is reflected in the typical code quality and documentation.

My only wish is for the Erlang website ([http://www.erlang.org/](http://www.erlang.org/)) to get a redesign. It gives the language an esoteric apperance to newbies. Which is a shame because I absolutely love the language and think it's far superior for many of the types of projects for which people have been using Node.

<comment><USER12> I am excited for a continued improvement and enhancement to the language.

Erlang 18 brought maps, people complained about that for years. Erlang 18 also brought (via a feature flag) dirty schedulers so can have long running C function embedded in without messing up process scheduling also an often requested features. Probably the best thought-out handling of time in any language I've seen so far ( synchronization, warping, moving backwards: [http://erlang.org/doc/apps/erts/time_correction.html](http://erlang.org/doc/apps/erts/time_correction.html) )

Erlang 19 is exciting as well -- 10x faster tracing, dirty schedulers turned on by default, a new state machine OTP module, an external plugin (with LevelDB as one example) for Mnesia storage also something people complained, 2x-3x faster spawning external processes + many others.

The impressive part is that these changes are done to a 30 year old language.

<comment><USER13> mnesia_leveldb is scheduled for OTP 19? That's great news!

I can't tell you how many times I've cursed at the overfilled-hours-ago-but- mnesia-didnt-care DETS table shard. Getting a on-disk backend that can store more than 2GB at a time will be great!

It'll be even better if the writer code actually _notices_ failures to write to the backing store and aborts transactions when they happen! [0] :)

[0] Seriously, who thought it was a good idea to ignore the return value from dets:insert/2? :(

<comment><USER12> I think this is the PR so far:

[https://github.com/erlang/otp/pull/858](https://github.com/erlang/otp/pull/858)

</comment></comment></comment></comment></comment><comment><USER14> Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

<comment><USER15> It just seems that all the effort going into Erlang would be better spent on making the OTP stuff as a library for a popular, cross-language platform. Like the JVM (or maybe .NET.)

<comment><USER16> sure. we can start when the jvm can do preemptive scheduling of processes

erlang isn't great because of a single feature or library, it's great because it's designed from the ground up for one very particular role. you can't just port the otp api to go or the jvm. you need the whole foundation

</comment></comment></comment><comment><USER17> I'm really interested in BEAM languages, but the fault-tolerance / supervisor aspect of it doesn't speak to me. Aren't all modern application fault- tolerant, as long as you don't design something really poorly?

For example, I've never had a single HTTP request bring down an entire website -- that's already isolated. Same with message-queue listening processes. For general batch applications, I've always had them short-lived and running periodically, e.g. every minute, so even a complete crash there is isolated between runs.

One powerful aspect is how it strongly encourages you to design loosely- coupled message-passing systems that should be easier to scale out. But I'm not convinced that's enough to warrant a switch.

<comment><USER18> Erlang's fault-tolerance becomes really useful when you wrote a server that manage hundreds of thousands of simultaneous connections (a chat server being the typical example). With Erlang, each connection is managed by its own lightweight process (no callbacks, no promises, etc.). If a lightweight process fails, it doesn't bring down the other processes. Moreover, BEAM can signal other processes about the failed process (Erlang' supervision trees are based on this mechanism).

In a traditional architecture, you would use one thread for each connection (let's ignore the issue of the memory used by each thread), but when one thread fails, it would bring down all connections instead of just the failing one.

</comment></comment><comment><USER19> You know, even if Erlang didn't have great SMP scaling, or wonderful distributed properties, I think its fault-tolerant, actor-model-ey nature would make it wonderful anyway.

The fact that you program expecting failures, and forced isolation of everything allows for incredibly "sturdy" code. The other features are fantastic, but they're just gravy as far as I'm concerned.

</comment><comment><USER2> The future is already here: [http://erlangonxen.org/](http://erlangonxen.org/)

<comment><USER20> Ling is cool stuff, but I have the impression that it's a clean-sheet Erlang VM implementation, not a port of BEAM. BEAM is time-tested and battle-proven, and I'd really like to see BEAM itself rely less on the underlying OS (e.g. epmd as a separate OS process, quirks in how it uses select/poll). I know Peer Strizinger did a lot of work on this[0], but hasn't (to my knowledge) yet released any of his work, sadly.

[0] [http://www.grisp.org](http://www.grisp.org)

</comment></comment><comment><USER21> Erlang is glacially slow. Even on a 20 core machine, a multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation. All this stuff about multicore scaling is baloney - who cares it is scales and is still slow?

<comment><USER12> > multithreaded Erlang implementation will usually be trounced by a good > singlethreaded C++/Go/Java implementation

And Go/Java implementation can be trounced by hand written assembly and ASIC accelerators probably.

> All this stuff about multicore scaling is baloney

You say baloney I say money in the pocket. I've seen it scale, I've seen it work reliably in large clusters, I've been able to inspect, debug and hotpatch running systems while they are still running. I have seen systems which had non-critical components crash and auto-restart for days without impacting customers and needed teams of "devops" to babysit it.

Moreover I've see single and multi-threaded C++ and Java applications with threads and and data races which take weeks or months to find. Or they are screaming fast until they take a nosedive and segfault (also in some minor stupid new feature which nobody uses). You know what the transaction processing rate of a segfaulted process is? - 0 tps.

That's why teams like Whatsapp could get by with only 10 or so back-end engineers handling billions of messages / day from various devices new and old, while other companies need 10x or even 20x more than that.

It is not just being able to run fast. Assembly runs very fast. It is also about being able to have the right tools and abstraction to define a problem. Erlang has those and they come built-in (the OTP library, the distribution protocol etc), C++ doesn't, so have to start from STL and boost and so on, then get serialization, monitoring, supervision, etc bootstrapped.

</comment></comment><comment><USER22> To me the power of Erlang comes from a combination of powerful VM and OTP. In the era of hype for SOA, OTP

You can run multiple apps on the same VM and they will run concurrently and communicate with each other using protocols that are core of the language.

I agree, erlang seems weird at first, simply because there is not anything like it. It also solved todays problems with software a decade ago.

</comment><comment><USER23> One word: ejabberd. That's why erlang matters to me :)

<comment><USER23> Also, it has a great free book on it: [http://learnyousomeerlang.com/](http://learnyousomeerlang.com/)

<comment><USER13> There are at least two great free books: [http://www.erlang-in- anger.com/](http://www.erlang-in-anger.com/) ! :)

<comment><USER24> Written by the same author no less. :-)

</comment></comment></comment></comment><comment><USER25> This seems like it could've been called "Why Actor Systems Matter".

If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time.

I'm totally sold on Actor Systems and think it's something more programmers should expose themselves to. I'm just not sure there's much of an argument for Erlang vs the JVM unless you're completely sold on the notion of process isolation for some reason.

<comment><USER26> It's not at all about segfaults. Assuming the Erlang VM is as likely/unlikely to crash as the JVM, then it's a complete wash: Erlang processes are green- threads, not OS processes, so you don't gain anything there.

It's about the share-nothing architecture of Erlang: it means your processes are isolated and can be stopped/restarted independently, crash/hang without writing into the memory of another process, have their own garbage collection, and be moved to a different physical computer (or even data center) with no impact at the logical level. Erlang forces you to architecture your program as a collection of nano-services. You can of course emulate some of it on the JVM, but you can't go lazy and cut corners with Erlang.

<comment><USER25> Akka checks most of those boxes AFAIK. And there's really not much you can do in the way of cheating unless I misunderstand you. Or at least idiomatically you wouldn't cheat in Scala anyways.

Speaking of which, I just realized the AtomicLong I'm using in my IdGenerationActor (performs an atomic increment of a processId counter in the database, then uses that with the AtomicLong as the input to Hashids; fast, in-process, cluster-safe short-Id generation that will leave popular Redis based solutions in the dust) is completely unnecessary. Copied and pasted from non-Actor code without consideration.

I guess Actors still can't keep you from doing dumb things yet. ;-)

<comment><USER16> this is just not true. every other week i have production issues because akka managed to exhaust the thread pool with long running/nonresponsive actors

<comment><USER25> You've done something wrong then? Or maybe using experimental features? I might play with them a bit, and it can be frustrating to wait, but I've never launched anything on -experimental before.

I was referring to "cheating", with the idea that you might pollute your Actors with... I dunno. Programmatic connection pooling for your database driver? Passing mutable messages around?

Both of those things would be very unusual in Actors written in Scala since pretty much everything is immutable by default. Seeing that sort of thing should at least raise some eyebrows.

As far as non-responsive, I've never seen that. But I do take care to use Futures where appropriate, and pipeTo. Maybe it's good habits, or maybe I'm just very lucky.

One of my first Akka projects is still running, still processing content it's notified of by Postgres through LISTEN/NOTIFY, still posting that content into Cloudant (basically a managed Lucene deployment in this case).

And it's been running since September 2014 without a restart AFAIK. Which would have never happened with a previous non-Actor solution we might have used if for no other reason that a network blip might detach the listener, whereas here the Actor just restarts.

My experience has been overwhelmingly positive. Despite doing the wrong thing occasionally.

If you have Actors that are hung, I guess the first thing to try is figuring out which one(s). After that, you could just schedule the supervisor to routinely PoisonPill them, and forcefully stop them after a grace period.

I'm not sure that OTP is going to help with this sort of issue either. You have an apparently blocking process that makes an Actor non-responsive. The fact that it's single threaded within the Actor and stalls it's mailbox is kind of the point of Actor systems AFAIK.

I guess one thing I feel like helps me is to keep my Actors small and doing one thing. It's hard to do too much damage when you only have a dozen lines of actual message handling. "One thing" is sometimes coordination/aggregation BTW. Which means I might have a GetRequestActor, PutRequestActor, DeleteRequestActor, etc. Which do the one thing. But then I also have a DatabaseActor that basically just coordinates/forwards for all those so you don't actually have to deal with them yourself.

And from there if I decided that no GetRequestActor should take longer than 10 seconds to do it's thing, I can easily schedule the DatabaseActor to forcefully stop any task exceeding it (without the need for an actual watch if you choose). Which you can then log an ERROR for and work out why. And maybe some requests just take longer and that's OK. So maybe you then write a LongRunningRequestPathExtractor and put that pattern before the normal one. And now you can have multiple timeouts for different paths.

Or maybe you just record the epoch for different requests, and if you've had 1,000 updates since the last View request, you know the next one is going to trigger a reindex. So you give it extra time. Or you set it to allow stale results and reschedule the same call to occur again in 1 minute to minimize the disruption of indexing the changes. Just some thoughts.

<comment><USER27> > _You 've done something wrong then?_

Well, the idea is with Erlang you can't.

<comment><USER25> I don't believe Erlang goes around magically imposing it's own timeouts on message handling.

<comment><USER16> it doesn't, but an erlang process that is waiting on a message won't block other processes from running ever

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> Please let me ask some noob questions.

> Erlang matters today because it demonstrates how these semantics can be > elegantly packaged in one language, execution model, and virtual machine.

Why is it so important to demonstrate that these semantics can be packaged into such a homogeneous environment ? Is it even a good idea ? Is this way of doing things superior to having micro-services that talk to each, all managed by a supervisor system ? Wouldn't that allow us to take advantage of the unique upsides of multiple programming languages, virtual machines and execution models ?

<comment><USER29> You may underestimate the difficulty of writing a bullet-proof and feature- rich "supervisor system". That has pretty high complexity and lots of nasty edge-cases.

Erlang happens to nail that part with OTP.

</comment></comment><comment><USER30> I made an argument that we were reinventing many of the ideas of Erlang in the DCOS model (Docker, Kub, and cloud etc).

Text is here (CTRL-F erlang):

[https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-20...](https://zwischenzugs.wordpress.com/2015/11/17/dockerconeu-2015-talk- you-know-more-than-you-think/)

Video here:

[https://www.youtube.com/watch?v=-qHwL8C9UoA](https://www.youtube.com/watch?v=-qHwL8C9UoA)

</comment><comment><USER31> "Cache coherence doesn't scale."

This is a controversial statement, and an opinion that is not shared by many respected computer science researchers: [http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coher...](http://research.cs.wisc.edu/multifacet/papers/tr2011-1_coherence_stays.pdf)

<comment><USER32> It does scale when being considered by software running on it. Even more with some alternative approaches like directories. What OP means is that it does not scale for software to be oblivious to underlying cache coherence and to operate on "one flat shared RAM" assumption. E.g. false cache line sharing etc.

</comment></comment><comment><USER33> Linked article "power-wall" ([http://daimi.au.dk/~zxr/papers/treewalls.pdf](http://daimi.au.dk/~zxr/papers/treewalls.pdf)) seems to be unavailable.

Does anyone working link to this article?

<comment><USER34> Updated to point to [https://en.wikipedia.org/wiki/Multi- core_processor#Technical...](https://en.wikipedia.org/wiki/Multi- core_processor#Technical_factors)

</comment></comment><comment><USER35> Doesn't the existence of Golang remove most of the reasons to use Erlang these days?

<comment><USER36> I was wondering this when Go came out. But time has shown they solve problems very differently, so they are not really direct competitors.

Erlangs primary difference over Go is that it can gracefully handle the case where a programmer has made an error in the program by accident. A typical Go program cannot gracefully recover from an error which were unforseen and never considered by the programmer. The Erlang equivalent Erlang program, however, has mechanisms to safely clean up resources for the faulty part and then get on solving work. This is the reason Erlang has a nice robustness story.

<comment><USER37> [https://github.com/thejerf/suture](https://github.com/thejerf/suture)

Supervisors for golang. It looks excellent. I personally have fallen for Elixir and think the syntax, immutability, community and class functionality like Phoenix.Presence make me bet that it'll be bigger than Python for jobs in 5 years.

<comment><USER36> Supervisors is only half the game here. Suppose A sends a message to B and decides to wait around for the answer. B now divides by zero.

In Go, your whole program is in consistency trouble and you have to write code to handle the case.

In Erlang, your monitor on B means you get told it is dead via an async exception delivered into your mailbox.

I know what kind of system I want to work with here :)

<comment><USER37> Wow. That's just incredible. I seem to _keep_ saying that the more I learn about Erlang/Elixir.

</comment></comment></comment></comment></comment><comment><USER38> One missing feature is that you cannot run the same code in the browser and on the server (which is very useful).

Is there a language that compiles to both Erlang and Javascript?

</comment><comment><USER39> There is Armstrong's thesis (google it) which explained all the major design decisions much nicer that this arrogant "Erlang matters".

The foundation principles is not only in selecting a functional language and enforce immutability, but explicitly rejecting all sharing (threads in the first place) and providing a theoretical basis of why JVM is an unacceptable target for reliable, soft-realtime systems, (no matter what Scala guys might tell you) - a crashed process would affect none other, no data corruption, no locks, no messed up stack. This is what is behind the "let it crash" meme.

Erlang is not "matters", it is a masterpiece of software engineering to study and learn insights from. Especially, how to make ones own decisions based on right principles and rejecting sectarian dogmas (run everywhere!) of wast majority.</comment>


Notie.js: A JavaScript notification plugin without dependencies - <AUTHOR> https://github.com/jaredreich/notie.js <comment><USER2> > Works in all modern browsers (Chrome, Firefox, Safari, IE, Edge, Opera)

For people who are concerned with backwards compatibility (which I know isn't everyone, but it is a necessity for my work), it would be super helpful to clarify this statement. Specifically, how far back in IE does it go? What about mobile Safari vs. desktop, and what about the Android browser?

Thanks, looks like a neat little utility.

<comment><USER3> You're welcome, it was fun to make! It is a good idea to add detail to the browser compatibility and I will eventually do so. It was before this repo gained popularity that I did the quick browser testing to warrant that statement. Thank you for the suggestion.

</comment></comment><comment><USER4> A plugin for showing notifications, packing ~700 LOC and 25kb of JavaScript. I can admire the "no dependency" ambition but at the same time it's marketed as a plugin that has everything you'll ever need, probably targeting the audience that is already using Bootstrap and/or jQuery. Let's solve all the DOM quirks, again.

That being said, there's a probably a lot of useful stuff in there and some inspiration if you want roll your own solution!

<comment><USER5> Please don't depend on bootstrap. Require jQuery if you really need too, otherwise raw DOM would be lovely and keep your deps down.

<comment><USER6> Building on this, if you do support BS3/4 be sure that the boostrap stuff is either an separate dedicated file/folder or an add-on file. Anyone who cares about those extra files should be using gulp/grunt/webpack anyways.

</comment></comment></comment><comment><USER3> Hello everyone! I'm the creator of notie.js and although I'm a frequent browser of HN, I found this post from a fellow who placed the link in a comment in one of the GitHub issues. Very cool to see someone promoted this! Thank you for all the comments/suggestions/feedback!

</comment><comment><USER7> It's ok to have dependencies. If you want to avoid big dependencies like jQuery, there are tiny DOM modules that you can pick and use; [http://github.com/npm-dom](http://github.com/npm-dom)

</comment><comment><USER8> It is a pity: I consider this kind of notification really attractive but proved to be a antipattern in the projects I implemented.

Notifications are better when shown near the event source. If your user base includes some non-technical profiles they can become confused by this kind of message without context.

It can work for global announcements that can not be tied so a specific source or they are hidden and are important ("remember to activate your email").

This was just my experience. Congrats anyway for the work, it is really visually appealing.

<comment><USER3> This is true about the notification potentially not being close to the action point - though the way I thought of it is that the user should know what action they just took therefore will understand the message they just got. Especially if the site uses this library throughout, the user will be used to this kind of feedback on their actions. It also makes it a bit more friendly for responsiveness as the developer doesn't have to worry about placement or if the alert will fit on the screen properly.

<comment><USER9> I try to keep related interactions near each other so showing notifications near the source turned out to be more problematic than having a single place for notifications (like near the top where there useful information can be seen but no interactions occur)

It was apparent after just a simple mockup that the notifications would get int he way if the user was makign many rapid interactions.

In my paricular application the notifications could be used as a history of interactions that could be opened up and examined in more detail.

</comment></comment></comment><comment><USER10> Handy. But was browsing through the code, and I didn't find it that clean, maybe personal taste. I like to use plugins that are solid.

        function input(title, submit_text, cancel_text, type, placeholder, submit_callback, prefilled_value_optional)

Feels like this function has too many parameters, might be doing too much.

<comment><USER5> It's also in snake case, whereas JavaScriptuses camelCase (with the odd exception, like title case prototypes and lowercase event handlers).

</comment></comment><comment><USER11> I've used this lightly/moderately, and it's worked well with no surprises.

</comment><comment><USER12> Neat, though I read the name as "Not IE" at first.

</comment><comment><USER13> Keyboard accessibility is missing.

<comment><USER14> Nothing is missing, the library does what it does. If you need keyboard accessibility you are free to add it.

<comment><USER13> Libraries that display overlays with interactive elements should be keyboard accessible, by default.

<comment><USER14> Sure, if you want to pay the developer to create interactive elements for you feel free to specify the requirements. Since nobody paid for this work, and nobody is requiring anybody to use it, there is not a single feature that should be included 'by default'.</comment></comment></comment></comment>


Why A.I. Researchers at Google Got Desks Next to the Boss - <AUTHOR> https://www.nytimes.com/2018/02/19/technology/ai-researchers-desks-boss.html?rref=collection%2Fsectioncollection%2Ftechnology&action=click&contentCollection=technology&region=stream&module=stream_unit&version=latest&contentPlacement=2&pgtype=sectionfront <comment><USER2> This reads like a piece of advertising.

<comment><AUTHOR> In what way? Given the number of big company name drops, who is it an ad for?

<comment><USER3> I explained why in the previous submission of this article, this appears to be the work of a PR firm: [https://news.ycombinator.com/item?id=16416420](https://news.ycombinator.com/item?id=16416420)

It's not surprising they added additional sources, but it's _likely_ Google or Facebook's, or even Overstock's, if they're hoping to be viewed on the same tier as Goog and FB.

It's pushing AI research buzz, in general, (while containing no actual news) which is pretty valuable to someone like Google, who markets themselves as "an AI company".

<comment><AUTHOR> The responses to your assertion seem valid, and given that you don't know which competing company is being advertised, that seems to support them even more.

<comment><USER3> As Graham's article explains, the goal is for your press hit to not look like an ad. I can't be 100% sure who's behind it, but, for example, it fits the classic submarine model if it's Overstock. Note that Graham specifically cites quoting "experts", and down in like third or fourth, you'll see the actual client get dropped.

> With trend stories, PR firms usually line up one or more "experts" to talk > about the industry generally. In this case we get three: the NPD Group, the > creative director of GQ, and a research director at Smith Barney. [5] When > you get to the end of the experts, look for the client. And bingo, there it > is: The Men's Wearhouse.

Google and Facebook could easily be considered "experts" in this field, and Overstock is definitely a place that doesn't come to mind when you think "AI researchers". This little submarine might be trying to plant the idea in peoples' heads that OLabs is a place to consider when they're looking to do AI research. You might not have thought of it before, but you might think of it now.

The article wasn't outwardly an ad for them, but it's maybe the only new information it inserted into your brain. The perfect submarine.

<comment><AUTHOR> You could be right, but I see a problem in that you could just as easily be wrong. Worse, if I apply your standards to many other articles, I'm capable of obtaining the same ambiguous results.

<comment><USER3> Many other articles are also submarines. ;)

<comment><AUTHOR> _Twitch_

Granted, but it's the ability to distinguish them from others that seems to be the relatively hard part.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Android can't work its way through structured data (open app -> perform function that is achieved in two or three touches in app -> narrate back the results). There is way too much hype in A.I.

<comment><USER5> It also lacks the ability to discern intention. If I am driving and ask for a location, it should be able to start navigation without having to be re- prompted. Things like this should be easy and yet I find myself having to spoon-feed the AI. Every. Single. Time. It's just really cumbersome and disappointing every time I try to use it.

</comment></comment><comment><USER3> Dupe of: [https://news.ycombinator.com/item?id=16416294](https://news.ycombinator.com/item?id=16416294)

</comment><comment><USER6> I thought Goodfellow was in Toronto. Jeffrey Dean being a short walk away from the CEO is nothing surprising of course. These people are research institute directors basically, hardly researchers themselves, which is what the title makes it sound like

<comment><USER7> He's in San Francisco.</comment></comment>