Ask HN: What's the big deal about Ruby and/or Rails? - <AUTHOR>

It's not a rhetorical question, I'm really, honestly, trying to understand what the big deal is about Ruby. I'm not trying to start a "my programming language / framework / environment / technology is better than yours" fight, so I'm not looking for opinions on why Ruby might be better or worse than (pick your poison). I'm just trying to understand why and how Ruby is getting so much momentum, and whether it really matters, or is just one of those meme things that happens in a close community like tech startups. <comment><USER2> I believe it's not as big a deal now as it was when it first arrived. At that time the idea of an MVC web framework wasn't new. Django was also in development and PHP had several crap web frameworks available. So, there weren't very many web frameworks and what was out there wasn't very good. Rails hit the scene and brought the idea of web frameworks to the masses of web developers. Even today after all those years there are PHP frameworks which try to mimic Rails and fall short. The alternatives of today are largely good enough though, especially for more specialized cases.

I think you are a step behind. These days you should probably be asking "what's the big deal with Node.js?" ;)

</comment><comment><USER3> regarding Ruby:

Ruby is dynamic. Kind of like Perl, Python and PHP, but meta-programming features make it feel even more powerful.

Ruby is object-oriented. Even more than, let's say, Java. No primitive data types. Even things like regular expressions and pieces of program code are objects. This makes the language feel very consistent.

Ruby is beautiful. The syntax and consistency appeal to many developers for a variety of reasons. For me it's the fact, that if you adhere to some common sense rules of naming your variables and methods you get extremely readable code.

Ruby has some unique and interesting features. Such as code blocks (kind of closures).

Combined this means that you can accomplish a lot with very small amounts of actual code. Still, this code remains extremely readable and thus maintanable.

For many developers, Ruby ist the last language they ever want to learn. But to be honest, I think it is not for everyone. You should try it and see if it feels "right" for you. Do not worry, if you don't get it, and maybe try Python instead.

regarding Rails:

Today, I guess Rails is nothing special anymore. These days you can choose from a variety of quality web frameworks in whatever language you are comfortable with (and most of those probably borrow some ideas from Rails).

To understand what really set Rails apart you have to imagine the world of web development in 2004, when Rails was first released. Back then you had to either use PHP, which has a bad reputation for many reasons I do not want to delve into, or some ridiculously complex Java framework.

Rails was (and still is) a wonderful framework that takes the tediousness out of many repetitive web development tasks. Furthermore it gives your project a structure, trying to lead you to write well-structured, testable and maintainable code.

Oh, and of course Rails is written in Ruby. Rails introduced many people to the Ruby programming language. I think it is the combination that makes it both so powerful and likeable.

</comment><comment><USER4> Ruby is probably the most zen thought interpreted OO programming language.

        Example: http://news.ycombinator.com/x?fnid=IpkcxQEdui

Rails is probably the most zen thought web framework.

        Compare Rails#has_many with Django#foreign_key , which feels more natural?

The sum renders _the benefit of cognitive discharge_ that lets you focus on important stuff and not tinker on details.

The rest is huge community, huge documentation, large mature ecosystem (mostly web stuff, python's SciPy pretty much way-ahead, all tough ruby can do science too), lots of best practices from the start, github-lead, mature implementations etc

</comment><comment><USER5> Because it's easy to learn, has good community support, and powerful metaprogramming features. In a nutshell it's easy to think and create in ruby.

Also significant is that the tradeoffs you must live with (speed, lousy debugging/refactoring tools) to get ruby's benefits just don't matter for a huge swath of web projects.

Ruby is optimized for a very common, very pragmatic set of problems.

</comment><comment><USER6> I suspect it's because of Rails and the commercial potential of the web these days (Groupon, etc.).

As an aside, it seems like a pretty nice GP language in its own right. I had to write some shell scripts for a Windows box and picked Ruby largely on a whim. Two months later, and I've got a stack of Ruby books and I'm going user group meetings.

<comment><USER7> Regarding "I'm going to user group meetings".

I'm not a Ruby user, as I work primarily with statistical computing and machine learning, but Ruby has a really impressive set of regional user groups. Except for R, there aren't really any other languages which have a significant number of well organized regional user groups. It's great for users of a language to get together and share info and provide guidance to new users.

<comment><USER6> The community is amazing. I've been to groups for other languages, but they aren't as hands on or useful as the Ruby meetings. The Ruby group in my area does monthly 'hack nights' where experienced rubyists pair up with noobs and implement a small project. That kind of interaction keeps me motivated and lets me pickup standard practices and tools much faster.</comment></comment></comment>


Ask HN: I'm going to learn Scheme; any suggestions? - <AUTHOR>

I don't know much about it yet, but I ordered a book and am motivated to get through it. Although I have to learn it for a class, my main priority is to learn the basic concepts of programmings, and Scheme seems to perfect for that.<p>So does anyone have any comments about Scheme as a language and about how easy it is to learn it? <comment><USER2> The obvious choice here is to start with The Little Schemer. After that you can go on to SICP. Another alternative which is not nearly as challenging as SICP is HtDPv2 (How to Design Programs v2). HtDPv2 was written to be used with Racket.

There's also the Reasoned Schemer and Seasoned Schemer, but I haven't any of read either of those so I can't tell you with any certainty if they live up to the experience provided by the Little Schemer.

In general those are the 5 best books covering Scheme as far as I know of especially for you as a learner. I'm sure there are other books for more advanced Scheme, but I don't know them.

The Little Schemer is great fun and is programming equivalent of piano finger exercises.

</comment><comment><USER3> Scheme is a great language to get going w/ functional programing and lisp type languages. I would suggest using Racket. It is 'batteries included', design for teaching so there is tons of documentation and has support for R5 and R6 versions of scheme.

Most programmers I know started w/ an imperative language. I didn't and feel grateful for it. Learning programming in a different way tends to mean even if you get a job doing imperative program, you usually think different from others and that can lead to excellent conversations, designs etc.

</comment><comment><USER4> I learned it from a class. We blazed through the SICP in 15 weeks. I'd advise the same. Use MIT's OpenCourseWare as a guide: [http://ocw.mit.edu/courses/electrical-engineering-and- comput...](http://ocw.mit.edu/courses/electrical-engineering-and-computer- science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/)

</comment><comment><USER5> Scheme is not that hard - I had some trouble internalizing call/cc, but the rest is rather straightforward or fiddly but not really difficult (macros).

That said, I sometimes get the idea that the majority of Scheme code is in Scheme implementations - which put me off the language.</comment>


Building a Decentralized Webpage - <AUTHOR> http://medium.com/@abarisser/a-decentralized-web-site-anchored-in-the-blockchain-14b91cef0e4c <comment><USER2> Well, we already have [0] a widely popular decentralized web without needing the Chinese miners to keep the lights on!

[0]: [https://ipfs.io/](https://ipfs.io/)</comment>


Octopus skin contains a light-sensitive pigment found in eyes - <AUTHOR> http://www.theguardian.com/science/neurophilosophy/2015/may/20/octopus-skin-contains-light-sensors

<comment><USER2> According to Wikipedia, "an octopus has a highly complex nervous system, only part of which is localized in its brain. Two-thirds of an octopus's neurons are found in the nerve cords of its arms, which have limited functional autonomy".

This and the link makes me think that octopuses are one of nature's best distributed systems.</comment>


Îñţérñåţîöñåļîžåţîöñ - <AUTHOR> http://googlewebmastercentral.blogspot.com/2011/09/internationalization.html <comment><USER2> An extremely important point that most native english speakers just doesn't seem to get: Don't force a localized version to your users.

In many countries your users are probably going to prefer english than a translated version for many reasons, and that's even before taking into account that you probably can't translate it well anyway (even with a lot of resources and effort) which makes it even worse.

Always make it ridiculously easy to switch to english, always. In many cases you probably should make english the default even though you have a localized version (this is especially true for web sites, few things are as annoying as having to change language again and again and again and on every device, browser etc. (example: youtube has this annoying message telling me that a localized version is available that forces a page reload to dismiss (and thus you have to reload and restart the video, true story))).

This of course depends heavily on your target audience and their culture but just don't assume a translated page/app is a favor, you just might end up with some confusion and a group of really outraged users (boy do I loathe applications that assume I want a translated version - always give me the option to change it to english during the installation).

Direct machine translations might be better than nothing for some cultures but for some it's a slap to the face and will just make your company look pathetic. Example: Adobe.

<comment><USER3> > Always make it ridiculously easy to switch to english, always. In many cases > you probably should make english the default even though you have a > localized version (this is especially true for web sites, few things are as > annoying as having to change language again and again and again

Yeah, like google.com. Whatever I do it just does not seem to be possible to _permanently_ set US version of google.com as default, not local version. Especially frustrating when traveling to other countries and getting it in language you do not understand.

<comment><USER4> No redirection: <http://www.google.com/ncr>

Explained here: [http://www.google.com/support/websearch/bin/answer.py?answer...](http://www.google.com/support/websearch/bin/answer.py?answer=873)

<comment><USER5> I have that as my homepage to make sure that the cookie is set every time, and I still occasionally end up with search results or google products in non- English.

<comment><USER6> Agreed. And it annoys the hell out of me if I fire up my Android browser and end up on a Hebrew home page, again.

Somehow I thought that we already had a mechanism to negotiate the language between server and browser. Ah well, let's just ignore Accept-Language, shall we?

</comment></comment></comment></comment></comment><comment><USER7> We're currently going through our internationalisation test phase for a major release and it's been a _huge_ headache.

My one piece of generalised advice: DO NOT leave internationalisation testing to the end of the release. Make sure you're pumping Unicode strings through your app in unit tests. Make sure you're regularly viewing your app in other languages using mock strings if you haven't got the translations. The earlier you can find these defects, the easier it is to fix. There's a perception that internationalisation defects are easy fixes, just updating a messages file. The truth is that major parts of your app may not work unless you regularly test it. And don't rely on the Unicode abilities of your chosen framework, language or operating system. If you haven't tested it, it doesn't work

<comment><USER8> Here's a real life scenario:

1) Develop a project in a rush

2) Becomes successful

3) Boss/Client decides to launch it in 2/5/10/22/34/82 countries

4) Project becomes one big hack

One simple Unicode test and 10 minutes of initial thinking would've saved all this trouble.

</comment></comment><comment><USER9> > We can't recommend this enough: reuse the same template for all language > versions

This can get quite tricky, because languages don't easily map onto 1-to-1 items that can be just translated independently and stuck into a template. See the classic "localization horror story": <http://interglacial.com/tpj/13/> (and HN discussion: <http://news.ycombinator.com/item?id=2095334>)

<comment><USER10> It's not a problem of HTML, but the method you use to construct translation string key names.

If you have `<button>file</button>` and use it in both "[file] a complaint" and "save to a [file]", then you're in trouble indeed.

But you can fix that by adding context to translation keys in the template, e.g. in TAL you can do `<button i18n:translate="'file (verb)'">file</button>`.

<comment><USER9> It's not just an issue of polysemy (that "file" means two different things in English), but that the structure itself may need to be different in different languages, because languages have different grammars, and different ways of dealing with objects/numbers/etc.

In the example I linked above, there's a whole mess of rules to capture if you want to handle singular/plural correctly in different languages, including those that distinguish more cases than singular and plural. It boils down to the fact that word-for-word translation doesn't work in all but the simplest cases: you can't translate "[a] [b] [c] [d]" by having 4 lookup tables for [a], [b], [c], and [d] and then plugging them into a template independently.

</comment></comment></comment><comment><USER11> Oh yes, this is tremendously fun! I worked on i18n/g11n/l10n for Y! World Cup and other games

Compare: <http://us.wc.fantasysports.yahoo.com/> <http://hk.wc.fantasysports.yahoo.com/> <http://tw.wc.fantasysports.yahoo.com/>

It's a tremendous amount of work, and you have to identify translatable phrases AND contexts, not just strings and words. Websites that plan on catering to multiple languages and regions should incorporate i18n from the beginning, not an afterthought, which would require going through lots of code with a fine-toothed comb =)

</comment><comment><USER12> If i18n is a priority on your project, make sure you show your designer(s) this article. With the current trending emphasis on grids and horizontal rhythm, left-aligned labels are quite fashionable.

An effective bandaid solution is to set left-align labels to text-align: right; thereby visually linking the variable width label to the field.

</comment><comment><USER13> Good to see that Hacker News deals correctly with those beautiful glyphs :-)

