skysight-inc/HackerNews huggingface dataset:
Heh, I was wondering that myself, but I try not to get too hungup on votes :)

Per project is just going to be a pain in the butt, honestly. It means you'll need to constantly swap out the gopath, and there's really very little harm in having all your go code in one giant gopath. The only time it is a problem is if you use different branches of a package for different projects. That has been very rare in my experience, hopefully it will be in yours as well.

However, I do know some people that have a gopath per project... you certainly can do it, it's just more work. But what you do need is some sort of gopath. It's fundamental to the language. In theory you could probably build without one if all your imports were relative, and you checked out code without go get... but you'd end up with non-idiomatic go code that no one else would touch with a ten foot pole, and you'd lose a lot of the cohesiveness of the tooling.
I agree with the user comments issue. Maybe a way of vetting them, possibly if other viewers agree with previous comments, they become publicly available?

EDIT: ...but even then, you might not get personal opinions. Tough one!
I've been looking for a way to generate those fancy isometric architecture diagrams like the ones by AWS... this looks really promising :D
This doesn't make sense. What you're saying is that the world is a shitty place, for a while it was less shitty and now it's going to shit again.

We've never been more technologically sophisticated. It's never been cheaper to stay alive. It's never been easier to produce cheap, valuable goods to ensure that people can have a good life.

It's not about job security, it's about making sure that everyone can afford a bare minimum of dignity and living standard. If you read between the lines, the author of this story calls for sensible regulation to ensure that this continues to be the case, and that regular people aren't exploited for economic gain. While this might be a controversial topic in some circles, I don't think your average middle-class family would object.

It is obvious that the continued technological developments, including automation, will cause an amount of pain and strife. This is why we should meet these problems head-on. Increased automation should mean more wealth and a better life for everyone. The status quo, at least in the US, has meant a poorer median and vastly increased wealth differences between the top and the median. The latter of these points is not in itself a problem, but the first is. That's where the problem lies.
A public protocol and a reference implementation of a social network. The problem is stabilized, it's time to do to social networks what SMTP did to email. Open it up to be fully decentralized, where people can host their social hub or use a hosting service, of which there would spring up a multitude.

Social networking is nowadays as central to the internet as email, and it is the first such, heavily used, application layer "protocol" that is closed.

For a small period of time I had hopes that this would be the path G+ would take to the top. It isn't.
Oh god, BREW... My condolences, and serious props for managing to port such a complex stack to it!
Sounds like a great tool -- I would certainly use something like this during my telecom days. At the end, did you still use tshark to pipe input data to your database?
MIT Distributed Systems course Lab exercises in GO
No, what he's saying is that AirBnB, Lyft, Uber, etcetera might face lawsuits incurring civil penalties while the people they "hire" would incur criminal penalties if caught working for those companies. It's showing that there is a dual class of law for management vs the worker.
I think this is really a problem that exists beyond interfaces. For example, even if you had these two concrete types, and both had close methods, how would you know when to call one close versus another and what they do? This kind of confusion is a perpetual problem... and I don't think Go interfaces make it any worse, really.
You might find this interesting, just came across it today!

Unofficial Google Music API in Python, quite well documented.
http://unofficial-google-music-api.readthedocs.org/en/latest...

About to get started writing a little script that will take care of synchronising my library with my google music one, and automatically uploading those that it can't find a match for. A few of my friends also use it, so I was also thinking of making a little tool that would allow us to compare our libraries and show us what each other are missing etc.
Isn't that what diaspora is? https://diasporafoundation.org/
I had thought of this, then I wondered, why not have head movement do both? That is, have the camera pan/tilt/roll in sync with your head and also shift the plane on the same axis. That way you could know which way was centered (looking out over the nose of the craft), and immediately see where you'd be headed when the turn completed.
Immediate sharing of raw data (with the world, or restricted to one’s peers), instead of going through the tedious process of information packaging through text, words, written description or synoptical graphics — that’s the future of our open Web. When anyone can create and update the underlying raw data, there can exist infinite summarizing views, syntheses, charts, text, all drawing their own conclusions.

Pushing and syncing strings is a solved problem, as are atomicity, consistency, isolation, durability. Powerful visualization tools are being made, too. The View and the Controller are taken care of.

The unsolved problem remains: how will we empower users to relate those strings, to have them turn data into information, and information into knowledge? How will we enable the many thousands of non-tech domain experts to create their models? How will we devise the Model?
> That's it: a tiny adaptor that makes a bare function satisfy an interface. How is that possible?

No, why is it necessary?

In Java 8:

public interface Handler {
void serveHTTP(ResponseWriter w, Request r);
}

public class MyApplication {
public static void myHandler(ResponseWriter w, Request r) {
w.write("An even easier webserver?");
}

public static void main(String... args) {
Http.handle("/", MyApplication::myHandler);
}
}

No adaptor needed!

Or even:

public class MyApplication {
public static void main(String... args) {
Http.handle("/", (w, r) -> w.write("An even easier webserver?"));
}
}

And please bear in mind that this is Java, the slowest-moving and least sophisticated of contemporary languages! Why does Go require so much more boilerplate than Java?
A progress and time tracker like Habit RPG and Rescue Time that tracks number of hours spent towards a habit/skill. Basically, something that can track where you are on 10,000 hours rule. More automation is better!
The free market is a bunch of fucking horseshit. So there's that.

Maybe try re-examining the assumption the "most efficient" way of distributing resources is better than finding a more equitable and globally beneficial distribution of resources.
Something like Tent?

https://tent.io
The subtitle has the meat: "Vulnerability in Internet Explorer Could Allow Remote Code Execution".

"Microsoft is aware of limited, targeted attacks that attempt to exploit a vulnerability in [IE 6 through 11]." --date published: April 26, 2014.
Of course C++ didn't fail in the sense that it would lack popularity; I think the parent meant that C++ is a complex, horrible mess and that it failed in the "beauty contest" sense.

It also failed in the sense that it didn't eliminate all competition.
I think one major issue there is that all of the available video transmitters for FPV transmit in standard definition. You'd have a hard time spreading that over a sphere and being able to coble anything useful together.

Most of the FPV videos you see on youtube are not showing what the pilot saw in real time. They're showing you the HD that was recording on board the plane and retrieved after landing.
Somebody is also working on this and has made very impressive progress:

http://tactustechnology.com

They are also planning to release it for in-car displays.
US $13K is laughably small for an "institutional" block. Block trading in US equities is more like 10000 shares (keep in mind 100 shares is "one lot" i.e. the minimum quantity for typical orders). Since BTC is trading around the same dollar value as GOOG now, imagine what would happen if someone announced institutional trading with a minimum quantity of 25 shares of GOOG. It's a decent chunk of change for your IRA, but doesn't even register for an institution.

If the goal is to facilitate large orders, the minimum quantity should be at least 1000 BTC. Institutional traders would not pick up the phone for less than that.
This has nothing to do with automation of deployments. Any part of an automated deployment can fail. At scale a single failure cannot be allowed to halt the deployment, either.

This is an architectural mistake. Distributed systems must always be able to operate in an environment with a variety of versions, without ill effects.

They repurposed a flag and then failed to test the mixed environment.

Hindsight is 20/20, of course.
One of the nicest things about Go interfaces is that they encourage SMALL interfaces. In explicit interface implementations, you end up throwing everything including the kitchen sink in the interface, because you might need it somewhere the type is used.

In Go, interfaces are small, and focused more on the function rather than the type. The function defines the methods it needs. So you can have a hundred small interfaces with one or two methods each, and a small handful of types that implement some percentage of those interfaces. Small interfaces makes your functions a lot more flexible. If all you need is a Read() method and a Close() method, instead of a huge number of potentially type-specific methods, then your method that takes a ReadCloser can be used by a lot more types.

You can do that in languages with explicitly implemented interfaces, but it means you need to write down that your type implements these 40 interfaces... and that's a hassle that isn't really needed or useful.
I recently came across this tech where physical buttons appear and disappear on touch screens when needed : http://tactustechnology.com/
I've passed a lot of my first 10 professional years fixing bugs for a information security company. One of them was pretty hard to find out because it was inside the boot of a specific IBM machine in a specific version of a HD encryption bootstrap. The sympton was the machine could be turned on normally, but in the second boot we got just the black screen after the BIOS check forever. Oddly enough, in the third boot things got just right, freezed again in fourth boot and so on.

The problem with boot code is that the debug process cannot interfere with the boot memory itself or the bug won't show up. So I got to make one simple change in the assembly bootstrap, assemble the code, boot with a floppy, access a raw disk editor and replace the old bytes for the new test, boot twice and see what happens (mostly some chars printed on screen).

After one week focused the problem decided to show up. It was a micro misplaced bit operation in the blowfish algorithm (our version in assembly) that swap one or two bytes in a specific sector in the disk. This happened just in this machine with this HD and this version of O.S. because in the boot process some code in the O.S. bootstrap made a write operation in the disk just in this "wrong sector". It was not hard to fix this problem, but to find it for the first place, and after this system already running in thousands of different machines for a couple years without a clue.

