tedsuo

A point often missed by new Go programmers is that channels are only for select. In other words, channels are a primitive for handling nondeterminism at the runtime level, not a general purpose queue. If there is no select statement, there is no actual need for a channel.

A well designed interface, not a primitive, is the correct way to express an Object or an Abstract Data Type in Go. Specifically, prefer a Queue or Collection interface over a raw channel. (Unless you need to use select.)

This is our fault though, for putting channels in every beginner example, while never really explaining select properly.

All that internet, and the android tablets are still just sitting on the wall where the light switches used to be. What's the cost in hardware and electricity to move from light switches to android tablets for an entire hotel?

Pivotal was spun out. It's a privately owned company with EMC, VMware, and GE as large investors. OSS isn't going away at Pivotal any time soon, it's core to a number of business models.

As an aside, Pivotal also heads up Cloud Foundry, which is an open source PaaS that runs on top of every IaaS. We have been good at selling it to large companies (I work at Pivotal). Everyone in this thread is wondering how EMC breaks into cloud computing, but no is mentioning Cloud Foundry. That's currently the tip of the spear.

Just pointing out that none of the security issues written about in the article appeared to be related to it being an external service. Their problems seemed to be:

a) no one actively admining the service, in particular removing accounts when people left.

b) users themselves were communicating things they were not supposed to, like instructions for circumventing other security procedures.

You can just as easily have these problems with an internal service.

Telling is that the illegal advice VA staff were giving each other had to do with circumventing other security procedures that were interfering with their ability to work effectively (like needing to be available via email but not having access to email on an available device). These are issues all big organizations face, regardless of whether they are purchasing IT services or implementing themselves.

The translation of the compiler from C to Go was a mostly mechanical transformation, specifically to prevent any changes in the resulting compiled programs. Go compilation is getting better all the time, but the switch itself did not change the resulting programs.

I kind of did an eye roll at the breathless language in the announcement. I'm trying to unpack that reaction, because I actually really enjoy the first-principles approach that they have taken with their work.

I think, perhaps, it's because there's a fair amount of praxis already out there in the enterprise and small business sectors about this, and I didn't really see reference to any of that, Lotus Notes notwithstanding. I know it's nitpicky, but it was a strong reaction so I thought I would share it. I'll try to unpack it more:

Basically, creating data processing tools for humans is such a fundamental application of computer science that we even have a name for it: Information Technology. And, ever since the Mother of All Demos we have been trying to make a kind of "omni-tool" for data processing, and pretty much falling on our faces.

This is perhaps because a "general purpose tool" usually turns out to be a particular kind of "special purpose tool". The question is whether a large enough segment benefits from general purpose tooling, which entails taking on the overhead of learning how to use this "tool that makes tools" in order to accomplish their many tasks. In other words, there's a layer of indirection. Or, are most people's problems disjoint and specific, so that they benefit more from using a few special purpose tools that can then be loosely coupled together.

For example, let's say for my job I have to manage the generation of reports, etc, and post them on a company website that I maintain. I can use a document editor to edit documents, a communication service to send links to the documents, and a web-based CMS tool to post the final reports to the website. It's not clear that I would be better served, or even could be served (due to the network effect), by an all in one tool-builder tool. Three special purpose tools, which can guide you effectively in each task, might be easier to deal with than one general-purpose tool, all user grousing aside.

This particular type of omni-tool could be described as a"Distributed Filemaker." Filemaker-like tools are definitely popular, but tend not to unseat other special purpose tooling. And they have a problem shared by all powerful data modeling tools: they provide you quite a bit of rope to hang yourself with. If you want to really improve in this space, I suggest you focus on providing a data modeling and coherency paradigm that is appealing to non-technical users, yet successful for managing long term data that changes meaning over time. That would be profound, as poor data modeling is pretty much how all of these projects eventually crash on the rocks. Your users will not ask you for such a thing though, as they don't understand it.

In spite of the eye roll, I wish you luck!