<comment><USER14> It's pretty hard to screw up copying a string from one place to another without modification, at least when it comes to encodings without null bytes.

Some programs manage it somehow, though.

<comment><USER13> You will be surprised actually how many web apps get this wrong.

</comment></comment></comment><comment><USER15> Good article. Now can anyone recommend a service for replacing the copy in a site with copy in different languages, so I can use my same templates?

Like Google Website Optimizer, but replaces strings with the appropriate language.. ?

</comment><comment><USER16> I'd be interested in knowing what made them write that IntelliJ IDEA provides "decent solutions for bidirectional editing", considering that JetBrains' Dmitry Jemerov has specifically said that they don't see the business case in supporting RTL editing:

<http://youtrack.jetbrains.net/issue/IDEABKL-5572>

</comment><comment><USER17> I just want to point out that the title uses a letter which doesn't exist in any language: t with a cedilla. It's a Unicode fuck up which plagues the romanian language to this day. Not just on computer systems, in real life too!

</comment><comment><USER18> Nothing like early morning Unicode abuse. ;)

</comment><comment><USER19> I'm a web developer with experience of technical editing, a native speaker of Arabic, have translated many popular Firefox extensions to Arabic, and worked in "Google in your language" project, since I speak English and German fluently. I'm willing to help any HN member who wants to localize his startup/website to a RTL language, for free. If you contact me, I will gladly review the Arabic localization and RTL design and help you with the globalization in general in my spare time. As a thank you for the community I'm a big fan of.</comment>


Publish your computer code: it is good enough - <AUTHOR> http://www.nature.com/news/2010/101013/full/467753a.html <comment><USER2> This is such a fundamentally important issue in the sciences. Without the source code, you can not truly do peer review, and you may not be able to replicate someone else's work. With no peer review or replication, you are no longer doing science.

I've seen source code for software used to produce results in major publications like Nature that was so poor quality it is surprising it even compiled. You don't generally get tenure for producing well written software, so there needs to be another incentive for scientists to spend the time to write well thought out and well documented code. I think sunlight helps tremendously.

Warren DeLano, the author of PyMol, the very popular molecular visualization software, was an early voice about the importance of open source software in the sciences. Unfortunately, he is no longer with us, but it is hearting to see others now taking up the cause.

 _The only way to publish software in a scientifically robust manner is to share source code, and that means publishing via the internet in an open- access/open-source fashion._ \- Warren DeLano (2005)

<comment><USER3> I'm not sure sharing code is such a great idea. If you use the other guy's code, you might be replicating the other guy's mistakes. And having the code available encourages that.

It would be better to describe your methods, so someone else can implement it in their preferred tools. If they still replicate your results, that strikes me as being much stronger than just rerunning the same, possibly buggy, code.

I mean, if you're working with monkeys, other scientists can't reuse your monkey. They have to follow the procedures you describe on their own animals.

Another issue is that the code might not be very useful to other labs as-is. The code might be for unique, custom-made hardware, or an unusual configuration of equipment, or in an unusual language.

<comment><USER4> Sharing code doesn't prevent someone else from reimplementing an idea and indeed they should if they rely on results from another publication. If everyone open sources code they wrote during their research then it ought to be easy to tell if someone reimplemented an idea correctly (if their results differ). If they copied the original implementation this should be evident too.

<comment><USER5> But people are people and when there's an easy way...

<comment><USER4> I agree, but at least having implementations in the wild should bring more attention to an idea and scrutiny of that code than none?

<comment><USER3> If the same results are obtained using different code (or subjects/animals/chemical batches) does it matter as long as the code is doing the same things?

I get the impression that software types are inclined to put way too much significance on the source code. I'm not surprised the author of the linked item in Nature is a software engineer.

I wonder, did scientists in the 1930s publish their scratchpads full of calculations?

<comment><USER6> There is a massive difference between a scratchpad of calculations, and a simulation involving thousands or millions of data points.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I debate about this constantly with my office-mate, who--unfortunately-- represents the conservative status quo in science. His concerns are that he is worried about being scooped, and that it's bad science to release things before they are finished products.

I am a proponent of open notebook science, and strongly believe that the benefits outweigh the negatives. Besides the feel-good arguments that this advances science and reproducibility, I'll point out a selfish motivation for releasing code: _It makes it more likely that other researchers actually try your methodology and cite you._

I used to get mired down in trying to do formal releases. Now, I realized that releases are a hindrance, and by default all my research code lives in a github repo from day one:

<http://github.com/turian>

For example, here is the page I published on my word representation research, with links to my github code: <http://metaoptimize.com/projects/wordreprs/>

<comment><USER6> Whether or not he's an open science fan, that's no excuse for him to refuse to publish code when the paper is out.

You should point out that refusing to publish code is like being intentionally hazy about your experimental protocol.

<comment><USER8> I am not sure where the idea that you release the source before publication comes from, but it does seem oddly prevalent given the solution is so easy.

</comment></comment></comment><comment><USER9> One time I worked on a power grid simulation that wanted to release its code but it couldn't because it used algorithms from «Numerical Recipes: The Art of Scientific Computing» which has a pretty asinine copyright policy with respect to openness : <http://www.nr.com/com/info-permissions.html>

Even worse are the researchers who keep their models and data sets secret due to paranoia that some colleague will publish first, which admittedly does happen.

