skysight-inc/HackerNews huggingface dataset:
The biggest turn-off about Go, for me, is that the community seems to be incredibly unfriendly to newcomers. He touched on the lack of REPL, but it goes further than that.

For instance, there is very little in the toolchain about debugging other than "use GDB". For someone very familiar with the workflow of typing "debugger" in Javascript code, being able to stop the world at any state, examine variables, and having a fully-functional REPL to test expressions, Go's way of "debugging" code is...well. I don't really know how to do it in Go. The general answer seems to be something along the lines of "think about the code you wrote and then write it correctly you idiot."

Seriously, this is the canonical debugging advice, from Rob Pike himself:

"When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model."*[1]

[1] http://www.informit.com/articles/article.aspx?p=1941206
I disagree with the fundamental idea that time spent on meetings can only be productive for the team but not for you. In fact meetings can (should) be a time to share ideas, learn new things and ultimately make your work more focused. If you're doing meetings right, they prevent you from wasting time on inconsequential details and keep you focused on what matters. If you are bored and the details of your work are not even addressed, you're probably just doing meetings wrong.
I would go with writing directives over using global scope in general, though it's more time consuming to me.
> Go has shared memory. Yes, that's a feature. It allows things to go fast. Purity of not sharing state between threads sounds good in theory until you need concurrency and get bitten by the cost of awkwardness of having to copy values between concurrent processes

There are approaches that allow the flexibility of shared state without the possibility of lurking data races or, worse (in Go's case) lack of memory safety. Even JavaScript has such a solution now (Transferable Objects). In fact, Erlang itself has one such approach: ETS.

To be honest, I don't think unrestricted shared state is the right thing in a programming language. It just invites too many bugs (and race detectors don't catch enough of them).
I started programming when I was 10 and I was instantly hooked. Two years later, my parents got a divorce and my dad took the computer. I only saw him on weekends, but I had to get my programming fix. During the week, I'd write Qbasic programs in a notebook, then type and test on weekends. Eventually I graduated to assembly and C. It was a great way to pass the time in high school health class.

To this day, I still prefer to do a lot of writing before I start typing, though I don't often write the entire program ahead of time. Instead, I'll write the "interesting" bits -- the stuff that's algorithmically complex or otherwise kind of tricky. I find that with nothing but a pencil and a sheet of paper, there are fewer distractions and fewer limitations (comments can readily contain drawings, for example).
There's a lot of conversation about the redundant injector syntax in this thread. This is something that ngmin takes care of completely transparently. There's really no need to worry about it in raw, uncompressed source code. Other than that, this provides a nice way to enforce a certain set of conventions, but I'm not completely sold on the quality of those conventions - the most glaring thing being losing references to your watches. Reverse-binding controllers to views through DOM selectors also has a bad code smell IMO, feels a bit like reverting to jQuery madness. I prefer to do this through routing or directives wherever possible.
Good questions.

> To replicate erlang, is easier if used the Actor model? Or can be done with CSP?

There is overlap between then two. CSP is _usually_ synchronous and Actor model is asyncronous. CSP is focused on channels. As in you send messages to a channel and the other side receives them. Channel has an identity. In Erlang you send a message to a process (its main concurrency context). A process has a process ID used to identify it. Like say you have an address at your house and and I send a letter to you.

Goroutines don't have identity. You can't easily send a message to a goroutine. Kill a goroutine, see if it died to start another one and so on.

> Also, what is need to made a soft realtime language/runtime?

Quite simply you need one part of the system to not block other parts from making progress (returning a result). Imagine your serve a page to one user but because some other user is sent some input that take a long time to process, the first user doesn't get a response, he has to wait.

Or say you have some data structures and a common heap between concurrency contexts. A garbage collector might have to stop all goroutines in order to check if it can collect any garbage. So that introduces a pause. Java Azul JVM the only VM with shared that that has concurrent and pauseles garbage collector. It is very impressive, look it up how it works. In Erlang it is easy. Processes heaps are private to each process so they can be collected independently without getting in the way.
I use Vim normally but I actually downloaded Sublime Text just to use Floobits. There's something really intimidating about using Vim with Floobits, and there's the lack of the nice visual cues like circling around highlighted text.
Solar Powered Window Socket
well, it depends on the console.log implementation :)

On firefox I get

>>> console.log.call(undefined, "Hi")
Hi
> The Muen Separation Kernel is the world’s first Open Source microkernel that has been formally proven to contain no runtime errors at the source code level.

I had the impression seL4 was the first microkernel formally proven to be secure.
Ask HN: What does your startup do for data backup/disaster recovery?
Hi Angilly

1) I cannot comment on the specifics as I hope you can understand.
2) We don't ID check all the accounts at signup. That would be logistically impossible. We have 11 million users.