btw for the record I don't think there's something wrong with making small packages like this, just that I'm more likely to copy over a function or pattern that I like into my codebase, rather than bring in a dependency.

Simply put: dependencies are code, and code comes at a maintenance cost. Thin abstractions, such as a this library, can be replaced by a function or two, which is a lower maintenance overhead because there is less code, you wrote the code, and all the code is being used.

IMHO, dependencies should be pulled in for things that would take you weeks to do correctly. Avoid pulling in a dependency for something you can do yourself in 5 minutes. So I would pull in an http library if it actually did the mechanics of http better than the one in the stdlib, but not one that just wrapped it up for me a bit.

For me, that's not a Go thing, that's just an I'm Older Now thing.

Also, snarkily, dependency management is a mess in Go right now; none of us have any dependencies because we can't figure out how to do it. :P That is definitely a hole right now (though it's starting to get plugged in 1.5 with the /vendor directory) and is definitely exacerbated by the core team not being able to use any solution they could provide for the community.

The term "Data Lake" has been a rich source of puns and riffs at work. You can trawl through it for weeks without finding anything; it's polluted with industrial runoff; you can hide a body in it...

Fun, but like the "cloud" terminology, I die a little bit every time one of these marketing terms gets coined.

Garden is not a docker fork, though it is capable of running docker images.

If what you are passing is a pointer, then the value of the pointer (an integer) is copied. So pointers are passed by value.

"Pass by reference" means that the runtime will convert what looks like an instruction to copy a value (such as a data structure) into an instruction to copy only the address. Go has no such concept. You cannot make a new value that is a "reference" to another value. If you make a new variable that takes a value, that variable allocates a new block of memory the size of that value. Assigning a value to the variable (or passing a value to a function) makes a copy of the value into the new memory address. You can make a "reference" only by explicitly making a pointer and copying the address of another object.

"Pass by reference" languages treat everything as a pointer by default, forcing you to make a copy operation when you do not want this behavior. This may seem like an equivalent programming model, and possibly simpler because this pointer business if confusing at first. However, basic concepts such as a call stack or an array of values can no longer be expressed easily, because with "pass by reference" languages you have removed the concept of a value from the language. So pass-by-reference languages can lead to confusion in large programs, even if they seem simpler at first.

Basically, go is "pass by value" because the language forces you to always be explicit about when you are copying an entire value, and when you are only copying a pointer.

The OP's complaint about Go's type system seems to mainly be that memory allocation is explicit.

Go is always "pass by value", and it's true that I've watched developers struggle to grasp the full ramifications of what that means regarding memory usage. But not understanding the subtlety of memory allocation usually means your programs will simply run slower and consume more memory. It does not usually mean that your programs will run incorrectly.

Given that the OP mentions that they find the slower, more expensive execution of racket programs to be an acceptable trade-off, I'm surprised that they have a problem with this.

Personally, I prefer running in a language that allows me to reason about the memory allocation explicitly. I'd only prefer to give that up in favor of a declarative language that could compute the optimal execution for me. Unfortunately that language is a bit of a unicorn for general purpose programming.

That's great, they hadn't done this when I last talked to them.

I don't believe it has been formally proven correct. I would love to see evidence that it has been proven to be mathematically equivalent to Paxos.

CoreOs (etcd team) is currently rewriting their raft implementation because it had a lot of problems. I don't believe there is a "good" implementation out there yet, because it's all very new. And should an implantation be "good", AKA implement the spec without introducing incidental errors, will it still have edge cases because the spec has edge cases? This is all currently unknown. It's precisely these assumptions that I'm pointing out.

A quick google search brings up libpaxos and other open paxos implementations, so it appears that they exist.

The only issue I have with raft (besides bugs in the various implementations I have to deal with at work) is that it is not yet proven to truly be simpler than Paxos. In other words, is it a genuinely simpler algorithm that provides the the same guarantees as Paxos, or is it simpler because it leaves edge cases unspecified, forcing implementors to grind through the edge cases with heuristics? If it's the second, it's not actually simpler, it's just worse.