Cultivating a spirit of genuine cooperation and sharing in academia would do wonders for the progress of the sciences, but there are so many hurdles that need to be removed. It's not just a matter of knowing that it's good to release source code or feeling confident in including it as the article suggests.

<comment><USER10> IANAL but as far as I understand copyright law it is impossible to copyright "an algorithm." What one can copyright is source code but as long as you do not copy the source verbatim it is not copyrighted. I would suggest you translate the algorithms from the book into mathematical expressions and then implement your own code from there. This should be legal to publish.

<comment><USER9> In this case it was a derivative work based upon source code from the book, which is permitted under the terms but precludes open dissemination. Further, the rest of the codebase was very tightly coupled to the algorithms since since the algorithms updated state in-place instead of returning values, so dropping in an open version of these algorithms was very non-trivial.

</comment></comment></comment><comment><USER11> I'm currently an engineering masters student, and the code I've written is available on github, if not properly licensed (I'm seriously considering slapping the CRAPL onto it now that I'm aware of it). I don't really care too much about polish, since, I mean, it does what _I_ want, I have the excuse of working around other peoples' software, and at worst someone finds out that I did something wrong, and we all benefit. Plus, having it on github makes it really easy to work on it from different locations, and version control helps me document just where all my friggin' time went.

The biggest concerns I've heard from other researchers (ie, professors) has to do with being beaten at a publish. I think that as long as your paper _itself_ isn't easy to find pre-submission, then you're okay, especially if nobody will really understand what you're doing anyway. So, I'm not too nervous about the prospect. It's just code for now.

Unfortunately, even if scientists release their own code, it's often just a small part of the big picture. In engineering, at least, MATLAB, Mathematica and commercial Finite Element packages are everywhere. My own project uses MATLAB and COMSOL in tandem, meaning that what I wrote only really serves to glue a bunch of completely closed algorithms together. Personally, I'd love to see a completely open, usable and documented FEA stack (which would ideally include an adaptive mesher, some FEM algorithms, a post-process visualizer, and both a gui and a not-shitty scripting API).

<comment><USER12> _I'm currently an engineering masters student, and the code I've written is available on github_

Did you have to clear this with your university/advisor? AFAIK, my university has copyright on code I produce on paid time or using university facilities/equipment, which covers my research and even a good chunk of my homework.

 _meaning that what I wrote only really serves to glue a bunch of completely closed algorithms together_

This is consistent with what I've run across. It seems a lot of research revolves around modifications to an existing system, but in CS, it seems the established code base is more likely to be open source (e.g. Jikes RVM) or be proprietary but still have source code readily available (e.g. SimpleScalar).

<comment><USER11> > Did you have to clear this with your university/advisor?

I don't know if I _had_ to, but I did discuss it with my advisor, mostly due to the "someone could steal my thunder" issue, and we were basically in agreement. I actually have a really cool advisor--I lucked out there.