Regards
Matt
I had to do some digging, but I found the issue he was talking about and the plugin to fix it. The problem with Sublime Text 2 is that the cursor is very thin and hard to see. The plugin to fix it is https://github.com/netpro2k/SublimeBlockCursor

If you don't want to install that plugin, you can get a more visible cursor by adding "caret_style": "wide" and "highlight_line": true to your Sublime preferences.

I'm not sure why the author avoided mentioning the specific issue. If it affected him and his friend, it seems like he would want to err on the side of telling others about it.
I work as a software engineer at a mid-size ad agency in Birmingham, AL. Send me your resume (brgordon at ua.edu) and I'll see what I can do in the organization.

I also graduated with an advertising degree, but started coding my senior year of college. I just started with this company so I can't make any promises but I'll see what I can do. You have an online portfolio too, correct?
Thinking like a designer is so important in coding. Designers spend most of their time observing a problem then deriving a simple, efficient patch. I'm always looking for ways to patch, by observing closely and listening to what others are frustrated with.
All funds have been returned to the employer's credit card and the employer has been called to inform them to pay directly.
http://en.m.wikipedia.org/wiki/Zorn's_lemma

Minor major nitpick: Axiom of (Uncountable) Choice (AUC) is controversial. It isn't intuitive, but it is independent from the intuitive axioms, which means that you don't have to accept it, and if all you care about is things that might ever be computable during the existence of the Universe, you never need AUC, and AUC never tells you anything useful since it is nonconstructive in the worst way. (It doesn't even say, like NP does in computing, that if you brute-force, you can solve any problem to any desired level of accuracy). AUC just asserts an answer exists. The interestingness is in knowing what other statements are equivalent to it , but it is and forever will be confined to purely abstract math (really! Unlike RSA, there will provably NEVER be a computational or physical application in the accessible world of countable infinities.)
> Why? Why shared state is so bad? Isn't it taken care by Go's channel anyway?

Because you can have data races and memory safety issues.
Definitely true in general though angular in particular is SO GREAT that it is worth it. But it certainly doesn't need MORE layers like the one in this post.
I apologize for the snark.

But I thought that your first statement was questionable, and that therefore your second statement was rather facile.

> Knuth's definition of 'bug' is a limited one, that seems to be mainly about logic errors. Allowing a user to incorporate bitmap fonts in a document (which very few users actually wish to do in 2014) would be considered a bug in other typesetting software.

Certainly, people sometimes use "bug" loosely, but it seems to me there is a strict sense in which a "bug" means something that was not intended by the writer of the code. And the issue you describe clearly does not fit this description.

I would call what you describe a "design flaw", at best. But as I alluded to, it wasn't even a design flaw at the time it was introduced. So it's really more of an anachronism than anything else.

And again, it's not really clear that it's even an anachronism in TeX, since it's more of an issue with the DVI-to-PS (or DVI-to-PDF) transformation.

And then you went on to conclude, from this highly questionable chain of reasoning, that this "bug" is "a fantastic illustration of the gap between academic and industry concepts of computing". Which I just find galling. Here you're talking about one of the most celebrated computer scientists of all time, someone who is almost certainly a lot smarter than you (or I), and you chalk up a difference between what you and he call a bug to the difference between industry and academia. As if Knuth is just some kind of ivory-tower crackpot who wouldn't understand the real-world exigencies of industry.

So: I think your definition of "bug" is highly questionable, and I think that in the future, when you find yourself in disagreement with some celebrated academic computer scientist, you should perhaps linger a bit longer on the possibility that you might be mistaken, rather than chalking it all up to the difference between industry and academia.
author here: I couldn't remember clearly if the issue that was fixed was the block cursor one or something else. It would prove logical that the only one I can remember is the actual issue discussed, but I can't be sure.

Aside the focus was on the act and impulse rather than the actual issue.

Aside number two, I had a few glasses of red wine while writing this. I find it helps get the words flowing, but the memory fuzzy. ;)
Hello campuscodi

With 11 million users you are bound to get a few complaints about something, however we are very proactive about finding these issues and resolving them. I personally am dealing with this issue and I have looked at the circumstances and I stand 100% behind my anti-fraud team.

Regards
Matt
I don't know that much about Erlang, or Go for that matter, but there are a couple of things that seem to be at issue:

* From what I can tell the times I've looked at it, Erlang's syntax is pretty standard if you're used to functional programming. Sure, if your background is in C and Java, you might have a hard time picking up Erlang syntax, but if you have experience with Haskell or ML, it will be nothing new, except for (that I can tell) its syntax for bit-level operations.