It was a pretty nice week in the end.
I'm excited about practical linear typing implemented on the top of full-dependent systems. It would bode pretty well for experimentation and research, more so than baked-in linear type systems, because of the possibility of writing new stuff without having to touch the compiler internals.

In Idris there is some experimental support from writing effectively linear/substructural typing rules for some program state, all within the language, and using it to enforce resource usage or state transitions.

http://eb.host.cs.st-andrews.ac.uk/drafts/eff-tutorial.pdf

In its current form it's not all that usable, because Idris itself is not usable, the error messages are positively Lovecraftian, and there is a hefty performance overhead. But it could be really good when fleshed out.

It would be also great to be able to interface higher-level linear typing constructs with low-level primitives, so that we could reproduce some of the main benefits of the Rust type system, and maybe write some kind of custom "ST monad on steroids" with more control over memory.
But that's the point. Coase says that transaction costs create the need for firms, because they make it more expensive to engage contractors for every job. You reduce transaction costs, and you consequently lessen the need for firms in certain areas.
It depends, I think on the whole it probably is a positive bit depending on the store can be off putting to certain people. For example with clothes shopping I have avoided shops which in the past have tried to be overly helpful. I much prefer to browse and try things on on my own and then if I do need help have someone to ask.
Status page - http://status.bitbucket.org
https://lift.do/ does this
With the current scenario and what we have seen in the recent past, I wouldn't prefer to work in the company being paid in Bitcoins.
How we all could benefit from synaesthesia
Feedient launches into open beta
And here's what I've come up with, as ~/bin/unwrap:

#!/usr/bin/perl -p

use strict;

BEGIN{$/=undef;}