<comment><USER12> Eh... good enough. I'd do it if I had my advisor's approval (I really doubt he'd give an OK that would get me in trouble).

</comment></comment></comment></comment><comment><USER13> While I strongly believe that scientists should publish their code along with their papers, I do think it has one potential disadvantage. Suppose a scientist writes a big piece of code to some complicated calculations, but makes a subtle mistake somewhere in it (perhaps some parentheses are nested incorrectly). If the code is not published and another scientist comes along to extend the results from the first paper, the first thing he will do is try to replicate the results of the original. If the code is unpublished, the second scientist will have to write the code from scratch, and in doing so will likely catch the original error. But if the code is published, the second scientist will just use the original code and probably won't catch the error. Consequently, the mistake will take much longer to catch, if it's ever caught at all.

The advantages still outweigh the disadvantages, but it's important to remember that there are always trade-offs.

<comment><USER14> I think that to the contrary, that it would allow people to determine whether the original results were due to flawed software by analyzing the code. Subsequent efforts would remain free to create their own implementations from scratch if desired.

<comment><USER13> True, and that's the definite advantage to publishing code. My point is just that if there's a lot of code and error is obscure, it will take a long time to identify the error and the mistake will be propagated in further research. Most scientists using the code will just skim it, see if it gets the results published in the original paper, and then move on. This has been my experience with my own research anyway.

<comment><USER15> I disagree, because your mental model of a large code base that only has _one_ error is absurd. Scientific code is not magically easier to write than real code. Get two random code hacks to write two significantly-sized codebases, say, about the size of a decent web framework, and you won't get one perfect code base and one with a subtle bug that has ramifications down the line. You'll have two code bases so shot through with bugs that they will never reconcile, ever.

The quality issues aren't all that different than a web framework, either. Release one or a small number of code bases, and have everybody pound on and improve them, and you might get somewhere. Have everybody write their own code bases from scratch every time and you'll get yourself the scientific equivalent of [http://osvdb.org/search?search[vuln_title]=php&search[te...](http://osvdb.org/search?search\[vuln_title\]=php&search\[text_type\]=alltext) .

To be honest at this point when I see a news article that says anything about a "computer model" I _almost_ immediately tune out. The exception is that I read for some sign that the model has been verified against the real world; for instance, protein folding models don't bother me for that reason. But this is the exception, not the rule. When it became acceptable "science" to build immense computer models with no particular need to check them against reality before running off and announcing immense world-shattering results I'm not exactly sure, but it was a great loss to humanity.

</comment></comment></comment></comment><comment><USER16> I must admit that I have mixed feelings about this. Usually I post on my Python blog some code that might not be perfect or good enough but does the job for me. I post to show other people with no CS formation like me that they can achieve things with the language. The programming crowd that visit my blog, helps a lot, the science (biology, bioinformatics) crowd calls me dumb (not directly). I don't know if I would publish my code, I know my limitations and what in knowledge, but in a vain environment like the academic/scientific, I prefer to hide my shortcomings.

<comment><USER17> Why don't you put your blog url in your profile?

<comment><USER16> just did, if you want to check

python.genedrift.org

</comment></comment></comment><comment><USER6> As a scientific programmer/data scientist at a university, I wish I could upvote this twice. I'll be forwarding this one around my lab.

Another issue well as code quality, transparency, reproducibility etc. is simply reuse. There's a lot of wasted effort in academia where people are constantly reimplementing simple things from scratch that do basically the same thing as their peers' code does.

Okay, this is true in other fields too, but in our field it's public money getting wasted.

</comment><comment><AUTHOR> In addition to the common excuses that Nick Barnes mentions in his article in Nature, one reason why scientists did not freely provide their code was the fear of potential misuse of their software (since erratic publications using their software could harm their reputation). The common solution to this problem was to impose a barrier to entry by charging a fee. Many of the early examples of complicated scientific software used this policy:

<http://yuri.harvard.edu/>

<http://ambermd.org/#obtain>

[http://cms.mpi.univie.ac.at/vasp/vasp/How_obtain_VASP_packag...](http://cms.mpi.univie.ac.at/vasp/vasp/How_obtain_VASP_package.html)

Due to advances in computer literacy and the creation of competing projects, the landscape has been changing in recent years:

[http://en.wikipedia.org/wiki/List_of_software_for_molecular_...](http://en.wikipedia.org/wiki/List_of_software_for_molecular_mechanics_modeling)

[http://en.wikipedia.org/wiki/Quantum_chemistry_computer_prog...](http://en.wikipedia.org/wiki/Quantum_chemistry_computer_programs)

<comment><USER3> Those packages are rather different from a given scientist's code for a given paper. These are big, mature projects, probably multi-lab or department-wide, long-term efforts, to develop a shared foundation for work in a given field.

The code actually corresponding to a given paper is likely to be a small amount that builds on packages such as those above, or products like Matlab, whatever. There could be code to implement an experiment, and Matlab code to analyze the data.

<comment><AUTHOR> Agreed. Sharing these big, mature, foundation frameworks is essential for the reproducibility of published research. The additional convenience scripts that accompany a paper are often described or provided in the methods and supplement. As a reviewer, I block papers that lack unambiguous information allowing their reproduction, but I don't penalize the lack of explicit convenience scripts, since these can be reproduced or provided from the authors upon request.

</comment></comment></comment><comment><USER18> I go even further and am of the opinion that data provenance is the overarching issue. Any series of results should be able to be re-generated quickly (as measured in scientist-time not computer-time) based solely on meta-data provided–and this is the key point–as part of the results themselves. A few simple guiding principles could go a long way toward achieving this goal.

       1. In the absence of a well defined standard, it's the individual scientist's/consortium's responsibility to define and actively use an organized meta-data standard.
       2. If it's not open source it's not science.
       3. A snapshot of the source code used to generate results should be given/pointed to when the results are presented.
       4. Minimizing reproduction time is an integral part of science.
       5. Principles 1-4 should be be demanded, by funding agencies, program heads, and research advisors.

</comment><comment><USER19> See also the CRAPL: <http://matt.might.net/articles/crapl/>

<comment><USER20> The pronounced acronym is appropriate for academia. It contains both words that come to mind.

</comment></comment><comment><USER21> Scientists sometimes do publish their software. An example: in Operations Research, the COIN-OR initiative (<http://www.coin-or.org>) is a growing set of (Open Source) tools for solving OR problems.

Also, in certain disciplines, not only papers, but also the software used to obtain the published result is peer reviewed. For instance, the journal Mathematical Programming Computation (<http://www2.isye.gatech.edu/~wcook/mpc/index.html>) accepts papers accompanied by the software used by the authors, which is tested and reviewed by technical editors.

</comment><comment><USER22> Some journals already require this.

[http://www.econometricsociety.org/submissions.asp#Replicatio...](http://www.econometricsociety.org/submissions.asp#Replication)</comment>


Intel Announces Xeon Phi Co-Processors - <AUTHOR> http://www.anandtech.com/show/6017/intel-announces-xeon-phi-family-of-coprocessors-mic-goes-retail <comment><USER2> Note: the instruction set and open source software stack are available:

[http://software.intel.com/en-us/blogs/2012/06/05/knights- cor...](http://software.intel.com/en-us/blogs/2012/06/05/knights-corner-open- source-software-stack/)

[http://software.intel.com/en- us/forums/showthread.php?t=1054...](http://software.intel.com/en- us/forums/showthread.php?t=105443)

<comment><USER3> So this means that each core is running its own version of Red Hat or some other Linux? Does that mean that I can install my own software on those ah, tiny machines?

Someone may probably get mad or think I am stupid for asking this, but can I install node.js on each core?

<comment><USER4> It's probably going to be a small RTOS in each core

Or like it's done in PS3, where you have one core scheduling the others

"but can I install node.js on each core?" maybe, but that's really not the idea

<comment><USER3> ok whats the idea then, how am I supposed to program the tiny machines/cores?

<comment><USER5> Have a look at OpenCL, I think you will use OpenCL or a similar framework to code for this device.

</comment></comment></comment></comment></comment><comment><USER6> Seems like the tl;dr is: 50+ x86 cores with RAM and CPU soldered to PCIe boards.

In other words, a mix of CPU and GPU. A standard architecture, as opposed to GPU private architectures, many cores, and faster memory pipelines.

Now, where did I put that functional programming book..

</comment><comment><USER7> Hmm, the Mac Pro has Xeon processors and PCIe slots. People were complaining just recently about the lack of Mac Pro updates.

I assume some of Apple's professional video tools, at least, are CPU-bound. They'd probably love to have an "add 50 more processors" option for Mac Pros.

<comment><USER8> The Phi cores are really slow unless you use the SIMD unit; the typical way to do that would be OpenCL, but you can run OpenCL code faster on your GPU.

</comment></comment><comment><USER9> Okay, I'm a little confused. What exactly is a Co-Prossessor? It looks like a graphics card. Will it replace the graphics cards or work alongside it? Does it only handle highly parallel tasks, with the processor handling serials tasks?

<comment><USER10> <http://en.wikipedia.org/wiki/Coprocessor>

Yes, the idea is that you will offload highly parallel tasks to it while the main CPU handles serial tasks.

<comment><USER11> While we're adding relevant Wikipedia links,

<http://en.wikipedia.org/wiki/Heterogeneous_computing>

</comment></comment></comment><comment><USER12> If Xeon Phi is going to run linux out of the box, then that's Intel basically declaring that they want this card to be supported by the opensource community from day one, correct?

Correct me if I'm wrong, but it seems to me that the Xeon Phi is only going to be useful to open source developers early on, and then as libraries are built that make use of the Xeon Phi, application developers will be able to build on top of those libraries. So we're probably a long way off (and likely a few different shifts in co-processor technology) before a card like this is useful to the typical, end user.

<comment><USER8> Realistically Intel is going to provide the libraries like the OpenCL runtime.

</comment></comment><comment><USER13> Little low on technical detail. "Works synergistically with Intel(R) Xeon(R) Processor", honestly!

Interesting though: will it be developed into a graphics board, returning to Larabee? What will NVidia and AMD (ATI) do in response?

<comment><USER14> Looks like Intel is trying to attack the CUDA/Stream market. I'm curious to see how NVidia and ATI will respond.

<comment><USER15> s/ATI/AMD/

</comment></comment></comment><comment><USER16> Now, I'd love to see one with hardware-assisted transactional memory like the newest POWER machines. A standard HTM implementation for x64 ISA machines would be a huge leap forward.

<comment><USER17> The future "Haswell" chips are going to have support for transactional memory.

No news on these guys though. Give it time. In a few years these things will be getting up to speed in features/RAS and such.

</comment></comment><comment><USER18> Xeon works "synergistically" with Xeon Phi ;)

</comment><comment><USER19> Any word on what the cost of this card will be?

</comment><comment><USER20> The 80s called. They'd like their co-processors back!

<comment><USER16> I'm quite sure my Apple II didn't have 50+ cores.

<comment><USER21> That would be a funky looking apple...</comment></comment></comment>


Radiolab on the life of Alan Turing - <AUTHOR> http://www.radiolab.org/blogs/radiolab-blog/2012/mar/19/turing-problem/

<comment><USER2> Includes James Gleick. _The Information_ was so awesome!

</comment><comment><USER3> Beautiful story.</comment>


Teams Stopped Working on Firefox - <AUTHOR> Since today I am not able to attend Teams meetings anymore with Firefox. It forces me to download the application.
The application does not work well with screensharing on RHEL (Fedora). So instead of Firefox I tried Chromium with out fo the box settings. In Chromium I keep getting an error while trying to attend a meeting.  (To open the web app, you need to change your browser settings to allow third-party cookies.)
So now I installed Chrome. And it works immediately. So there we are Micro$oft. You are pushing your new Edge Chromium browser to the big audience over a forced update. You are one of the biggest companies working on the Linux kernel. But I think we can all agree that this is going to be the next Java situation. <comment><USER2> Same story, chromium does not working properly.

</comment><comment><USER3> Maybe Firefox can patch something?</comment>


What will be the legacy of Go? - <AUTHOR> http://dave.cheney.net/2015/11/15/the-legacy-of-go <comment><USER4> Go was written to solve an internal problem at Google. Google needed efficient server side applications. Python was too slow, and C++ was too hard to write, too buggy, and a pain for string work. Google then developed good-quality libraries for all the things one needs for such applications. That made it an excellent language for server side work.

As a language in general, Go is practical and mediocre. This may be a strength. Go lacks generics, and thus has to over-use introspection. In practice, while "interface{}" implies extra run-time work, it tends not to end up in compute bound code. (Two notable exceptions: sorting and database access.) So that turned out to be less of a hassle than expected. Also, from Google's internal perspective, they're mostly using their own data structures, and type-specific code may not be a big problem.

Go's approach to concurrency hand-waves too much on the data sharing issue, and has soundness problems, but at least the language talks about concurrency and has some reasonable primitives. C and C++ don't even provide syntax for talking about concurrency.

</comment><comment><USER5> The C section is so wrong it's unbelievable. Or why I created the Pastebin below. There were plenty of good languages before C, not just asm. C wasn't designed: a tweaked BCPL and B to work with PDP-11. C wasn't even meant to be portable.

[http://pastebin.com/UAQaWuWG](http://pastebin.com/UAQaWuWG)

Helps to understand what it is exactly and then the rest (like ditching it) becomes more obvious. P-code was probably the first portable, assembly language with good results. Or LISP from the functional side.

<comment><USER6> Thanks for the illuminating link.

Nevertheless, I unfortunately do not see an easy solution in the near future that avoids C/C++ much as I would love to ditch them. Let us leave aside the question of legacy code and focus on future systems projects.

General issue: C and C++ have an advantage in the sense that we understand their many problems well due to their long history, and they have formal specs that are far more carefully written than most others, where documentation is spotty and formal specs are often lacking. Example: I have not studied Rust closely, but it seems to me that there are sections that essentially must be placed under "unsafe" for performance or low level access. The oft-repeated claim is that it minimizes the surface, since it localizes the unsafe sections. I have not seen any hard, formal guarantees in either the spec or implementation as to what is precisely meant by this. I am very interested to know how I can reason that the unsafe section has zero side effects outside of it. Such a statement in general must be false, since the unsafe block clearly communicates with the rest of the program, else it is dead code. And if the interface is sandboxed (an imperfect solution), then it implies some kind of performance penalty across the barrier, implying additional cognitive load for a developer since he/she has to reason about the possible performance impacts for such things, among others like array bounds checks. Lastly, if the guarantee regarding the extent of the "unsafe" block is as complicated as I suspect it to be, the load is increased further. Of course, the load comment is really relevant to Rust vs C and not Rust vs C++.

Specifics: 1\. Go - garbage collector, large runtime/binary sizes, portability issues (AIX: [https://groups.google.com/forum/#!topic/golang- nuts/IBi9wqn_...](https://groups.google.com/forum/#!topic/golang- nuts/IBi9wqn__FY)). 2\. Rust - too new, general points above. 3\. D - <USER2> the same energy as the above projects, so likely fares worse than the above. Furthermore, due to its closer ties to C++, its rather incremental nature resulted in a significant loss when C++11/C++14 came around. 4\. Others - <USER3> many to list, focused on above due to their frequency on Hacker News.

<comment><USER7> Focusing on Rust "unsafe" as some sort of way to ding its safety drives me crazy.

"unsafe" blocks in Rust is designed to be just like the compiler backend. We could have built things like Vec::new and vector indexing into the code generator, like Go or Java did. Then we wouldn't need the "unsafe" construct in the language (except to interface with kernel32.dll and/or syscalls). But that would make our lives harder _for absolutely no extra safety gain_. It's precisely the same thing as implementing things in the compiler backend, but it's _safer_ than doing that, because we get to write code in a stronger type system than that of raw LLVM.

More succinctly: What makes the compiler backend safe while unsafe blocks are not? Can you name one thing that makes the compiler backend safer than code written in unsafe blocks?

<comment><USER6> I did not "ding" it, but asked for an honest, transparent response if available. It can only help the Rust community by making such things clear. I focused on it as it is what I got probing Rust since after all there can be "no free lunch".

The compiler backend may be viewed as a smaller component that needs to be trusted. General code lies on top of it, and there is a big difference due to code volume.

<comment><USER7> I don't understand what "there is a big difference due to code volume" means.

<comment><USER6> I was referring to all usage of Rust by clients across the world versus a single compiler and reference standard library. Many of these clients will need "unsafe" blocks, and the combined length of these "unsafe" blocks will exceed that of the standard library and compiler assuming Rust adoption is high.

This is what concerns me: I wished Rust's "unsafe" blocks could have been exclusively confined to some things in the reference language compiler and standard library. Unfortunately, it seems like many reasonable systems applications still need access to unsafe blocks for reasons of performance, low level access, etc and such needs are not uncommon given the target systems audience.

<comment><USER8>
      > I wished Rust's "unsafe" blocks could have been
      > exclusively confined to some things in the reference
      > language compiler and standard library.

This sadly isn't possible in a language at the systems level. If you don't provide an escape hatch then users will just use the C FFI as an escape hatch, which results in far more potential unsafety than Rust's `unsafe` blocks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I think Go will ultimately be remembered for reaffirming the importance of single binary deployments.

The world of deployments e.g. build scripts, containers, extravagant tools are all unnecessary with Go. And I suspect future languages will learn from this.

The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have.

<comment><USER10> I think the single most important 'thing' go offers is his third point. The removal of the thread. The ability to very easily run multiple concurrent pieces of code cannot be understated. I have my grievances with go as i do with every other language, but what makes me more or less automatically start most new projects in go is that i know that at some point i will probably be sending the same http request to N servers or some variation of a similar task, and even if it can be made to work in any other language, the ease of which it is done in go keeps me coming back.

As an aside i think the composition over inheritance argument deserves a mention. The io.Reader and io.Writer interfaces () and their close friends io.ReadCloser, io.ReadWriter etc) have completely transformed how i approach tasks that involve shifting data through a number of whatevers.

<comment><USER11> What do you mean by "removal of the thread?" Go is multithreaded and is vulnerable to classic thread-safety issues, like races and reentrancy.

<comment><USER12> Go runtime library contains user-space scheduler which maps lightweight Go threads to heavyweight OS threads in M:N manner. By the way, Go runtime library allows running user code in only one OS thread per process, all other OS threads must be in the state of blocking system call. So, no mutexes / interlocked instructions are required to access global data from goroutines, but this comes at the cost of reduced parallelism compared to C/C++ (which author of original article seems to be unaware of).

<comment><USER13> Wow, uh no. You're 100% wrong, unless I'm misunderstanding you. You can absolutely have user code running on N threads simultaneously (where N is the number of cores of your machine). And you definitely do need mutexes.

Your statement holds only if GOMAXPROCS is 1, which granted used to be the default, but was always able to be increased, and the default now is the number of cores on the machine.

<comment><USER12> Ah, now I see these things changed recently. I wrote original comment because at the time of Go 1.1 or 1.2 my colleague wrote racy code which accessed global variable without mutexes. I tried to educate him to use mutexes, by reducing his code to the minimal version demonstrating race condition, but failed. Then I digged into the source code of Go runtime library and discovered that only one thread could be in the running state at any moment (other threads could be in the state of blocking system call).

So, things changed since that time. OK, nice to see Go evolves. Interesting, how many code in production got broken during upgrade to Go 1.5 due to this backwards-incompatible change. Overall situation seemed totally reasonable to me at that time: Go is a language for average programmer, so it should prefer safely over runtime performance; and coding cowboys who are comfortable with mutexes, interlocked instructions, memory barrier instructions, and lock-free data structures will use C/C++ anyway.

<comment><USER14> But that wasn't true either at the time of Go 1.1, nor ever I believe. It was the _default_ behavior to have a single core running at a time, but you could just tweak that with the [GOMAXPROCS]([https://godoc.org/runtime#GOMAXPROCS](https://godoc.org/runtime#GOMAXPROCS)) variable, documented everywhere. (That's what changed in Go 1.5; now the default for GOMAXPROCS is the number of cores in the machine.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> The legacy of Go will be a movement by many developers to statically typed, compiled languages after spending many years with Python, Ruby, and Javascript.

Although it is not groundbreaking, it will continue to be used because it takes the ease of dynamically typed languages and gives you fast compilation.

</comment><comment><USER16> Perl: the language that showed us brevity.

Despite all its various layers of madness, it made a generation of programmers more productive than they'd known was possible. Tasks that used to be major undertakings often boiled down to simple scripts. Python, Ruby and many other languages since have borrowed from and built upon the brevity that Perl first showed us and it's unlikely that people will ever go back to the verbosity that used to be common for text processing and sys admin tasks.

</comment><comment><USER17> > Go is still young, with a long productive life ahead of it [...] compared to > the number of people who will use Go during its lifetime, we are but a tiny > fraction

An assumption lurking in the last paragraph. Remember JavaFX and Dart, both languages backed by large corps who then pulled their support. Go could be at the peak of its popularity, about to tank. We don't know.

<comment><USER18> I'm thinking of Turbo Pascal for DOS. It was very popular, and then it sank to obscurity almost overnight, basically because it didn't have any answer to "how do I write a Windows program in this?" Its niche had been eliminated.

I don't think Go will vanish unless "network servers that run in text mode on unix" somehow stop being a thing. There is no Google product whose change of strategy could strand Go (unlike the others you name). If somehow all computing moves to phones and tablets, it could be stranded, but I can't imagine that happening.

<comment><USER19> Was it not reborn as Delphi? It was always Pascal. But I do agree, a non- visual service lang is probably a thing.

<comment><USER20> Delphi was really not so bad. Back in High School we first learned with Pascal, then Delphi. It was pretty simple to put together simple Windows GUI Programs. Never really used it outside of school though.

<comment><USER21> > It was pretty simple to put together simple Windows GUI Programs.

It was one of the most powerful Windows (GUI) programming tool back then, and easy to create beautiful UI components and had great third-party components market. Plus it has incredible compilation speed.

</comment></comment></comment></comment></comment><comment><USER22> "I mean, who doesn't want to be simple ? And what better way to frame a debate as simple; good, complexity; obviously bad. Could we say then that simplicity will be Go's lasting legacy ?"

I think this misses the point. Complexity isn't bad. Only Incidental complexity is bad. Inherent complexity exists in the domain itself and is unavoidable. If this inherent complexity is not expressible by abstractions in the core language itself. Then it must be expressed in libraries, or user code, or in the way end-users configure and use the program.

Go is interesting because it created abstractions for concurrency in the core language itself. Go is a more complex language because of it, but concurrent programs user code is less complex because of it.

(On a side note C++17 is getting a more abstract version of go-routines. Thanks Go.)

<comment><USER23> Co-routines go back to Modula-2 (1978) and first COBOL optimizing compilers, Go didn't invent anything there.

<comment><USER24> More recent inspirations: Win16/32 API has "Fibers" (used in WinWord), Lua has coroutines.

</comment></comment></comment><comment><USER25> Minor nit re: Rails legacy. IMO a major reason it was so popular was because of Ruby. It's certainly not the right hammer for every nail but the syntax is one of the best to work with ever. Whenever I can find a project where writing a little Ruby makes sense I use it. Because I enjoy it :)

While it's useful to me and dominates what I code in atm, I don't necessarily like writing Go. Better than C/C++, sure, but I wouldn't go so far as to say I enjoy it.

<comment><USER26> Have you tried Crystal? I used to think I loved Ruby for its syntax, until I tried Crystal, then I found out that Ruby's dynamic typing and the sublime object model are just as important, if not more important, than the syntax.

</comment></comment><comment><USER24> C, C++ and Go are going strong. All operating system kernels we currently use are in C, as well as most low level drivers and libraries. Most PC client applications are in C++ including most video games. Common web servers are in C. They will be around for many more decades.

Go already replaces Java and dotNet as a leaner more suitable server language in some companies. Nodejs and Go apps (+ JS in the web browser) replace older CRUD web apps written in Ruby/Python/Perl. Most languages will stay around for a long time, although a less popular for beginners.

Java and dotNet will have a harder stand. On the one hand dynamic typed languages like Lua, Javascript and Hack/PHP with their JIT compilers are already (almost) as fast and allow developers to be more productive while still offering optional typing when/where speed matters. On the other hand new static compiled languages get more approachable (Go, Rust, Swift), are faster and use less memory.

Paradigm shifts surfaced exotic languages and trends. So Erland/Elixir, Go, Nodejs and others are very popular for todays web services.

<comment><USER23> Java and .NET have AOT compilers so compilation to native code is not a point.

They have support for generics and FP like programming that Go will never get.

Go will never have the access to the system resources on Windows and Windows Store like .NET does.

Go will never had access to Android frameworks like Java does.

Go doesn't have a UI toolkit like JavaFX and XAML.

All companies selling IoT SDKs are paring Java with C stacks.

Go doesn't have the IDE tooling support that Java and .NET enjoy.

Java and .NET having a hard time? Only if one is living in a bubble.

<comment><USER24> Some of your info is a bit outdated.

Speaking of Go, it's appearently commonly used for server side services/apps. Well the same can be said for Java and C#/F#/VBNet.

All applications we all use on the client side are C/C++/ObjectC/web apps. (exceptions are maybe Eclipse/IntelliJ, mind that Visual Studio is C++). Java on Android is an exception for legacy reasons (Google bought the Android company; and we pay the price buy using 2x-4x as powerful hardware (CPU cores & memory) comparing to iPhone to get similar UX & latency). Even the Win10 startmenu is still a C++ application for performance reasons. AOT is helpful for certain execution paths like JIT and isn't magic. Even the Win8/10 calculator app has a loading splash screen, the FirefoxOS calc app starts faster. XML based UI languages work, but aren't that great (e.g. resizing the Win10 startmenu isn't what I would call responsive design in comparision what we known from HTML5&CSS3).

Beside that you wrote a good comment above: [https://news.ycombinator.com/item?id=10568915](https://news.ycombinator.com/item?id=10568915)

<comment><USER23> > ll applications we all use on the client side are C/C++/ObjectC/web apps.

Not every company is the same.

Since when does Apple have server frameworks for Objective-C?

WebObjects was re-written in Java.

My current customer uses everything native, with web apps just for small CRUD maintenance tasks of a few DB systems.

> Visual Studio is C++

Visual Studio is a mix of C++ and .NET code, its UI infrastructure was completely rewritten in VS 2010.

> Even the Win10 startmenu is still a C++ application for performance reasons.

Have you seen the code? How sure are you that it isn't .NET Native?

> Even the Win8/10 calculator app has a loading splash screen,

Anyone that knows WP dev, knows those splash screens are optional.

> the FirefoxOS calc app starts faster.

Which is behind WP and BlackBerry in sales.

</comment></comment></comment></comment><comment><USER27> > I think a strong contender could be a lack of inheritance; _Go took away > subtypes._ [emphasis mine]

Go took away subtypes? News to me.

</comment><comment><USER28> I'm not sure Go will have a legacy in 50 years. If you gave me even odds I'd go with none.

<comment><USER29> Care to explain why? This comment doesn't really say anything without an explanation.

<comment><USER28> Most programming languages don't have a legacy. They're just forgotten. That's the default. So far I've not seen anything from Go to make me think it will be more than a footnote.

<comment><USER30> How about Docker and other tools in the container space?

Go is a great systems language. The stdlib is through and handling IO and pipes is safe and fast.

Amazon is using as the mission critical ecs-agent that orchestrates their container service.

Perhaps containers will be forgotten too. But my guess is that we will be seeing some go binaries controlling very important parts of Linux and distributed systems in the far future.

<comment><USER31> Go is problematic as a systems language. Calling it safe is odd, when it's glaringly allowed for Null. It's safe like Java is safe, which means that the memory will always be safe to use, but the program will still die due to bugs that a compiler could have helped prevent.

As a comparison Rust has no runtime, has no garbage collector, and is a pure systems language, and also helps developers be truly safe. Based on my experience with Go, I still don't understand where it fits, it's a compiled language, but has a runtime and a GC. So it's somewhere between C++ and Java, it's less verbose and faster to program in, but if that's the desire, than perhaps the better choice will be Kotlin in the long run.

<comment><USER32> > which means that the memory will always be safe to use

In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access".

A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim?

[1] [http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not- co...](http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors)

<comment><USER33> Dereferencing nil is not an unsafe memory access in Go, just like a null pointer exception in Java isn't unsafe. Both are well-defined operations (sure, they yield errors, but they do so with 100% reliability and complete control), they're not undefined behaviour like in C or C++.

Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)

<comment><USER32> Thanks for the clarification! What if instead of the sender goroutine setting the pointer to nil, the GC frees the object that the pointer was pointing to before the recipient goroutine reads it? Wouldn't that be considered "reading from a pointer that has already been freed"?

<comment><USER34> That can't happen. The GC won't free the object until nothing references it, and in your proposed scenario either the channel or receiving goroutine will have a valid reference.

<comment><USER32> Thanks for the explanation. I didn't realize Go's GC also worked for pointers/references.

<comment><USER32> Let me qualify that: work for them _across goroutines_

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Docker

</comment><comment><USER36> As a slightly improved perl that really didn't change anything about languages.</comment>


Ask HN: Anyone use 'smart glasses' as primary coding monitor? - <AUTHOR> Just wanted to check in and see if anyone here has ever tried using a pair of 'smart' glasses (VR / AR / ? ...) to program with.  I'm thinking of something simple with an HDMI input I can just plug into my thunderbolt port and project my IDE /  web browser onto.
Background:  I tend to sit in a reclined position with my feet elevated when I code but my neck and upper back then have to strain to look at what I'm doing on the screen.  If I could fully recline with a head mounted display I think it would take some of the strain off.  I realize a standing desk is an option to avoid neck strain but I'm curious about the glasses use case.
It seems like the wild west out there right now in terms of modes, options, models and price points so was hoping to tap the collective here to avoid problems.
I'm not looking for AR or 3D capabilities, just large format immersive (probably some translucence).
Here's a couple of links for reference: https://www.youtube.com/watch?v=yRFv9XxXnh0 https://www.youtube.com/watch?v=bYPmpMPLa6Y&t=687s <comment><USER2> I've had some times in the past where my chair was really causing me discomfort. I thought it would be nice to be able to do something similar-- perhaps even lay down with one of those split ergonomic keyboards. (I rarely use a mouse)

I didn't find much during my investigation at the time, but this was a couple of years ago. There were some VR headsets that people had hacked up to show a terminal, but not much beyond that.</comment>


1. Design; 2. Slicy; 3. Profit - Tim Van Damme - <AUTHOR> http://macrabbit.com/slicy/#

<comment><USER2> Very nice job, manual cutups are definitely a bit of a chore and having the assets update automatically is sweet. I take it you have to save the assets again after an update in photoshop though? If that is the case maybe you could serve the assets on localhost? This would be incredibly useful, it would mean I could save changes in photoshop and then refresh a web page and see the updates.</comment>


Bitcoin energy consumption surpasses Switzerland - <AUTHOR> https://www.bbc.co.uk/news/technology-48853230 <comment><USER2> Strange that nobody says anything about Christmas lights.</comment>


Come on in my kitchen ... - <AUTHOR> http://www.google.com/gwt/n?u=http%3A%2F%2Fpsoup.math.wisc.edu%2Fwelcome.html <comment><USER2> Direct link without the Google wrapper: <http://psoup.math.wisc.edu/welcome.html></comment>


Ask HN: (UK) Do you use the giffgaff mobile network? - <AUTHOR>

I only heard of this mobile network today and wondered if any of you in the UK had used it. It appears to be tailor-made for savvy smartphone users:
http://giffgaff.com/index/pricing
It's a separately branded sim-only service run by 02. The main attraction is genuinely unlimited mobile internet (if you order at some point this month, excludes tethering).
Any thoughts? Pitfalls? Too good to be true?
(Sorry if this sounds like a plug. It really isn't.) <comment><USER2> I've been using giffgaff since December. The signal coverage isn't great (but this seems to be a general issue in UK) and the internet connection sometimes isn't perfectly stable. Personally, I find this tolerable and the prices are great. The internet connection is genuinely unlimited - but you'll get a warning if you constantly use more than 100MB/day.</comment>


Ask HN: Different Types of Productivity - <AUTHOR> Is it better to intensely productive in bursts, or mildly productive consistently?
I'm wondering if one way is better than the other. In my case, I'm able to be very productive for a few days, but then I usually have a slump where I get bored easily and find it hard to focus (lasts a day or two). Some people are more consistently productive, but probably not as intensely so. I'm guessing it's not healthy to always be 100% productive.
If it's the case that one is better than the other, is it possible to shift your productivity habit? How might you do so? <comment><USER2> I don't know what's better, but I tend to run hot and cold like you.

</comment><comment><USER3> I don't think you can make a normative statement like "better" about this as far as comparing the two goes.

I can say that my productivity as a programmer has traditionally been very bursty and requires long blocks of time and isolation.

This is the traditional (PG APPROVED!) understanding of programmer productivity. That said, I've been getting better at becoming more consistently productive of late.

I think it has more to do with the individual and the task than anything.

<comment><AUTHOR> I guess by 'better,' I meant the amount of output produced by one style or the other. Would there be a repeatable and measurable difference in the amount of output from someone who is bursty productive than from someone who is consistently productive?

Have you started doing anything different or made any changes to your working style that have led you to become more consistently productive?

<comment><USER3> >Would there be a repeatable and measurable difference in the amount of output from someone who is bursty productive than from someone who is consistently productive?

Nope. Never. Sounds like a CTO/CIO's pipe-dream.

It's a personal thing that likely has little correlation with overall productivity, and most programmers are bursty.

If you want to help programmers be productive, make them happy and give them the working environment they crave. Whatever that may be.

>Have you started doing anything different or made any changes to your working style that have led you to become more consistently productive?

The only change I've made recently that I'm convinced made a sustainable uptick in my productivity _personally_ (not applicable to everyone) is that I've started following Seinfeld's and many other writers advice.

I just make certain I write code everyday and if I'm stuck I force myself to start sketching out boilerplate/rough-ideas until I get unstuck.</comment></comment></comment>


Typographer Erik Spiekermann on iOS 7 [German] - <AUTHOR> http://www.youtube.com/watch?v=Sw0syzCeH4Q

<comment><USER2> English subtitles are provided, as well.

</comment><comment><USER3> I have no doubt that IOS7 will change before it is finally released as Apple will be listening to reactions very carefully, but there is one thing that all these purist designers forget. IOS isn't designed for their approval, it is designed to appeal to IOS users en-masse and to distinguish IOS7 from previous versions.

For example, whether these people think Helevetica light is inappropriate for this kind of usage is irrelevant. Now if the objections were on the grounds of reduced accessibility, that would be very different but it seems to me that lots of designers (and Spiekermann is very eminent) are just unhappy that their established rules are being ignored. So be it, that is change. Whether the change is successful remains to be seen.

<comment><USER4> > IOS isn't designed for their approval, it is designed to appeal to IOS users > en-masse and to distinguish IOS7 from previous versions.

If Apple produces something beautiful, it's a sign that they employ the most talented designers and are at the bleeding edge of design.

If Apple produces a cheap rip off of Windows Phone, it's because they care so, so much for their users.

Got it.

</comment></comment><comment><USER5> Here's a related articled that can be translated.

[http://www.mactechnews.de/news/article/Schriftgestalter- Erik...](http://www.mactechnews.de/news/article/Schriftgestalter-Erik- Spiekermann-kritisiert-Schriftwahl-in-iOS-7-156006.html)</comment>


Ask HN: what would happen if the US defaulted? - <AUTHOR> <comment><USER2> Nobody really knows.

We have a good idea that it would be bad (worse than if the .gov hadn't stepped in to prop up the economy in 2008) but the actual practical consequences are literally unknowable.

If you're nihilistic you may think that a disruption like this would be a salutary thing for the United States forcing us into the long overdue reappraisal of our place in the world and our ability to dictate terms to the rest of the planet. But the truth of the matter is that our far flung logistical system means that many of us are more dependent on global trade than we realise and that a sovereign default on the part of the United States of America would have repercussions that will affect pretty much everyone on the planet who has an electrical outlet in their house.

Fucking with the flow of money at that scale will certainly cause chaos and civil disorder as primary effects, but it will also disable most of the tools we have to control chaos and civil disorder.

Think of it as being like a power outage, only it's a money outage. Your bank won't be able to count on getting it's regular operating loans, your employers bank, the same, various payments into the system for housing vouchers, food stamps, agricultural subsidies, road construction contracts , all the paper that keeps our society from collapsing will stop moving. Some of it may resume, but if enough of the economy is broken...

So best case scenario: economic hardship, generational unemployment, millions of people displaced from their homes, and the US can wave bye bye to the dream of hegemonic leadership, economic or military, for the foreseeable future.

Worst case scenario: War. It is traditionally the cause and cure of sovereign default. And while we (the US of A) are currently fighting multiple colonial wars (mideast, north africa, south america) which is part of what has spun up the numbers on the debt; we have not really begun to tap our poulations war making capabilities, one of the few untapped resources we have left.

<comment><USER3> The US won't default unless the President chooses to, there is still plenty of money to make the interest payments on the debt, it's under 10% of revenue. All we have to do to balance the budget is go back to what we were spending 8 years ago... Only 8 years ago... That's how much the government has increased.

What would happen is the government would be forced to make cuts in other areas. There is still enough money for most of the entitlements and the military but other areas would undergo drastic cuts.

Government Spending to stimulate the economy doesn't work, the best quote is from FDR's own Treasury Secretary and creator of the New Deal where he said in front of congress, "We have tried spending money. We are spending more than we have ever spent before and it does not work... I want to see this country prosperous. I want to see people get a job. I want to see people get enough to eat. We have never made good on our promises... I say after eight years of this Administration we have just as much unemployment as when we started. And an enormous debt to boot!"

<comment><USER4> If only it were that easy. The president doesn't have a magic "get things done" button, unfortunately. He must pass everything through congress. That's the entire issue with the debt ceiling. If he cannot act - whatever the action, then we will default.

<comment><USER3> Actually he does have the right to prioritize spending in such an instance and therefore does not need congressional approval. It's a power of the Treasury Secretary. Clinton did it in '95 during the government shutdown.

</comment></comment></comment></comment><comment><USER5> It's not likely to happen (sorry for bypassing the answer).

Simply because the international impact would be too big. Too many international trades rely on the US dollar. Until the Yuan takes over (speculative(!), if it would, in the next 50 years) the US is pretty much safe from defaulting.

If it really did, it'd be the end of the global keynesian economies and throw us back in pre-globalization.

Most economy would pull back from global exposure (that's non-realistic). Although we're seeing this on a small scale (when France refuses to adopt more EU policies for example, or when all EU goes pissed at Greece (particularly Germany)), it just won't happen.

What's going to happen, is massive sweeping under the carpets, "deal with it later", and a whole bunch of plans to lower debt-creep and keep face publicly.

Think of it as, bumping a massive bug to "next version" in the understanding that everyone already knows about it, and it's can of worms that would require too many structural changes, to the point that it would change the nature of the software itself.

<comment><USER2> If it weren't for the fact that there is a simple straightforward known solution to the problem: fixing the revenue side of the equation.

If we reset tax rates to what they were under Bill Clinton the deficit would be falling, not rising...

[http://en.wikipedia.org/wiki/National_debt_by_U.S._president...](http://en.wikipedia.org/wiki/National_debt_by_U.S._presidential_terms)

Notice when the the numbers start climbing...

Undoing GWB's shenanigans would have us back on the right track tomorrow. But that is apparently an unthinkable concept in the current political climate.

<comment><USER6> Both Clinton and Bush barely touched the revenue side of the equation. Revenue was 18.6% during the Clinton era and 18.0% during the Bush era.

Under Clinton, spending was reduced. Bush reversed most of the Clinton era budged decrease.

[http://www.deptofnumbers.com/misc/debt-revenue-and- expenditu...](http://www.deptofnumbers.com/misc/debt-revenue-and-expenditures- as-a-fraction-of-gdp/)

</comment></comment></comment><comment><USER6> Here is the thing I don't understand - why are people acting as if failing to raise the debt ceiling is the same thing as default?

I.e., I might run up my credit card until I reach my $1500 limit, but I don't default if the bank fails to raise my credit limit. I only default if I fail to stop spending more money than I earn and refuse to pay my credit card bills.

<comment><USER7> Not sure if this is a rhetorical question or not. But the way I understood it is that it's a question of refinancing federal debt. I.e. the new issues are needed to pay off existing bond holders, and if treasury was prohibited to do so, the US would be in default. Have taken my eyes off the markets for the last few months, though, so "grain of salt" and all that...

<comment><USER6> I'm asking because I'm genuinely curious. As for requiring new issues to pay off existing bond holders, why would that be necessary if spending were reduced or income increased? It seems as if paying off a bond holder with new debt should be more or less deficit neutral.

I.e., if I pay off $500 of my $1500 credit card bill, my credit limit remains fixed at $1500 but my debt is now only $1000. I am free to borrow another $500 if I need to.

Is the problem merely that I need to borrow $500 first, raise my debt to $2000 for one day, and then pay off $500 worth of old debt (bringing me back down to $1500)?

<comment><USER7> "why would that be necessary if spending were reduced or income increased?"

i think that's exactly where the problem is. the debt payments are due soon and until the republicans turned the federal debt limit into a political issue, it was being presupposed that it would be raised "automatically" by congress. now they've turned it into a bargaining tool (similar to what they did under gingrich in the nineties) and we have "inconsistent time scales", in that budgeting changes take much longer than the time to next due date. basically, the republicans hold up the extension "in return" for concessions by the president on the revenue side (i.e. no tax increases for their plutocratic clientele) and forcing him to regulate the long-term debt problem only on the spending side.

but you know what, i shouldn't be talking through my hat. i'm not american, have only limited understanding of the us budgeting process, and like i've said have turned my eyes off the markets for a while now. so if anyone knows better, please, enlighten us :-)

<comment><USER6> What are the inconsistent time scales? Was it somehow impossible to cut spending between January and today? How long does it take to reduce spending?

[http://online.wsj.com/article/SB1000142405274870395400457608...](http://online.wsj.com/article/SB10001424052748703954004576089963912388314.html)

<comment><USER7> no point in replying to your questions because they obviously are rhetorical. good day, sir.

</comment></comment></comment></comment></comment></comment><comment><USER8> The assumption is there is no good reason for the US to default, as it can always print more dollars and pay debt with them. In contrast, Greece can't print euros by itself.

<comment><USER9> The U.S government cannot print money, only the Federal Reserve can. The government can only get cash from taxes and debt notes, which is why it's important to raise the debt limit.

<comment><USER10> Actually, it is the Department of Treasury that prints and mints new money. This entity _is_ part of the government, and also manages tax collection etc.

Though you are right that the U.S. government can't print & spend directly. The printed money has to be brought into circulation by the Federal Reserve, which lends it out at the Fed rate. Then again, the Federal Reserve's profits go back to the Treasury so the government can in practice borrow the printed money from the Fed without interest.

</comment></comment></comment><comment><USER11> Unless I'm mistaken, a default only happens if we don't pay our creditors that service our debt. For August that's supposed to be around $29billion [1]. We have more than enough to cover that (the article predicts ~$150 billion in revenue). Every other expense is legally optional and failing to pay those is in no legal sense of the word a default.

[1] [http://about.bgov.com/2011/07/12/august-invoices-show-u-s- tr...](http://about.bgov.com/2011/07/12/august-invoices-show-u-s- treasury%E2%80%99s-limited-choices/)

</comment><comment><USER12> I think a proper response to this question would be in the form of another... What would happen if the US _doesn't_ default? I was raised to think that my parents tried their damndest to leave this world a better place for their children. They might have, but their generation sure failed in that respect. Continuing the charade as if a debt-based economy isn't hurting anyone is just asking for more trouble down the line. Why don't we, as a people of the world, do the responsible thing and get rid of the corruption linking politicians, multinational corporations and banks. The people of the world are suffering and it ain't getting any easier. I heard Latvia just voted to oust their parliament because it was as bad as the US government. Corrupt politicians doing favors for the ones with the "money" and leaving the little guy (the other 99%) to fend for himself.

[http://english.aljazeera.net/news/europe/2011/07/20117232155...](http://english.aljazeera.net/news/europe/2011/07/2011723215535185126.html)

Also, Ron Paul has some words of wisdom on this topic. He has been saying the same thing his entire career and people keep calling him crazy. I think it's about time we listen.

[http://www.bloomberg.com/news/2011-07-22/default-now-or- suff...](http://www.bloomberg.com/news/2011-07-22/default-now-or-suffer-a- more-expensive-crisis-later-ron-paul.html)

</comment><comment><USER13> Is there any reason to expect the US to default? Currently we can easily pay for our debt service using our tax revenue.

</comment><comment><USER14> We will find out what the libertarian ideal of a world without government entitlements looks like would be my guess.

</comment><comment><USER15> A related question: what, if anything, are you doing to shield your savings from a crash in the USD?

I always thought the gold bugs were nuts but if I'd dumped my savings into gold in 2003 when I was considering it seriously I'd be a very happy man right now.

</comment><comment><USER16> There's a good list by Megan Mcardle here.

What people don't get is that increasing US debt is a short term fix. People are going to stop buying Treasuries and the US is going to default. It's just a question of whether it happens on Aug. 2 (unlikely) or in a few years (very likely).

[http://www.theatlantic.com/business/archive/2011/07/getting-...](http://www.theatlantic.com/business/archive/2011/07/getting- specific-on-spending/242240/)

      - You just cut the IRS and all the accountants at Treasury, which means that the actual revenue you have to spend is $0.
      - The nation's nuclear arsenal is no longer being watched or maintained
      - The doors of federal prisons have been thrown open, because none of the guards will work without being paid, and the vendors will not deliver food, medical supplies, electricity,etc.
      - The border control stations are entirely unmanned, so anyone who can buy a plane ticket, or stroll across the Mexican border, is entering the country.  All the illegal immigrants currently in detention are released, since we don't have the money to put them on a plane, and we cannot actually simply leave them in a cell without electricity, sanitation, or food to see what happens.
      - All of our troops stationed abroad quickly run out of electricity or fuel.  Many of them are sitting in a desert with billions worth of equipment, and no way to get themselves or their equipment back to the US.
      - Our embassies are no longer operating, which will make things difficult for foreign travellers
      - No federal emergency assistance, or help fighting things like wildfires or floods. Sorry, tornado people!  Sorry, wildfire victims!  Try to live in the northeast next time!
      - Housing projects shut down, and Section 8 vouchers are not paid. Families hit the streets.
      - The money your local school district was expecting at the October 1 commencement of the 2012 fiscal year does not materialize, making it unclear who's going to be teaching your kids without a special property tax assessment.
      - The market for guaranteed student loans plunges into chaos. Hope your kid wasn't going to college this year!
      - The mortgage market evaporates. Hope you didn't need to buy or sell a house!
      - The FDIC and the PBGC suddenly don't have a government backstop for their funds, which has all sorts of interesting implications for your bank account.
      - The TSA shuts down. Yay! But don't worry about terrorist attacks, you TSA-lovers, because air traffic control shut down too.  Hope you don't have a vacation planned in August, much less any work travel.
      - Unemployment money is no longer going to the states, which means that pretty soon, it won't be going to the unemployed people.

<comment><USER17> Are you being serious? Even Germany after WWII hadnt fallen into such anarchy. The truth is even if the monetary structure fails en-masse(highly unlikely), society would find a way to function. People will work for food, cigarettes, coffee.

<comment><USER18> Germany received a lot of help though. You cannot simply replicate that for the US.

</comment></comment></comment><comment><USER19> Cascading default in state, local and foreign governments along with the end of a largish chunk of firms, ending with a series of currency unpeggings that make the end of Bretton Woods look carefully choreographed.

There may be riots in China. Wars are a distinct possibility. Depending on how the back-end is handled on letters of credit, international trade could grind to a halt. See riots in China above.

<comment><USER2> Not just china. Most states are reliant on the feds for transfer payments, that means 2 million or so households losing their apartments. It means foodstamps stop or get cut, nationwide. It also will mean reduced police coverage in many of the larger cities of the Southern US (remember that thing about blue states being net tax exporters and red states being more dependent on federal dollars...).

If you were trying to create race riots in the US that's pretty close to the recipe you'd follow.

<comment><USER20> Race riots or class riots?

</comment></comment></comment><comment><USER7> to paraphrase larry summers: "post-lehman on steroids"

think what you will of the guy, this is a good description of the most probable scenario, i think:

<http://www.charlierose.com/view/interview/11777>

(at ~ 4:10)

</comment><comment><USER20> The US telecom infrastructure would become privatized. Oh, wait.

</comment><comment><USER21> From what I understand, it wouldn't be as bad as everyone is saying. The US has been the safe bet for decades. Suddenly, we would no longer be the international currency, we would be less trustworthy. The international community would move away from the dollar, maybe to the Yuan, or a mixture of currencies. We would have a harder time trading, which would spiral us further down in recession. This wouldn't happen overnight, though.

Internally, I don't think any of the horror stories would happen. Decisions would have to be made, fast, about what spending to cut. Federal employees would probable get vouchers for awhile until things get sorted out. Lots of furloughs, but air traffic controllers and prison guards would most certainly stay employed.

By the way, this Planet Money on debt was interesting: [http://www.npr.org/blogs/money/2011/07/20/138518262/the- tues...](http://www.npr.org/blogs/money/2011/07/20/138518262/the-tuesday- podcast-how-much-debt-is-too-much) (TL;DL the US is near 100% debt to GDP, countries historically run into problems when they exceed 90%, but it's not a guaranteed outcome, and Britain reached debt to GDP rations over 250% after the war, yet still exists)</comment>


How do I deal with internet trolls? - <AUTHOR> http://www.bbc.co.uk/guides/zcq72p3 <comment><USER2> You don't. Ignore them. Block them. Don't concern yourself with them.</comment>