* Structs are not data structures. They are a way to represent objects. Erlang has these as well, in the form of Records, which as far as I can tell are pretty much exactly the same thing as structs.

* Hash tables are only really useful with mutable data, which has its own set of issues and which Erlang does not have (much). Erlang does have maps, which act much the same way but are immutable.

I think it really comes down to that Erlang was designed for a restricted set of uses, which makes it really excel there but seems to hamper it in other areas.
Interesting...would you be able to give an example of the state machines you built and how you used them?
I think Haskell has been growing a lot fueled by having a really great base language finally getting a pretty comprehensive standard library. This was a highly intentional group effort that began probably 10 years ago and pushed the Haskell libraries to a level of maturity.

I can't truly claim this has driven the adoption of other languages, but Haskell's (or pick some language from the ML roulette) influence on Clojure and Scala is undeniable. Clojure's commitment to immutability pales in comparison to Haskell's, while the latter demonstrates the advantages of such programming in spades. Scala's type system is a novel extension of the HM system which forms the basis of Haskell's.

So am I claiming that the increased availability and "practicality" of Haskell has driven a renaissance in functional programming?

Sort of, yes, but I don't feel it's the core underlying cause. More a symptom in its own right. These ideas are the leading edge of programming language research. They're smart to learn and to integrate into our next generation of tools. This evidence has long resounded from finding them at the center of the "Holy Trinity" of category theory, logic, and type theory. It's "practical" significance is still growing, however.
Both my site (Freelancer.com) and Paypal have similar issues. Both are subject to fraud on a daily basis, and we have to weigh up the security of our marketplace and the protection of our users versus customer support issues that become public very quickly in today's world.
Funny this mistake rarely goes the other direction. Probably because 'curry' is a fin word.

I propose 'parry' for "partial application", to satisfy the punsters without compromising accuracy.
> The concept of "compactness" is the technical solution that lets you formulate calculus without them -- it's typically only taught to math majors because infinitesimals are less awkward to do algebra with: we can now prove that the shortcut works, so why bother with the long way unless you have good reason?

I don't know where you got the idea that compactness is in any way relevant to the formulation of calculus. Compactness is a property of topological spaces that, to an approximation, is a generalization of sets being finite or infinite. For example, with the discrete topology, a set is compact iff it is finite. There are many related notions of compactness. In R^n, a set is compact (and sequentially compact) iff it is closed and bounded.

Compactness is important for some ideas related to calculus, but it's not related to formulating calculus. For example, if a continuous function maps from a compact space to R, then it achieves a maximum/minimum (this can be seen of a generalization that there is always a maximum/minimum of a finite set of real numbers, but not necessarily for an infinite set).

The word infinitesimals is also a tricky word to use. To a mathematician, an infinitesimal would probably mean an algebraic object that formalizes the idea of a number smaller than any positive real number. This is not what is taught in calculus or analysis classes, and is only relevant for non-standard developments of calculus.

The winner in the modern formulation in calculus is the "epsilon-delta" formulation of limits; that's what's taught in both calculus classes (at least to an extent) and analysis classes. The weird thing is that calculus is stuck with Leibniz's notation, which does, in a sense, refer to infinitesimals. I think that's what you're really thinking of (rather than compactness) as how you can formulate calculus without infinitesimals. The thing is that, save notation, this is how calculus is taught today.
I hope that wasn't the actual reason why they decided against a REPL or other tools, because unfortunately, most of us aren't as smart as Ken.
This reminds me of the George Bernard Shaw quote: "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
You have written this several times but the empirical evidence is that you don't accept them, you seem to have vehemently and repeatedly refused to accept this client's drivers license. Do you not acknowledge that the client's DL was refused? Do you not see how saying "we accept DL's" several times has not helped your reputation at all?
I just noticed that the plugin was last modified a year ago, but your story was written last week. It makes sense that the exact issue would be forgotten with time. I've had similar instances where I've forgotten the exact issue but remembered the general lesson.
We use CouchDB for distributed instances, using Digital Ocean droplets with backups there as well…might not be best practice.
> but this article just shows that you don't even have to try hard to create a biased comparison.

So, let's see you detailed unbiased analysis...

> * Go is fast. Erlang isn't.

Hmm. Given that you accused the author of making biased comparisons, I would expect some more detailed information there. "Faster" doing what? Assembly is faster, Go isn't. Ok, let's use assembly then.

> * Go has a non-surprising, mainstream syntax. You can pick it up in hours. Erlang - not so much.

I think Erlang syntax is small and self consistent. If ; and . are the biggest stumbling blocks to learning a new system. Ok, maybe Erlang is not for you.

> Go is good at strings. Erlang - not so much

Erlang is very good at binaries. It can even do pattern matching on them. Decoding an IPv4 packet is 2 or 3 lines of code only.