{ s/(?<!\n)\n(?!\n)//sg; }

END {print"\n"}
Lucasfilm makes it official: New Star Wars films ignore Expanded Universe
Here's an explanation. It's old, but probably still accurate.

http://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/25504...
Huh. We clearly mean different things by "imperative programming". To me, sequential computation is a necessary but really-far-from-sufficient aspect of imperative programming. A monadic expression is still an expression, not a statement. It is still referentially transparent. I don't know how you can look at a referentially transparent expression and call it imperative other than by being very liberal with your definitions.
- What is this site? Where is the original content? Why have you linked to a shitty secondary source?

- This is misogynistic and stupid, and exactly the kind of thing we need to keep out of tech culture.

edit: I found the actual content: http://codebabes.com/, luckily it was pretty hard to find, the first result for "code base code babes" was http://www.codefirstgirls.org.uk/edinburgh.html

edit2: Looks like it has nothing to do with CodeBase.
The average programmer would [...] because that's the way the program was written, as evidenced by the semicolon between the two statements.

Seriously? I don't even know C# and the "var q0" was enough to suggest the type of whatever Where returns is not an array of int (as opposed to the two functions above, with int and bool types), so why would I expect it to have filtered the array and returned it?

Ditto for the 2nd example: in this one it's even more clear that Select is returning IEnumerable<int>, not int[].

In C# the using statement causes the variable initialized at the entry of the block to be automatically disposed of when control flow reaches the end of the block. [...] surprising exception far away in time and space

There should be nothing "surprising" about that; maybe it is if you don't know C#. One of the first things that beginning C and C++ programmers learn rather quickly is never to return pointers to local variables or put those someplace where they'll need to be used after the function returns. How is this any different?

Imperative programs describe computations by repeatedly performing implicit effects on a shared global state. In a parallel/concurrent/distributed world, however, a single global state is an unacceptable bottleneck

Except that this "global state" is not really one thing, and it's not like all of its parts are modified by any one effect.

It appears that this "fundamentalist functional programming" the article is advocating is attempting to make programming more like math and distancing it farther from the real world by adding more abstraction, and if anything, I think abstraction is one thing that a lot of software these days needs far less of.

(Sorry if this is too rantlike, I have somewhat of a visceral reaction to these "the sky is falling!" style of articles...)
Well, there's been a rather precipitous drop of late:
http://www.google.com/trends/explore#q=%2Fm%2F03j_q%2C%20%2F...

Perhaps we can call this the Paul Phillips bashing-Scala-tour effect o_O

Hope Scala 3 addresses current issues with the language, which, if it happens, seems to be at leat 2 years away (i.e. 2.12 next year and possible Scala 3/Dotty in the 2016).
Programmer's laptop: A good quality, high performing, non-widescreen laptop with a 4:3 aspect rato.

Why? With a taller screen, there's less scrolling and your eyes don't have to jump as much when reading from line to line.

I would like to know if there would be a market for this and why manufacturers phased out 4:3 displays?
Well, "difficult" usually goes away when you have lots of time, so I have to add ship pressure. If you have time, then hard goes away.

Making the Newton data stores stable, about three months before we shipped. The Newton had a flash-based object store instead of a file system, and the code was such that a power loss or a reset in the middle of an update would toast your data. I spent about six 100+ hour weeks writing a transaction system to make sure that users wouldn't lose data to a crash or a dead battery. I think I had to fix only a couple of bugs in that code, after a massive checkin.

Then, making the audio pipeline for the Kinect stable enough for noise cancellation to work. I'd heard that doing isochronous audio was hard, and "yeah, yeah, sure," but I had no idea it was really hard until I'd shipped a system that used it, with tight constraints around latency variance. I worked with some really good people on this, and there were days when we were looking at Xbox hypervisor code, application code and even DMA traffic on the camera itself. Another three or four 100+ hour weeks, maybe three weeks before we shipped, changing scary stuff everywhere. I still remember a satisfying feeling when I discovered the exact buffer we needed to use as a clock root for audio (and it wasn't the obvious one).
As a Brit, everytime I go to the US I experience interesting social differences. Two fun ones I can recall:

1. Americans are so quick to give up their name whereas there are people I've "known" (as in, I can have a conversation with them and we know who each other is) here in the UK for years and I do not know their names (e.g. people at the corner store, people at user groups). This is not unusual either.

2. Talking in elevators. This rarely happens in the UK but I'd say 50% of the time I'm in a hotel elevator in the US, people say "hi", "good morning" or even try to start a conversation. While I find this unsettling at first, I usually coming away from it thinking it's cute.
I'm up for it. Shoot me an email.
Since C++ is also still used plenty throughout the world, I think he might've meant that it failed to live up to the expectations placed on it as a good balance of structural and functional.
The code was QAed, but they didn't test old and new versions against each other. Version A could accept a flag and run obsolete logic that would lose control of its orders but never sent it, so this problem never happened. Version B sent this flag and the receiver would send RPI orders with it. Put a Version B sender and a Version A receiver together and you end up with a disaster.

From a systems perspective, my takeaways on this are:

-Don't re-use a message for a semantically different purpose in a distributed system where you're running different software versions (even in cases where you don't plan to, really, since you may roll back or end up running the wrong code by mistake)

-Version your messages so anything that changes their meaning can only be accepted by a receiver that follows that protocol

-QA old and new builds against one another

If you really want to look at the root cause of this, it's cultural. Trading desks don't want to spend development time on things that don't generate PnL. Traders want to try lots of ideas so many features are built that don't get used. Code cleanup gets put on the back burner. Developers do sketchy stuff like re-purposing a message field because it's annoying or time-consuming to deploy a new format. If traders aren't developers themselves, they may underestimate the risk of pressuring operations & devs to work more quickly.

Things like this are probably the biggest risk faced by automated traders, and the good shops take it very seriously. I've never been scared of any loss due to poor trading, but losses due to software errors can be astonishing and happen faster than you can stop them.
I don't want to be pedantic, but what was your thought-flow when you submitted this to HN? I mean, sure Bitbucket isn't down that often but is it really thusly news-worthy that your first reaction and instinct is to post a thread about it on HN?
How about a search engine that bases its results on how unique the information is on every one of them.

Every time I try to do an in-depth research on Google about some topic I open up 10 or 20 of the most relevant results, only to discover that at least 80% of the information is repeating itself in at least 50-60% of the pages.

One could write a search engine that compares the contents, groups the articles that have similar enough contents and only displays one article per group. This could work especially well in the case of longer searches with enough keywords.

Obviously, this is not a standalone product that would compete against the established search engines, but it could be built on top of them - a browser extension for example.

Any thoughts on this?
I strongly disagree, but am sure that that disagreement comes only from us defining terms differently. If you define the term "imperative" widely enough to include Haskell, what language does it not include?
Excellent article, thanks for sharing! I wish I could attend Gophercon but I'm way down here in South America.

What book would you recommend for someone who wants to learn about Go practices and professional tips? I'm not interested in a reference book that teaches me how to loop, but a book that teaches me applicable knowledge in a bit more advanced subjects.

I'm aiming to make Go my primary workhorse language.
The notion that functional programming is somehow better than imperative or object-oriented is completely and utterly wrong. It has its benefits. In some situations, it's the best approach. But in most real-world projects I've come across, a mix of different paradigms is optimal.