I'm not saying that it isn't genuinely simpler. Just that in discussions about raft, I see most people blindly assuming that it is. But I don't believe that it has been proven yet. I think this is the nuclear power plant part of the bikeshed discussion. [1]

If you scrub to the 50 minute mark of this talk[2] by Leslie Lamport (creator of Paxos), my coworker David Varvel asks him this question and he gives more or less the same answer.

[1] http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality [2] http://channel9.msdn.com/Events/Build/2014/3-642

It doesn't currently mention this on the site, but one use case for Ethersheet is to embed it as a component in a larger application.

BlueMix is IBM's rollout of the open source Cloud Foundry product (I work on Cloud Foundry). You can also check out our own example rollout at run.pivotal.io if you want to see how they stack up.

Guys, the buses have nothing to do with it. People are angry because rents and evictions are through the roof, and many people are really feeling it. SV hasn't been shy about taking credit for the situation. The buses are just an obvious target.

Systems such as Go's goroutines, or clojure's core.async, or objective-c's GCD all solve the same concurrency problem while still allowing you to saturate all of your cores from a single process.

This allows you to get around some nasty architectural problems you can hit with node, where you must either find a way to manually schedule all of your computation into tiny chunks to avoid latency issues, or face potentially severe costs serializing your data to communicate it between processes. No trolling here, it's really a thing that happens!

People do solve these problems in node, it's just that the "ease" suddenly turns against you, as you must now solve tricky systems problems - such as manually scheduling all of your computation properly - or face potentially unacceptable performance degradation. In these cases the limitations of the platform become your overriding architectural driver - better drivers like logical separation start to take a back seat. It's not pretty - and not necessary in other environments.

Given that you won't encounter these types of problems until later - once you've already built up a large codebase and switching platforms is difficult - I think it's better to start in an environment where you know you have these tools available to you when you need them. Even though I really enjoy programming in node (and I've done a lot of it!), I'm wary of starting anything new there unless I have a good reason. There are a lot of great modules written in node, I just try to keep those components isolated and not let them grow too large.

The Daily Telegraph is notoriously full of climate change cranks, and regularly misrepresents the views of scientists and the IPCC. A previous example regarding arctic sea ice: http://www.realclimate.org/index.php/archives/2013/07/arctic...

Pivotal Tracker

I wonder how many of these new companies come from large companies that are just rearranging themselves? So that first year's revenue is based on pre-existing revenue or assets?

Yeah, strike lists are The Way It Has Been Done for over a century, it works pretty well. What amazes me about this story is not that the software crashed, but that they did not have precinct captains and strike lists at the ready to step in. And that they were only rolling out their GOTV operation on the day of the election, and not sooner? Pretty bizarre.

Oh the irony of distracting myself by reading this on Hacker News, then making a comment which I will flip back to and check reflexively for the next two hours.

yep, node has always used a threadpool for filesystem calls, even before libuv.

I would add this to the complaints:

- NOT AMENABLE TO SOURCE CONTROL

Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare.

And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful.

Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique.

So glad I don't have to deal with any of that insanity any more.

There are only a finite number of people in the world. So even if all of them knew how to program, a task requiring 10 billion programmers would have a supply shortage. Therefore, the statement "there cannot be a shortage of programmers" is false. Therefore, the market for programmers cannot be a free market.

BTW, I still agree with you that it's "pretty free." And I definitely agree with you that it's generally possible to find qualified programmers. I've never tried to hire and not found at least one qualified candidate that wanted to do the job, mainly by being honest about how our offer stacks up against the others. If we can't pay enough to hire an expert, we hire a potential expert that would take the wage and train them. The lower the wage, the longer we are going to have to train them.

But there's still a difference between "a pretty darn free market" and "the living avatar of the ideal free market," which is what it sounded like you were trying to assert. :)

Is it possible that google forced them to make their own maps solution? I assume apple made the first move, but given the size of the pissing match between the two of them, I could see google withdrawing map access in order to harm iOS.

The drones in the video look extremely CG to me. Cool idea though.