> Go has the obvious data structures: structs and hash tables. Erlang - no.

Erlang has obvious data structures -- maps, lists and tuples?

> * Go has shared memory. Yes, that's a feature. It allows things to go fast. Purity of not sharing state between threads sounds good in theory until you need concurrency

Quite the opposite. You can get easy concurrency if you don't share thing between concurrency contexts. You also get low latency response and non-blocking behavior.

Erlang shares binary objects above a certain size behind the scenes as well so those don't get copied during message passing.

It also has Mnesia, a built-in distributed database. It is used heavily by WhatsApp to share data between primary and back-up instances of processes running on different machines.

> You just have to overlook ugly syntax, lack of string type, lack of structs, lack of hash tables, slow execution time. Other than those fundamental things, Erlang is great.

Ok it looks like we only have to overlook syntax. Sound good to me then, I can handle . instead of ; and I will also learn and use Go because both are very cool and interesting tools.
Shared state is bad because it breaks local reasoning. Without enforcing certain disciplines (i.e. always sharing by passing messages via Go channels) it's hard, if not impossible, to reason about local behaviors without considering other parts of the code. Immutable vs shared mutable state is a design choice. Erlang chose immutability for safety, while Go chose shared mutable state for practical reasons, but as a remedy Go recommends best practices to avoid the drawbacks caused by it.

Pre-emptive scheduling is bad because you can have a goroutine running a tight loop starves other goroutines. To address that problem, you should manually call runtime.Gosched() to yield control and allow the scheduler to run other goroutines. Erlang's reduction-based scheduling does not have this problem and can be very fair.

Goroutine lacking identity is a major design difference from Erlang. In Go, channels have identity, but goroutines don't. In Erlang, it's the other way around: processes have identity, and channels are implicit a.l.a mailboxes. In theory you can simulate one style in the other, but the implication of this design choice is very proud. I'm a Go fan, but personally I think Erlang's model is easier to reason about in scale, and it has this nice symmetry with OS threads/processes (you can kill them easily. Good luck killing a goroutine).
The End of One-Doctor Medicine
For websites there is a $19 listing fee and a 10% success fee.
There really should be consequences like, for Australia, severing all shipments of raw materials to China or cancelling all imports from China and compensating any losses with any Chinese assets as a matter of national security. Or when the USA does it, pulling out all military troops in whichever war we are in at the moment or banning all American music, TV, and Movies....stuff that, although not painless to ones self, things that are far more painful for the offending party. Not doing so only encourages such acts.
http://en.wikipedia.org/wiki/Philosophic_burden_of_proof
I think a Go REPL would be a very cool project. I think it is doable. I always have ipython up, when I program in Python.

There is even a C++ REPL somewhere. It basically compiles very time your enter the expression and runs the code. I think it can be done in Go (but someone correct me, if I am wrong here).
Decompiling Clojure Part III, Graph All the Things
Note that the relationship at the time was between firms and Wall Street brokers and traders mediated via pensions, rather than individuals. Firms and unions will have more leverage.

The present personal investment model (401k and similar) will, I suspect, be seen as one of the larger financial mis-steps of 20th century economic history. Its emergence itself was largely accidental.
imho, go, afaik, is designed to cleanly express concurrency primitives in the context of a single system, and doesn't do 'fault-tolerance' in the erlang sense of 'you need >1 machine to be fault-tolerant'. with that lens, it is clear that the optimal way to do concurrency is with shared state, but that gets exported out via channels and go-routines etc.

also, can someone please explain the issues around 'nil' ? i fail to appreciate author's concern about those...
Yet, none of them came out with a new editor.
I'm 40 (I think age is important when measuring productivity of IT workers) and I can do 12 with a lunch break; however, I will be a zombie next day and half-zombie the day after. I do two long runs per week b/c it hurts my brain not to finish a module/task plus I hate to 'reload' the problem in my head the next day. Also, having the feeling of 'not done' makes me unable to disconnect from work and rest. On zombie days I do the no-brainier tasks or catch up with emails. Not sure if this a good strategy but I feel that in the long run I accomplish just as much.
Agreed 100% Nate.

The aha moment really makes customer development make sense.
Ah! I finally remembered what the issue was! I updated the post with what the offending issue was.
The World's Most Powerful Engine
Reinventing Search
CommentGame.com, featured on http://allfacebook.com/comment-game_b126161

Thanks.
RAM is no longer a bottleneck. So you can "spend" some RAM in the search for increased programmer productivity.

CPU is not really a bottleneck, either, so, you can also spend a few cycles there also.
Let's Make Texting REALLY Social
People love to complain about how NYC "used to be," but it is always changing. When a city is so compacted, the changes will be more noticeable.