Is there an existing "Stack" for getting into robotics? - <AUTHOR> I've tinkered with arduinos and stepper motors/stepper controllers. I built a CNC mill. But I'm hoping there are components that I can plug together and just focus on the software side using existing hardware modules. <comment><USER2> I'm a web developer who got the bug to get into robotics about four years ago as a hobby. I ended up joining a FIRST [1] robotics team as a programming mentor and I've learned a lot [2].

[1] FIRST [http://www.firstinspires.org/robotics/frc](http://www.firstinspires.org/robotics/frc)

[2] [https://www.youtube.com/watch?v=8319J1BEHwM](https://www.youtube.com/watch?v=8319J1BEHwM)

<comment><AUTHOR> Thanks! Is FIRST for youth only?

<comment><USER3> Yes, but many school teams are welcoming to adult volunteers. I'd highly recommend it!

</comment></comment></comment><comment><USER4> What about something like a TurtleBot[1] and ROS[2]?

[1] [http://www.turtlebot.com](http://www.turtlebot.com)

[2] [http://www.ros.org](http://www.ros.org)

<comment><AUTHOR> Thanks! Ros looks interesting. Turtle bot appears to be the open-source roomba with a shelf on it.

<comment><USER5> ROS is a good platform for writing software. There are ~50 hardware platforms that support it. Unfortunately robotics is still built to a purpose, and usually a bit too expensive for a typical hobbyist platform. Our latest robot here at Duke was built with modularity in mind and still cost well over 100k.

</comment></comment></comment><comment><USER6> ROS, ROS, ROS all our robots are on ROS and you get visualization and simulation tools, 90% of the things you'll ever need come from apt-get (ubuntu make everything easier) but the real deal is Gazebo and stage for simulation and the wiki is full of tutorials

</comment><comment><USER7> I wanted to get into robotics as a way to get up to speed on neural nets and reinforcement learning. I found the Lego EV3 kits to have a good mix of sensors motors and supporting parts. The EV3 bricks run Linux, there's a distribution for them called ev3dev, and they'll even run ipython notebooks.

I'm now looking at getting a BrickPy for it as the EV3 brick doesn't do FP, so not good for NN's.

</comment><comment><USER8> I would skip your search for the "right stack" and think about working on real, profitable applications. Develop whatever needs to be developed to solve a real problem. Most things calling themselves 'robotics stacks' nowdays are overblown and add more complication than they're worth.

</comment><comment><USER9> Depends on what you want to build. A popular hobby stack is built around the Arduino. It will allow you to plug in a fair amount of parts.

Figure out what you want to build first. Then send me an email and I'll try and guide you in tve right direction.

</comment><comment><USER10> Piggybacking on this: anyone has good ideas/sources for mechanical parts like gears and stuff?

My hobbyist alternatives right now are lego or pulling stuff apart.

<comment><USER11> mcmaster.com for everything, sdp-si.com for gears/timing belts etc, vxb.com for cheapo but decent bearings

<comment><USER12> My rule of thumb is McMaster for big stuff, sdp-si for little stuff.

</comment></comment></comment><comment><USER13> Lego Mindstorms. You can program them in "real" programming languages if you want to.</comment>


3d scene representation in Haskell - <AUTHOR> http://devskypers.blogspot.com/2014/07/lost-in-space.html <comment><USER2> I think this demonstraights a real weakness of Haskell. Several times I've started a new project only to spend several hours trying to work out the correct way to structure what I want. Often it is hours before I even get my first successful compile. This is exactly as shown in this blog post. While some people enjoy this kind of tinkering, for me this really quickly saps all my motivation for the task. I just want to get something, anything, working. I work best jumping directly into a task and understanding it from the inside out, learning from my mistakes. Sometimes if I do find a quick and dirty way to get something working in Haskell - often refactoring it also becomes pretty difficult - which turns me off again. Neither of these are problems I have in other languages.

Arguments for which approach is better aside, it is no wonder lots of people who learn and approach tasks like me, feel a little betrayed by Haskell. I've used it for a bunch of things, I'm past the steep learning curve - but it seems I'm still not reaping the rewards. Is my philosophy of jumping into projects really so bad? Is it Haskell's place to question such an approach, when it has served me so well elsewhere?

<comment><USER3> I agree.

Haskell enforces a programmer to create structure. There's no way around it. And it's (nearly) impossible to hack things together without failing early and often.

As a result, before the problem you're trying to solve can be explored, you're stuck making guesses on how the problem should even be structured. You spend a few hours with one guess, it turns out to not get your far, and you try another.

The unfortunate part is that these guesses aren't letting you get to the meat of the problem effectively; you're stuck trying to solve a _meta-problem_.

Of course, once you have solved the meta-problem well enough, you can start exploring your problem. Unfortunately, you may find that your meta-solution doesn't actually let you answer questions you didn't know you wanted to answer from the get-go, and now you're back to square-one.

When everything is right, the program is usually very beautiful, safe, and—if you're skilled enough—efficient.

Perhaps not all Haskell programmers have this issue for very non-trivial programs, though I certainly do.

<comment><USER4> I don't really agree. The greatest structure in most of my Haskell programs is some kind of ErrorT or something. That requires me to structure the way I handle IO and the way that Errorable things happen, but beyond that, `a` is just as generic as any Python type. Sure, a lot of libraries do require you to accept certain premises, which may be a problem, but most of them provide ways to break out of their abstractions: ErrorT provides `runErrorT :: (Monad m, Error e) => ErrorT e m a -> m (Either e a)` which allows me to break out very easily, and due to the composable nature of Haskell, even if the library does not provide a function, it is often far from hard to write one yourself.

</comment></comment></comment><comment><USER5> This is the "problem" with haskell. It makes you have a reasonably good model before you can even codify it.

You have to front-load all the whiteboarding. Everything is easier (and usually bug-free) after that.

There have been many times where my inability to codify a mental model in haskell made me realize why that mental model was inherently wrong/unsafe.

</comment><comment><USER6> A very small tip for people learning Haskell (coming from a fellow newcomer to the language): as you read the code, mentally replace "::" with "has type of."

</comment><comment><USER7> I think there may be a typo with the first example:

      newtype ID a = ID Int deriving (Eq,Ord,Show)

Should possibly just be:

      newtype ID a = ID a deriving (Eq,Ord,Show)

<comment><USER8> Nah, it is a type of numeric ID's for different types of things. The parameter 'a' is just a phantom type parameter to keep you from mixing up a mesh ID with a texture ID.

</comment></comment><comment><USER9> Lots of good discussion in this thread -- but no suggestions relevant to the author's problem. Is there a better solution?</comment>


Why Aren't You Trying to Be More Like Elon Musk? - <AUTHOR> https://www.psychologytoday.com/us/blog/the-architecture-inspired-lives/201806/why-aren-t-you-trying-be-more-elon-musk <comment><USER2> > Why Aren't You Trying to Be More Like Elon Musk?

Not being bipolor has been working for me so far.</comment>


GitHub Is Enabling HTTPS on GitHub Page - <AUTHOR> https://github.com/isaacs/github/issues/156#issuecomment-366504568 <comment><USER2> For me personally, the bigger news is that Fastly (which hosts GP) might finally be doing away with the $250 / month wildcard cert fee. Fastly has, in my opinion, one of the best HTTP/2 stacks available right now but you can't use it with your own domain unless you cough up that massive fee. Meanwhile everyone else offering certs for free (Heroku) but they don't have nearly as sophisticated of a stack as Fastly.

<comment><USER3> What makes you think that they might be getting rid of the wildcard cert fee? Their pricing still lists the $250 monthly fee for a shared wildcard cert (i.e. your wildcard domain is added to one of Fastly's SAN certs).

The "Contact Sales" plan mentioned in the Github discussion applies to the "Customer-Provided TLS Certificate Hosting Service" option, where the certificate is hosted on a shared domain map and where Fastly uses SNI to select the correct certificate to serve based on the domain name sent. Note that this option is only available if you meet their qualification criteria, whatever that includes. And it doesn't say anything about pricing, but there is no reason to assume that it's going to be for free. Also, that plan has been around for a while.</comment></comment>


A Week with Mozilla's Rust - <AUTHOR> http://relistan.com/a-week-with-mozilla-rust/

<comment><USER2> The example of match usage is really poor. From the looks of it there is no "pattern matching" going on at all here. I don't know the syntax, but even something like this would be a better demonstration:

        let computed_key = match (key.len() > self.block_size, key.len() < self.block_size) {
            (true, false) => self.zero_pad(self.hash(key).digest),
            (false, true) => self.zero_pad(key),
            (false, false) => key
        }

At least there is some matching here, unlike in the original example. But in real world this should be if..else if..else statement, not match - the latter being used makes no sense if there is no matching going on. In Erlang there is an if statement, which is a 'case' (equivalent of match here) but with matches taken out and only guards allowed - that's what would fit here, but I doubt Rust has something like this.

Also, does the compiler complain about my example above being not exhaustive? I think in OCaml it would, which is sometimes nice.

<comment><USER3> As noted by masklinn, the compiler will complain about the non-exhaustive match. Stuff like this makes me want a dependently typed language for practical programming, in which I can express the concept of "this case ought to be impossible", and convince the compiler by supplying a proof. Also, this would eliminate the false dichotomy between "fast, unchecked, unsafe array indexing" and "slow, checked, safe array indexing", which would be a huge win for safe systems programming.

<comment><USER4> I assume you're familiar with ATS? What don't you like about it?

<comment><USER5> I am not the original poster but I'll respond to this one:

I am familiar with ATS and I don't like that I am only familiar with it from the Language Shootout contest website. I haven't heard of it used in production, no blogs, no news on HN.

It is a bad excuse and rather sad but my main charge against it is that it is not popular enough.

<comment><USER6> I agree not much is heard about it. I blog about it a fair amount on [1]. There's also /r/ats [2]. I use it in production. The backend of my bitcoin mining pool [3] is written in ATS and has about 1% of the total bitcoin mining capacity and has been operating for a couple of years. The front end of the pool is written in Ur/Web.

[1] [http://bluishcoder.co.nz/tags/ats/](http://bluishcoder.co.nz/tags/ats/) [2] [http://www.reddit.com/r/ATS/](http://www.reddit.com/r/ATS/) [3] [http://mmpool.bitparking.com](http://mmpool.bitparking.com)

</comment></comment></comment></comment></comment><comment><USER7> I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content

The second sentence:

> I want a language where I can be much more productive than in C: one in > which I do not fear the correctness of my memory management, and don't have > to go through major gyrations to write concurrent code.

And we see no explicit demonstrations of the memory management and no demonstrations at all of the concurrency model. It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored before reaching the conclusion. :\

<comment><USER8> I agree, the actual content doesn't match the introduction so well.

I've been looking into Rust during the past few days and I must say I got stuck on the memory model - all the different pointers and their interaction with ownership and mutability, closures capturing their environment (variables outside the closure in the scope where the closure is defined), reference binding, and then things like std::Cell which on the one hand seems to be an alternative to std::Option but on the other hand it's using some unsafe operations in its implementation to change mutability or something... It's quite confusing and it stopped me from writing a simple example application I wanted to write because I wanted to understand what's going on a bit better first.

<comment><USER9> > all the different pointers

@ is going to sink into the library and will be deemphasized in the language to help with this. That leaves only ~ (pointers) and & (references).

> closures capturing their environment (variables outside the closure in the > scope where the closure is defined)

Right, this is one of the difficult pieces. This is going away as well in favor of Java-like Runnables to make the variable capture easier to understand (with macro sugar to make them just as convenient as closures). The closures that remain will work just like the closures you know from other languages regarding variable capture, and the Rust-specific stuff regarding variable capture will be gone.

> std::Cell

Yeah, this needs to be better documented. Part of the problem is that we haven't totally nailed down what Cell will be used for yet.

</comment></comment></comment><comment><USER10> Of all the upcoming languages out there. I think rust is best positioned. The fact that it is really the only contender that can preform the same role as C, but it folds in lots of the language design theory of the past three decades puts it in a league of its own.

<comment><USER3> Exactly! This is what makes Rust _exciting_ \- as opposed to yawnfests like Go that merely provide a compiled, somewhat faster Python.

<comment><USER11> Go does have one interesting feature: CSP concurrency built in. Even this was predated by Erlang, though.

<comment><USER12> I was really a little bit disappointed to learn that go (touted for it's goroutines) doesn't have actors, i would love to have the erlang style, network aware actor model in a language i belief i could learn easily ;) Without that, i don't see so much noveltly :( All in all i don't see how goroutines can compare to the Erlang model at all (

</comment></comment></comment></comment><comment><USER13> That seems like a really bad example of pattern matching, as no pattern matching is going on; it's just using the guard statements, and so could be replaced with an if statement:

        let computed_key = if key.len() > self.block_size {
            self.zero_pad(self.hash(key).digest)
        } else if key.len() < self.block_size {
            self.zero_pad(key)
        } else {
            key
        }

<comment><USER14> So the last statement in a block for a matched if condition gets assigned to the variable? That's pretty cool.

<comment><USER15> Any language that emphasizes expressions over statements will have this feature. Off the top of my head, that should include Haskell, Scala, CoffeeScript, Ruby, Elixir, Clojure (hell, anything Lisp really)...

The idea is that while you may be able to traverse code-paths with side effects in some of these languages, they encourage treating a line of code (term used loosely, as an expression can span multiple lines) as a computable value. It may take a bit of getting used to at first, but from my own experience, it now feels weird and awkward when a language doesn't.

Reminds me of looking at a nasty language like MUMPS or something, where persistence is built into the core language; statement-oriented languages tend not to be composable.

</comment></comment></comment><comment><USER16> I don't think it's fair to compare Rust to Go, while operating on nearly the same level. They are targeting a very different crowd. Go has very clean syntax, few reserved words and writes almost as easy as python. This makes go a attractive language for programmers who have a history with languages like php & python but also want more speed. Rust on the other hand has a more complex syntax but allows you more control over memory, thus making it more attractive for those with a history in C or C++. Go is a good language to learn as your first compiled language, easy to write, easy to learn and a good ratio between performance and effort. Rust is (or will be when it's stable) a good language to learn when you have a history in C and you want memory & type safety but still the control you are used to in C/C++.

</comment><comment><USER17> I enjoyed the article very much. Please continue with your journey of explaining Rust to programmers that are looking for new alternatives to C.

<comment><USER18> I really appreciate that feedback. Thanks!

</comment></comment><comment><USER19> I don't want to turn this into a Go vs. Rust discussion, because the two languages are very different and have very different goals.

However, I want to question the claim:

> Go is also not particularly friendly to interface to external libraries > written in C

which doesn't seem to be explained anywhere in the article, and jars with my understanding.

Go does play very well with C; cgo[0] makes this pretty straightforward.

Maybe there are specific things that the author is trying to do that they found difficult in Cgo, but I would say that Go does play fairly nicely with C; that was a design goal.

Here's a simple example of cgo in action: [http://golang.org/doc/articles/c_go_cgo.html](http://golang.org/doc/articles/c_go_cgo.html). As you can see, it's relatively straightforward and easy to use.

[0] [http://golang.org/cmd/cgo/](http://golang.org/cmd/cgo/)

<comment><USER20> Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat.

So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to write a piece of your application (even mainly C application) in something that gives you a different kind of expressibility. If there's need for that is another question, specifically, I'd like to see some examples that would really impress me. The examples the article author provided give me only the impression "OK it's weirder syntax but it's not so far from what would have to be written in C anyway, so where's the advantage?"

What I consider missing for "properly" interfacing with C is for Rust to be able to slurp C headers as they are, without the need for additional "translation" files that are presented in the article. At least the headers without the definitions of the functions. But the declarations of the structures and functions and even basic preprocessing were really, really convenient.

<comment><USER20> I've took a look on one "real" example, I admit I haven't spent much time with the language, I just want to get the idea looking at the code which really does something, I like that more than starting with boring tutorials:

[https://github.com/mozilla/rust/blob/master/src/libextra/jso...](https://github.com/mozilla/rust/blob/master/src/libextra/json.rs)

I know it's the least interesting thing, but for me the simplest rule to recognize Rust vs Go is that at the moment Go has the nice and minimalistic := and Rust the clumsy (for my aesthetics at least) "let."

Still, I understand that Rust attempts to solve more than Go in some aspects, and I really hope it can succeed. For that, yay Rust!

Can somebody explain me the reason for constructs like this:

        self.error(~"trailing characters")

vs

         self.parse_ident("ull", Null),

I read that ~ means "owned box on heap." Why should something that are facto string literals be owned and on heap? Isn't the need to allocate and box string literals on the heap something that makes the language unnecessarily slow? And why there's a need somewhere to explicitly box something that's known at the compile time and somewhere there isn't?

<comment><USER9> > I know it's the least interesting thing, but for me the simplest rule to > recognize Rust vs Go is that at the moment Go has the nice and minimalistic > := and Rust the clumsy (for my aesthetics at least) "let."

It is not possible for us to have ":=" because we don't know whether to parse a pattern or an expression without a prefix token like "let". Rust's pattern language is far more expressive than Go's and one grammar will not cover both.

> Why should something that are facto string literals be owned and on heap? > Isn't the need to allocate and box string literals on the heap something > that makes the language unnecessarily slow?

Probably the `error` method explicitly asked for a heap-allocated string, perhaps because it wants to pass it to someone who will later free it. (Unlike in C, it would be a type error to attempt to free a constant string in read- only memory, which is what a plain string literal is in Rust.)

<comment><USER20> Does it mean that to do

        self.error(~"trailing characters")

there has to be the complete allocation of enough memory to store the copy of the whole string, then copying of all characters there, only in order for the target function to be able to do "free"? If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be a good optimization to have the free routine check if the pointer is inside of the static area and then not do anything. That way you can pass the pointer to the static area avoiding copying and also avoid freeing. And the only thing needed is that free has "static_begin" and "static_end" addresses?

There are also other possibilities -- by knowing that the heap allocated things have lower bits of addresses 0 you can mark the stuff using the lowest bits of pointers.

I know, I have maybe too low level approach. But why not, as soon as you want to be more convenient than C, you have to think low level too.

Still what I like is that at least at the moment this explicit declaration of boxing gives a nice feeling that nothing is done "behind the back" of the programmer, which is good -- the main problem of C++ is that you can't know if somebody hid something very nasty behind some plain innocent looking construct, or even what the compiler will implicitly do or won't.

EDIT-addition: Regarding "pattern" if the := would be a single token, not allowed in patterns, wouldn't it be OK then? Do you have such a valid sequence in the patterns as the combination of the single operators or whatever?

<comment><USER9> > If the intention of the language is to "properly" work with a lot of strings > (and it should be) it would be good not to have glaring inefficiencies? > Wouldn't it be a good optimization to have the free routine check if the > pointer is inside of the static area and then not do anything.

You can implement that yourself, by using an enum for example or by using a custom smart pointer. The moment you start adding more magic to "free" beyond "call free" you become less low level of a language.

<comment><USER20> Can I ask in the language if the address points to the item constructed by the compiler in the static area?

The thing I miss most in C is the possibility for the some kind of"introspection" \-- reaching out to the info that the compiler or linker has to know anyway. As far as I know D language is very good for such things.

<comment><USER21> You can use lifetimes to enforce that a certain thing is static data, and combined with an enum, you get the best of both worlds: compile-time constants require no allocations, but still flexible enough to allow run-time construction:

      enum StringRef {
          Static(&'static str),
          Owned(~str)
      }

and then `error` would take `StringRef` and be called like:

      self.error(Static("trailing characters"))
      // or
      self.error(Owned(fmt!("%u trailing characters", count)))

(There was even a pull request that added this and the corresponding one for vectors to the stdlib, but it didn't landed (yet): [https://github.com/mozilla/rust/pull/7599](https://github.com/mozilla/rust/pull/7599))

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I must say i am really surprised about the presented features of the language. It seems to take a lot of the nice things of more dynamic languages and puts them into a fast, compiled system language. I will have to try Rust, now!

</comment><comment><USER22> Rust looks really great and I would love to switch all of my C development over to Rust but last time I tried to compile it, it took a good hour or two. Has this changed at all?

<comment><USER9> Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile.

Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically.

We continue to work on compile speed of Rust code all the time.

<comment><USER23> Will you also work on providing a better Windows package? I don't understand why you don't just bundle all the dependencies, given that they all seem to be open source and redistributable.

Call me spoiled but I expect a one-click installer in this day and age. I still haven't tried to actually use Rust because of that and I am sure I am not the only one.

<comment><USER21> You're spoiled :P

But, windows is (unfortunately) a bit of a second class platform at the moment (although there have been some very big strides in the last week or so). So part of the reason for poor windows packaging is Rust isn't ready on windows yet (even more so that its normal pre-alpha-ness on Linux and Mac).

</comment></comment></comment></comment><comment><USER24> Why do people keep reinventing syntax? Quick tell me what the following mean:

struct Digest { digest: ~[u8] } // what's ~ here?

for self.digest.iter().advance |&byte| { acc = acc.append(fmt!("%02x", byte as uint)); } acc

What does the above mean? acc as a separate line and nothing else

I hate it when people reinvent the same construct that can be found in other languages but differently. I guess they want to do something different in their language, is it?

<comment><USER25> Rust does have some new syntax, but I think most of it is justified for making programming in it nicer.

The `~[u8]` would be written `std::unique_ptr<u8>` in C++. They're used everywhere in Rust, and having to write out unique_ptr would get awfully tiresome.

The `acc` on its own line is a result of "the last statement gets returned" like many functional languages do. If you were writing C++, you'd write `return acc;` instead. This one is more of a convenience, and you could get away without it.

<comment><USER26> > The `~[u8]` would be written `std::unique_ptr<u8>` in C++.

Wouldn't it be `std::unique_ptr<std::vector<u8>>`?

<comment><USER25> Indeed, it would.</comment></comment></comment></comment>


Using Microservices to Encode and Publish Videos at The New York Times - <AUTHOR> http://open.blogs.nytimes.com/2016/11/01/using-microservices-to-encode-and-publish-videos-at-the-new-york-times/?_r=0&pagewanted=all <comment><USER2> I worked on something like this for a small video rendering startup a few years ago. Our backend needed to ingest short (<= 12s) videos and strip the parts we needed in our rendering stack. We polled S3 (SNS wasn't consistently fast enough at the time) for new files in our Upload directory.

The uploaded video was sent to multiple microservices in a group of tens or hundreds of instances. One would "normalize" the video so we had the same frame-rate, size, and bitrates to work with. Another would rip the audio into a couple formats. Another would generate HLS streams with a few resolutions. Another would generate the HLS playlist. Another would split the video up into images. Each service uploaded its results to S3, named as a SHA1 hash of itself, and reported to a single API which kept track of the "tree" of files generated from each upload.

The system was based upon an early version of NodeJS, which worked fantastically well as a generic daemonized wrapper around the command line tools we were using for all the ripping and modifying.

About a year before I left the team we changed to GCS for the upload server because they had reliable immediate notifications to webhooks for uploads, but kept the rest of the system on S3, since our processing instances were all EC2.

Would have loved to have Lambda back then!

We had a similar set of microservices for rendering the eventual videos in near-real-time - but that's a whole different conversation.

</comment><comment><USER3> Seems a bit, um, over-engineered.

I made one of these 6 years ago for one of my clients using aws, on my todd and it's really not that complicated. Sure ours is a bit duct-tape and string, but seriously, it's not complicated programming. Probably took me a whole day.

At one point we switched from one encoding service to another and it took me less than half a day of chargeable time to change the code, so not sure why they need it to be so "flexible".

They've probably wasted more dev time on over-engineering it than they'd ever have saved manually adding a new encoding provider.

How it takes 4 of them to write it too I'm a bit mind-boggled. Reliable processing queues are a solved problem, encoding services are a solved problem, this whole thing was a solved problem 5 years ago, which is aeons in programming times.

</comment><comment><USER4> Hello all, my colleagues Flávio and Max also did a presentation of this system at the Streaming Media West conference recently.

Here are the slides: [https://speakerdeck.com/flavioribeiro/building-a-video- encod...](https://speakerdeck.com/flavioribeiro/building-a-video-encoding- pipeline-at-the-new-york-times)

</comment><comment><USER5> "The main goal of the team was to implement a job processing pipeline that was vendor agnostic and cloud-based" I wonder if they feel they've achieved it? How much work would it be to switch away from their choice of JS libraries and AWS? And if it's not trivial, what's the point?

<comment><USER6> IMO, they probably didn't want to be cloud vendor agnostic. They really wanted to be /video encoding/ vendor agnostic.

<comment><USER5> Do you need 20 microservices for that? If you choose to swap a video vendor, I guess you need to write wrapper API calls for the new vendor? Even if the new vendor provides that out of the box, NYT amortizes those costs one way or the other...

<comment><USER7> Where do you see 20 microservices? I count a couple of video-specific ones, + some integrations with their existing systems.

<comment><USER5> It may be more or less, depending on how you count the, but what I'm really trying to figure out is whether the over engineering and the extra abstraction layers are justified in this case and in general. My experience so far is the opposite - Microservices, orchestration etc hide the complexity but don't remove it, so if the shit hits the fan, you still have to look under the hood and with Microservices, probably under 10 different hoods or a hood under the hood of a hood :)</comment></comment></comment></comment></comment>


How YesGraph Got Its First 1000 Users - <AUTHOR> http://blog.yesgraph.com/post/63562259689/first-1000 <comment><USER2> >Blog. If you make great content, people will read it and share it.

This reminds me of a jwz quote, except I would rewrite it as such:

 _Some people, when confronted with a marketing problem, think "I know, I'll blog about it." Now they have two marketing problems._

The whole premise of an article like this is that a great product won't draw in users by itself, but it's assumed that a great blog _will_ draw in readers magically. I'm not saying you can't build a large readership. We've seen it done many times. But I'm skeptical that you have to do any less work than you would just to promote the product in the first place. The internet is filled with blogs that nobody reads... I'm writing one myself.

<comment><AUTHOR> Your comment is timely because I spent more time promoting this post than writing it. Compared to the last blog post on the blog, it got 100X the traction after ~3X the promotion effort.

I completely agree actually. The relationship between frequency, quality, promotion, and traction on a blog is fascinating.

<comment><USER3> How are you promoting the post? When I think of ways to promote blog posts I can only think of ideas which are quick (post to HN, tweet about it etc.).

What are you doing differently?

<comment><USER4> This doesn't really answer your question specifically, but one helpful way to think about it is to invert your process. Most people create content and then try to find a traffic source for it. The most successful marketers I know find traffic sources and then create content for them.

<comment><USER3> Thanks. That does resonate with me actually.

<comment><USER4> It's a _lot_ harder than most people think. A fun exercise is to seek out some message board or facebook page for a group of people you have _nothing_ in common with and see if you can repurpose or create content that engages them. Create a mailing list and see how many people you can get to sign up. It's great practice and you'll quickly realize how insanely difficult it is to interact with people regarding a subject they are passionate about without sounding like a paid shill. It's easy for those of us with a technical background to belittle the marketing folks, but there's an art to it that isn't readily apparent until you are staring at that proverbial empty piece of paper.

Edit: the oatmeal comics are a perfect example of this. The best advertising doesn't look like advertising.

<comment><USER3> Nah I totally get what you're saying. I'm just trying to teach myself some marketing skills at the moment (coming from a tech background) and I can't seem to get any traction at all. Interestingly I'm actually doing the exact mailing list thing you suggest already (conversionnewsletter.com). It's far harder than I though it would be from the outside and, as you say, great practice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I think it would be interesting to see a followup to this about when they make their first $1,000, $10,000, $100,000 etc...

Getting free users is not the hardest thing in the world. People like free things. Getting them to pay you is a different thing altogether.

<comment><USER6> I had an insightful manager once who told me 'you'd be surprised how hard it is to sell something for free.' The point being, getting their attention and usage is in fact pretty difficult.

<comment><USER7> Agree. Especially since people are sick of signing up for services, especially when it requires username and password.

</comment></comment></comment><comment><USER8> Thanks for sharing, we're facing similar problems and comparison is always useful!

Betali.st and similar "tools" worked well for us, although users from these services are easily to get in, but harder to keep engaged (I guess as they're used to jump to the next novelty).

<comment><AUTHOR> Did you compare the results across such alpha list tools?

<comment><USER8> The best for us was erlibird.com, say ~500 users in a couple of months.

</comment></comment></comment><comment><AUTHOR> I'd be particularly interested in hearing about different ad channels people tried early on. If anyone has any experiences to share, I'd really appreciate it.

<comment><USER8> In addition to Google Analytics, we tried Twitter, Facebook and Stumble Upon.

My feeling is that, at early stages, all outperform analytics unless you really know what you're selling and/or you've good landing pages. All have their specific "way to use it", e.g. on Facebook you need a page with engagement, on Stumble you need "something" that people can stumple upon :) e.g. blog posts.

Here I'm considering signups as conversions. Analytics (and Bing) were good to reach a lot of page views (that may still be useful).

<comment><USER9> When you say "Google Analytics" do you mean "Google Adwords"?

</comment></comment></comment><comment><USER10> Just started using Pinterest to post relevant infographics. I use buff.ly to manage all my social media postings, and I have them all linked together so that people interested in topics related to our technology can find us and learn about what we're doing.

</comment><comment><USER11> Ghostery blocks this entire article for me... (first time I've ever seen that happen)

<comment><AUTHOR> I think it's the linkedin widget. I'll remove it

</comment></comment><comment><AUTHOR> This new post by Brian Balfour is related and super awesome [http://brianbalfour.com/post/63581380690/customer- acquisitio...](http://brianbalfour.com/post/63581380690/customer-acquisition)

</comment><comment><USER12> doh!! Signed up for a trial just to realize yesgraph's a linkedin message cannon >:(

<comment><AUTHOR> Actually we don't send any messages over Facebook and LinkedIn. If we did, it would be with explicit permission per message.

Here is how it works

      1. Describe a role
      2. Invite people to make recommendations
      (using the invite link or the direct email flow)
      3. Connect to get contacts, and we make it easy to recommend good people

That's basically it! Try it out and let me know what you think: email@example.com</comment></comment>


iOS Development Isn't in a Good Place - <AUTHOR> https://medium.com/@karti/ios-development-isnt-in-a-good-place-5fb73c31483e <comment><USER2> "Swift has been taken over by theorists who debate academic things or solve yet another corner case in their type system, making a complex language even more complex, rather than deliver what their users (developers) actually need to build real-world apps."

I often wonder why they didn't choose a language like C++ instead of implenting their own language again? I mean, C++ has its faults and some argue that it is too complicated but you can still do plenty writing simple C++ without going over to the complicated stuff.

"NSInternalInconsistencyException " ouch

"Swift code can still crash in a way that the caller can't recover from, thanks to things like nil unwrap failures" Out of interest, what happens in this instance? Does a nil unwrap failure not throw an exception of some kind?

Code analysis that is part of C++ compilers catch a lot of these NULL scenarios, particularly if you use something like SAL on your code as a standard practice.

With regard to the last C++ template example, why can Swift not do this? It is possible to some extent in C# with generics but what is Swift missing?

I ask these Swift questions being a complete novice with regard to it; I've got a book I mean to get around to reading one day...

XCode is indeed rather buggy (but always has been???). It does do code analysis for C++ like identifying dead code (point 17 in the article) but I don't know about other languages.

As for Flutter, it's written in C++ but the examples all appear to be in Dart - any way of actually writing the application in C++??? Some pointers (excuse the pun) would be welcomed. (It appears impossible at the moment - you need to learn yet another language like Fart to be able to write for it...)

<comment><AUTHOR> > Does a nil unwrap failure not throw an exception of some kind?

No, it just kills the program, like a segfault in C++. Unlike Java, which throws an exception that you can catch and recover from.

> With regard to the last C++ template example, why can Swift not do this?

I'm no Swift typing expert either, but my understanding is that:

a) Swift generics are type-checked at definition time, not instantiation time as with C++. I believe other modern languages do it like Swift.

b) Swift doesn't promote types, so you can't subtract a float from a double. That rules out heterogenous types, like a float or a double. Even if both arguments are floats, the 0.1 on the right side of the < operator is a double, which can't be compared against a float.

c) Swift doesn't have template specialisation either, so we can't provide different implements, one for floats and one for doubles. If we could, we'd use 0.1f for the float case.

</comment></comment><comment><USER3> I disagree with most of the points. Every platform has some issues and no platform is perfect.

The documentation updation I agree. But commenting on WWDC videos is not good. You will not find any other platform videos like that. It is one of the highest quality of documentation you can find.

No one is saying watch all the years videos. I see whatever I am working on and intrested.

This article is written to find only mistakes.

The one major drawback of iOS platform is it's closed api other than that all the API's are well documented and I do not get any problems while using them.

<comment><AUTHOR> > No one is saying watch all the years videos. I see whatever I am working on > and intrested.

Yes, but if I'm working on image processing, videos related to that go back many years, and things covered in earlier videos are often not covered in later ones.

Other that than, let's agree to disagree. Maybe you're right, maybe not, we'll see :)</comment></comment>


The Climate Models are in Fortran - <AUTHOR> http://www.2blowhards.com/archives/2009/07/climate_models.html

<comment><USER2> PAUSE GOTO <http://j3-fortran.org/>

It is my premise that every CS course should re-introduce Fortran!

It is the oldest surviving computer language. Shouldn't evolutionary forces have wiped it out by now? Fortran and Cobol made America a place of successful big Science and Cobol made it great in Finance.

Compare this with to-day's computer languages used for trading on the Stock Exchange, not only they messed trading but they also messed the World's Economic flora and fauna!

<comment><USER3> Fortran persists because its first compiler has been so influential in compiler optimization research, the language has pretty much first-dips on any new performance improvements, and things that need to be fast are written in Fortran because of that.

The power of convention, it boggles the mind.</comment></comment>


Why a computer buffer is called a buffer - <AUTHOR> http://www.johndcook.com/blog/2010/10/25/buffers/ <comment><USER2> I did some research just now on what 'buffer' meant in the early days of computers. It actually mean a logical-or circuit. It appears to have been used in the input circuits of the ENIAC.

I can conjecture that the progression was logical-or -> input circuits -> input data -> I/O-based register -> secondary storage. But if so, the use in computing may derive from the 1950s when the "buffer" was part of main memory, and not a later use when it was a secondary temporary storage.

Anyway, the details of my research are in the moderation queue for this blog entry.</comment>


How Paul Graham Is Wrong - <AUTHOR> http://ma.tt/2014/12/how-paul-graham-is-wrong/ <comment><USER2> >Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline.

I've been a 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are _not as effective_ as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other.

I'm not advocating an open floor plan with noise and distractions. Even a set of private offices that share a common corridor to facilitate spontaneous conversation with a side conference room for group brainstorming, is superior to keeping Skype windows open.

Yes, there are the common examples of virtual remote workers at basecamp, Automattic, github etc. Those are not billion dollar companies. A lot of startups have ambitious goals and very hard technical challenges and you can't compete with a team made up of 99% remote workers. I see no evidence that this has ever been successfully done. Small scale modest businesses, yes, but not big ones.

Maybe you can hire a 5-person 100% remote team to launch a new web magazine. Journalists and editors by their nature seem to fit the remote work paradigm quite nicely. At first glance, it seems programming also fits, but only for modest projects.

Yes, the remote workers themselves will insist "I'm 100% just as effective offsite as onsite -- in fact, I'm more productive because I'm not interrupted by office nonsense." No doubt they feel that way but _the whole team_ isn't more effective.

Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent.

<comment><USER3> As another veteran of working remotely, I disagree. Conscious use of collaboration tools offsets not being in the same office together nicely. Real time communication via Hangouts or Skype are at a level where you can hold a good conversation without having to be in the same physical location.

Also, most offices (and businesses) are not really built to support proper collaboration and working conditions. As an example, due to a recent job move, I'm stuck in an office 80% of the time right now, and it's pretty miserable. It's an open office plan so there's constant noise and visual distractions, my boss can (and does) come over and interrupt me constantly on issues completely unrelated to my work, and in a former life the office was a welding garage, so I'm pretty cold most days this winter.

I hear of the unicorn offices, where they were built to support collaboration and focused development work, but I've always found reality has more in common with Dilbert than Valve.

<comment><USER4> Thing I've learned through hard experience: programmers (and yes, I am one) generally over-value individual productivity and under-value communication. So yeah, you can "hold a good conversation" via Skype, but you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

Programmers tend to want to squirrel themselves away and work on stuff to maximize their own personal productivity, whereas _organizations_ want to get a bunch of people working at a _group optimum_. That means that every individual takes a productivity hit for communication purposes, but that the organizational output is much higher than any individual could achieve. Hence, we get the fruitless debates about working conditions: what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

There's definitely a fine line between communication and distraction and it's hard to hit the balance (I've worked in some horrible "open-plan" environments too), but in my experience, programmers nearly always err on the side of too little communication, especially early in their career.

<comment><USER5> >whereas organizations want to get a bunch of people working at a group optimum.

It's an exceptional and rare organisation where this is even remotely realistic as a goal.

The _appearance_ of productivity is usually far more important than the reality - especially in mid/late corporations, where the most significant outputs are primate status plays and politics.

>what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity.

No sane manager is going to want to do that without a _really_ good reason.

>programmers nearly always err on the side of too little communication

That's because programmers like to be left in peace to work on small, relatively well-defined problems. Communication can be limited to progress and code reviews and goal-setting by team leaders. Everything else is noise.

The real problem with remote working is that too few corps understand it, and too many managers believe employees aren't functional adults who can work without constant supervision.

It's a management issue, not a programmer issue.

I think at some point we're going to see some faddy Harvard Review type write a faddy Harvard Review type book about remote, and it's suddenly going to become the new outsourcing. Because cheap.

But meanwhile - Paul Graham's problem is that he has a nostalgic hankering for a vision of SV and start-up culture that's already well on its way to being disrupted by the global talent he wants to move to the US.

If you're a world-class five percenter, why on earth would you want to move somewhere with insane living expenses and in-bred VC culture of the Valley when you can bootstrap and innovate around it elsewhere?

Does he really believe all that funding and schmoozing and presentation is _essential_ to getting a business up and running on a planet with an Internet?

Graham maybe needs to consider the possibility that those five percenters aren't his future employees - they're his future direct competitors.

<comment><USER4> Pretty much nothing you've written here refutes what I'm saying. You're a programmer, so naturally, you assume that your optimal use is programming, and you draw conclusions starting from that assumption. But if you _moderate_ that assumption a bit (you're also well-used as a planner, an organizer and as a communicator, among other things), you arrive at a different set of conclusions.

 _" The appearance of productivity is usually far more important than the reality"_

No, that's just cynicism talking. Larger organizations care about your personal productivity, but they care _less_ than small organizations. Part of the brilliance of modern corporations is that you don't always have to be at peak productivity as an individual in order for the company to profit. Which means, in turn, that you can do things like get sick or have a family without having to give up your job. The flip side of feeling less efficient is that you have some cushion when you actually _are_ less efficient.

 _" I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity."_

You obviously don't want to interrupt someone gratuitously, but the point is that _your_ perspective on what's important can differ wildly from your _employer 's_ perspective. Keeping someone in "The Zone" is not the only goal. An employee in "The Zone" who is churning out "The Wrong Thing" is worse than no employee at all. So you need communication. And as soon as you need communication overhead, people are going to be interrupted. It's a cost of doing business.

</comment></comment></comment></comment></comment><comment><USER6> Programmers, if they have a choice, like remote or at least some remote.

Managers + VCs, if they have a choice, prefer all in the office so they can keep power but this actually makes them less competitive and more susceptible to physical disruptions: moving an office, an employee moving, time, office politics, commute, distractions, over meeting and more.

The PG essay on this was glaringly overlooking that you can be a US based programmer and be good or great even if you aren't in SF. Tech companies have a responsibility to not be so monoculture and they currently have a single point of failure in Silicon Valley, which from an engineering perspective is poor distributed design and very little redundancy.

There are benefits of being in one place, the ability to meet physically and be on the same page but we all know the real work gets done back at our desks in our solitary focused modes when it comes to programming and making products. Then we open up for feedback and iteration, then again back to work.

The work part should be setup so programmers perform their best. Just like some of the best scientists, writers, etc, they need their lab/office where they can get somewhere with the problem at hand, not an open office in SF.

Glad Ma.tt mentioned this as he is a leader in the right kind of tech leadership we need: spread it around, live better, work hard, deliver solid products, from anywhere...

<comment><USER7> I'd add that the PG post is a symptom of a disease. A disease that that is brewing in the echo-chambers of SV. Note also the recent post where PG claims that "mean people fail".

The more the VC community gets un-hinged from the reality the quicker the inflation of the bubble and the crazier the assertions.

Time to get out of the bubble.

<comment><USER8> Part of the problem is that investors might understand the businesses they invest in from 30,000 feet, but they frequently have no idea how their portfolio companies are actually run. If some of them went undercover and applied for jobs at their own portfolio companies, they'd probably have a different perspective about the "talent shortage."

<comment><USER9> They'd probably get rejected for jobs at their own portfolio companies. That's how out of whack hiring is.

<comment><USER10> Not sure why you're down voted, graduation year alone would get all VCs fall at the first reading of their CVs.

</comment></comment></comment></comment></comment><comment><USER11> Meh. Here is the tradeoff.

If everyone is co-located, you have inconvenience and higher productivity. If everyone is remote, you have an inherent overhead, but enormous flexibility. If some people are co-located and others are remote, you naturally tend towards a divide where people who are co-located without thinking about it wind up networking with each other and excluding the remotes.

If you are a small startup, the productivity difference really can be the margin between success and failure. Hence the pressure to co-locate. But conversely the availability of better talent in theory can allow for a better workforce which might outweigh the productivity overhead of remote work. But when there are just founders, by definition you can't assume that there are better people available. And the need for close working at the initial stages gives strong pressure to co-locate.

Therefore there is a natural tendency for startups to co-locate. And once the seed of the company is co-located, switching to a remote model is going to involve crossing a difficult cultural barrier that not everyone will succeed in. Thus the continuing pressure to co-locate.

<comment><USER12> I think you might be mistaken in the assumption that remote working leads to less productivity than co-located.

This is purely up to the team. Sometimes being co-located leads to over meeting and lots of time spent on disruptions and chats, while remote working lead you to be more professional and talk to your co-workers only when necessary for the job.

<comment><USER11> I think my assumption is justified. To address your suggestion, it is safe to say tht early stage startups which are inclined to over meeting are guaranteed failures no matter what.

</comment></comment></comment><comment><USER13> The article assumes its conclusion:

> amazing technology that allows us to collaborate as effectively online as > previous generations of company did offline

That's a huge claim, and it's disputable. For example, I've worked both ways a lot and find remote work to be dramatically less effective.

If you accept the claim, then sure, the startups PG was writing about are missing the obvious, and for the most ironic of reasons—technical backwardness. That's possible. But there's also a lot of wishful thinking and saying-makes-it-so on this subject, which comes up on HN all the time. A lot of people just really, really want this to be true. That alone doesn't make it true, and I think it's at least as possible that desire is distorting the analysis. (Which, as someone whose whole career has been plagued by an unsolvable constraint problem of family, work, and geography, I can easily understand.)

Fortunately, we're going to find out. If all those startups are doing it wrong, then there's a gigantic market inefficiency and we'll soon see a new wave of smarter, less backward companies doing much better.

<comment><USER14> What you say about the article may very well be true, but the surrounding discussion is not as bad as that. I recognize that the problems pointed out by PG ("chance meetings") and others are genuine problems that haven't yet been solved by technology. However, what I object to is that the rallying cry (and a lot of PG's essays are now rallying cries for how the industry should be, even if he just thinks "I'm just a dude that likes to post my thoughts on the internet, I don't know why everyone objects") of the industry is "move more people into open offices in SV and NYC", rather than "improve the remoting process".

<comment><USER15> Twitter = chance meetings as a platform.

</comment></comment></comment><comment><USER16> I just finished a remote job search. I'm in Los Angeles, and most of the companies I talked to were in SF. I had previously worked remotely for a company in New York (Etsy), and I was honestly really surprised how hostile SF companies were to the idea. I was mostly going through personal connections, so I assume that I was getting the gigantic break of having a solid recommendation that most people can't get. (I feel bad about this, but it is what it is.)

I have been on both sides of remote work, so I totally get that it's not a slam dunk. It works a lot better for companies that have a strong culture established in a home base, and it works a lot better for experienced folks than green college hires. I have shut down the interview process myself when I felt like working remotely wouldn't work out at particular companies.

Even given all of that, I was pretty amazed how quickly some of the conversations got shut down. No remotes, we don't care who you are or what your experience is. I didn't talk to any companies outside of SF that were that quick to say no.

FWIW I landed at Stripe, which in fairness is probably one of the companies pg had in mind when writing his original article. I agree with the spirit of this, and I also don't really agree with a lot of things in pg's essay. But the particulars here might be totally wrong. At least one company in his network is really remote friendly.

<comment><USER17> How does remote working get done at Stripe? what tools? What practices are a consolidated standard? It would be really useful to the discussion if you could share something with us.

</comment></comment><comment><USER18> I am still convinced that before anyone can confidently determine if a talent shortage really exists, they must first fix the transportation issues. I've made this comment a few times already, but if I had a magic wand and made a BART-like bullet train materialize that connected San Francisco to San Jose, Danville, San Ramon, Mountain View, Palo alto, Cupertino, Foster City, the "out-of-reach"'ish areas of SF like where SF Zoo is and where the House-Of-Air is located, and the Persidio... we'd would be having a very different conversation.

In short, I believe it's the commute that engineers don't want causing a big part of all this gentrification and talent shortage talk. Personally, my Linkedin says I won't take any job that I can't walk to from a BART station. Google is an exception though; the whole GoogleBus at MacArthur BART situation.

<comment><USER19> I don't know if I'm one of the great engineers PG and others are talking about but I have no interest in living in the Bay area, whether as it currently exists or with even more people.

You can solve the "transportation" issue by avoiding having to transport anyone in the first place, which is exactly what the author is speaking to when they suggest remote working arrangements.

<comment><USER20> Or maybe even transporting some of those opportunities to areas closer to you. Starting new VC-backed companies in Detroit, Denver, Boston, Durham, Austin, Memphis, Nashville, Louisville or other regions would give you access to some great talent that simply prefers to live in other areas of the country.

For an industry that often derides 'monoculture', the SF tech scene sure resembles one.

</comment></comment></comment><comment><USER21> PG ignored current trends and recent history to an absurd degree in his recent blog post.

Not factored into the equation: An actual, provable, verifiable history of illegal salary-fixing. The experiential reality that most immigrant programmers get a lot of mistreatment, both from racism and from their own incompetence - and the related experiential fact that a lot of immigrant programmers are utterly incompetent.

The rhetoric of these arguments talks about 10x programmers, but companies really seem to prefer importing 0.1x programmers or even -10x programmers.

Meanwhile, tons of companies have immense success with remote work, and the wage changes associated with the last ten years are not at all commensurate with the increased value of programming work. (See aforementioned illegal salary-fixing.)

Is remote work easy? No. But is PG's business about doing easy things? No.

I literally just ran grep -c "table" against a text dump of this comments page. The count was 122. 122 uses of the table tag. Since that includes </table>, 61 tables.

This whole argument is as up-to-date as the HTML on this page.

</comment><comment><USER22> So much this. I have pretty much stopped clicking on the HN posts from HN companies looking for employees, because almost none of them offer remote work. Which is too bad, because there are quite a few HN companies that I would love to work for.

<comment><USER23> I highly suspect that it's a consequence of being a YC company. The president of YC has even publicly denounced allowing remote work.

> As a side note, avoid remote employees in the early days. As a culture is > still gelling, it's important to have everyone in the same building. [1]

1\. [http://blog.samaltman.com/how-to-hire](http://blog.samaltman.com/how-to- hire)

<comment><USER24> Seems like setting yourself up to have an 'everyone is remote' culture at that point in time would make the most sense.

<comment><USER23> That makes the most sense to me as well. If you're planning on having a distributed team, doing it early on is the best, and perhaps the only, time to do it.

</comment></comment></comment></comment><comment><USER25> The idea that remote work is a solution to immigration is also a meme on Twitter. I'm not sure I understand it.

A San Francisco tech company can employ developers in Krakow to work remotely without dealing with visas. But those developers either need to be 1099 contractors, or loaned out from an outsourcing firm.

Both options are poor. Outsourcing firms for obvious reasons (introducing a middleman that serves no purpose whatsoever except to serve as a legal fig leaf). 1099 because (a) it creates a second class of employee and (b) because it's technically unlawful to classify full-time employees as contractors.

<comment><USER26> Do you know how Automattic, Github, and say Basecamp do it?

<comment><USER27> Automattic "employees" outside of the US and Canada are contractors.

(I used to work at Automattic)

<comment><USER28> This is no longer accurate. Some remain "contractors" still officially due to regulatory issues, but we now have employees in multiple locations outside North America. And that list of locations is growing.

(I work at Automattic)

<comment><USER27> Figured this was the case but assumed it didn't changed the gist of the answer too much. tl;dr actually employing people in other countries is difficult

</comment></comment></comment></comment></comment><comment><USER29> I have completely 180'ed on this topic. I used to think to be a successful startup, you all had to be in the same room, ideally at a big huge desk etc.

After working at my current startup, I realize I was wrong. We are an entirely remote operation, and have been since day 1. A few of us are in Austin, and rarely meet for a face-to-face, but it's more of a 'oh yeah, you actually exist' meeting rather than a hash-it-out sort of meeting.

I think the reason we have been successful is because being remote has forced us to write things down, in our wiki (in the form of product specs) and in JIRA (in the form of specific features and bug fixes). With just those two forms of written communication, we've solved 95% of our communication needs. We almost never skype or use video conferencing... it's just not needed.

The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough, but does deserve more explanation. (unfortunately I can't muster the amount of typing atm).

IN the end, we can focus on getting work done... without the distraction of office chatter, commuting, long lunches.

<comment><USER30> > The other reason we are successful is due to experience. We've all done > startups before, so we know the drill. I can't emphasis how important this > is enough

I've worked remotely for a few years now and think this is the key. I would not advocate hiring junior developers remotely. There's too much risk in it. I was once faced with the task of trying to mentor a junior dev remotely and it just didn't work.

<comment><USER31> In general I would agree, but I think it also depends on junior developer in question. Every now and then you meet someone whose overflowing intelligence, talent and work ethic will make them an exceptional engineer, but are not there yet. It would be a shame not to support that.

I recently mentored such person and she is already one of our most productive developers.

</comment></comment></comment><comment><USER32> For argument's sake, if remote work isn't the solution, how about taking the middle ground? I don't see a lot of companies setting up offices in other parts of the world until much later on the growth curve. Is there a fundamental reason for this? Is it simply cost? Seems to me that SV companies can do great things by even opening up 2-3 person shops elsewhere in the world. You then have the compromise situation of having a few people collocated, which should cut down the need to continuous remote meetings, and at the same time provide simultaneous access to new growth markets. In effect, you have remote offices as opposed to remote employees, which seems like a much more efficient organization of resources.

</comment><comment><USER33> If you do this right, there's no "remote", there's no "overseas", there's no day-to-day distinction in how someone works between whether that person happens to live in the country the company was founded or not.

</comment><comment><USER34> Isn't there a tremendous upside to being physically co-located? Even if the teams are remote, are the founders not usually located in a 'tech hub' city (SF, NY, etc.)?

Matt says to let people 'live someplace remarkable', but for most of the world that want to work in technology SF _is_ someplace remarkable.

The benefits of using group collaboration tools are still available, but you have other people working on overlapping problems on your doorstep, support and service companies, and access to intelligent finance.

<comment><USER35> The Bay Area is pretty awesome however the housing prices are not, I would say it's the single biggest issue here. I've been told my $2000/mo Rent for a 500Sqft 1Br Apartment in San Mateo is a "good deal".. to contrast that the mortgage on my 2000Sqft house back in Miami (not far from the beach) is $650/mo including Taxes and Insurance.

</comment></comment><comment><USER33> It's worth repeating that I absolutely believe we should improve and dramatically open up immigration in the US, and applaud PG's and other's work there, but in the meantime you don't have to handicap your company because of the current politics around this issue.

</comment><comment><USER36> There are companies like teleport [http://teleport.org](http://teleport.org) that try to visualise this potential with data.

Also recommend this YCombinator startup school talk by Balaji Srinivasan on this topic: Silicon Valleys Ultimate Exit [https://www.youtube.com/watch?v=cOubCHLXT6A](https://www.youtube.com/watch?v=cOubCHLXT6A)

</comment><comment><USER37> Spot on! Seems the "shortage" isn't in labor but in deference to employees as people. Wouldn't you want a horde of folks willing to work 80+ hours for Ramen? </cynic>

</comment><comment><USER38> It's interesting how many commenters read "remote" as "contract" or even "overseas". There are lots of developers outside of SF, NYC, Chicago, etc. that would relish the opportunity to still live their suburban/rural lifestyle and avoid a lengthy commute.

One advantage for companies in big cities is they can usually hire these remote employees at a discount. It can get a bit hairy when two remote employees doing the same job are paid differently, but that is already the case in many situations.

The other obvious advantage is that companies that hire remote employees have an almost unlimited candidate pool. Even if a company chose to limit hires to their own country, the only group they cannot hire would be candidates unwilling to work remotely. Based on my discussions with thousands of programmers over the years, I'd suspect this is a very small group.

</comment><comment><USER39> This is where I think Paul Graham gets it wrong:

> Exceptional programmers have an aptitude for and interest in programming > that is not merely the product of training.

This is the old "you're either an exceptional programmer or you're not" myth. This is one reason why diversity in tech has regressed since the 80s.

I agree that geopolitical boundaries should matter less in the software business. However, I strongly disagree that this is the solution to programmer scarcity. Expanding your source of resumes to the entire world only delays the inevitable. Why focus on removing the dependency on the passport variable, when we still have such a strong dependency on gender and race?

</comment><comment><USER40> I find this post and many remote-advocacy posts like it are overly optimistic about the problem of timezone differences. A critical flaw is that most of the "solutions" mentioned assume you're all working at the same time. (Skype, G+ Hangouts, chatrooms.) That may be ok for workers living in less expensive parts of America or the western hemisphere, but that certainly doesn't hold true for overseas workers, which is what Paul Graham is mostly talking about with immigration.

An 8-12 hour timezone gap is not something easily bridged by chatrooms and videoconferences. To even have a conversation with the remote worker/team, one or both of you need to schedule time at very early or late hours and even then you only get a little bit of overlap. For the most part you are left to collaborate by email or blogs -- which is a _significantly_ degraded way of collaborating, much moreso than just not being face-to-face. Without an easy way to have a realtime conversation, closing the loop on an issue can take 24 hours.. or several _days_ if there is a lot of back and forth.

This style of working can be very difficult in a highly dynamic, less structured, fast moving startup environment. It is not magically solved by "modern communication tools" or high-latency asynchronous working styles. The fundamental issue is.. daylight and human sleep schedules.

I wish all conversations about remote work would qualify which context they're talking about -- near or far timezones -- instead of just lumping it all together as "remote work from anywhere".

</comment><comment><USER41> I've worked both onsite and remote as a software dev / data engineer. I started out onsite. There are major disadvantages to remote work:

* Amount you learn from the office community is orders of magnitude lower than onsite. If you're good at pushing yourself to learn new things, that can help, but your knowledge will almost certainly end up less diversified living remotely. You're just not exposed to the company's tech challenges as deeply, yet that's usually one of the main reasons for working at the company.

* You don't necessarily get top projects, but rather perhaps good projects that fit remote work. Taking a remote role almost certainly hurts your career if you want to compete with traditionally onsite roles.

* You likely don't get to participate in hiring or shaping the culture in a substantial way.

* You'll have a much harder time building the network needed to get access to key resources (e.g. data, people, etc).

* Your company better have a nice VPN or you're going to be doing a lot of systems-oriented stuff for yourself. It can be fun but can slow you down.

* You're probably more likely to be laid off.

The company I worked for started offering remote much more frequently due to recruiting and retention problems. I don't think the net result had a very positive impact on the Eng org. In particular, a lot of junior people were allowed to go remote for retention reasons but they didn't end up doing much in that role-- they would have been much better off just joining a different company (either local to them or one with a much much stronger remote culture).

Agree with the poster that PG's essay has some holes; seems orders of magnitude less polished than his older essays.

<comment><USER41> Downvotes because I insulted pg or because I argued remote was bad??

</comment></comment><comment><USER42> This is a great how to article on remote management. The tools he lists are all there. The author mentions Skype, Slack, G+ Hangouts, and then surprisingly WordPress. Would the author care to discuss how _he_ specifically has used WordPress to remote manage a team? I think the issue is that most managers don't want to remote manage which makes me wonder, "Why?"

<comment><USER43> I worked for Mullenweg for a year at WordPress.com to write a book about all of these questions. It documents all the tools I used and what life was like as a remote manager of a development team.

[http://www.amazon.com/Year-Without-Pants-WordPress-com- Futur...](http://www.amazon.com/Year-Without-Pants-WordPress-com-Future- ebook/dp/B00DVJXI4M)

You can read a free chapter about culture from the book here:

[http://scottberkun.com/2014/why-culture-always-wins-an- excer...](http://scottberkun.com/2014/why-culture-always-wins-an-excerpt-from- the-year-without-pants/)

<comment><USER17> Do you recommend this book to understand remote working dynamics at Wordpress ? Learning from companies that succeeded in setting up the remote working practice is definitely the best way to understand if you can put the process in a bottle. Anyway thanks for sharing this title.

</comment></comment></comment><comment><USER44> It's all been tried and people know the tradeoffs, and there are tradeoffs no matter what you might think. The drive and culture that can develop when a small focused team spends every waking hour together can become almost cult- like. This culture is what VCs want to foment. It's also why they like hiring 22 year olds that can be more impressionable.

</comment><comment><USER45> Under jasode's thread, you can see that people are missing Paul's point. He's not saying that working with close proximity is the "best" way of working. Yet most people here are debating which type of work is. Each company, market, vertical, team, etc. will vary in manifold ways.

What I believe Paul is asking for is that companies have the option to choose. Right now the option is available to anyone to hire remotely in one way or another. This is not the case with physically hiring into the country. Almost every startup I've worked at has had issues trying to hire exceptional people from another country. In almost every case, we lost those hires to the system and were forced to start the search again.

If a small, remote, international startup grows fast enough and they decide that working together under one roof in the U.S. fits their new needs, they should have the freedom and choice to do so.

</comment><comment><USER46> The topics of remote work and of immigration reform seem unrelated to me.

A better immigration system would be better for the U.S., in that it would allow the best programmers to come here if they want to. That is clearly better for the U.S. as a whole, since it would make it easier to raise the national technical talent level relative to other nations. These new Americans would hopefully become citizens, raise families, vote, sit on school boards, run for elected office, start companies, etc.--improving the nation from within over time with their perspectives, talents, desires, and hard work (as past generations of immigrants have).

Contracting with foreign workers through the Internet does not achieve any of those long-term national goals.

Once new workers are legally within the U.S., I agree that they should have the freedom to choose remote work if they want to, or colocating work if they want to.

</comment><comment><USER47> Paul Graham is deferring to his portfolio founders' words and actions. Does author believe all these smart and highly incentivized founders are wrong, too? I hope he realizes how strong that claim is and that by doing so he should accept the burden of proof.

</comment><comment><USER48> I would _love_ to have remote work, but I am honestly unsure about whether I'm good enough at my job to enjoy it. My concern isn't with performing my current job, but every promotion/job change I've had has been because of the things I learned in some free time from somebody sitting next to me. It's so nice to be able to wander over to a smart person and ask about some random problem I've been having in an area in which they're an expert. I have no doubt I learn more in an office than I would in my living room.

...then again, that's probably why remote workers say they're more productive.

</comment><comment><USER49> The problem with this argument is that it lumps all versions of "Remote" together, but that's not really true. There's a huge difference between the guy who is remote because he has a long commute, vs the guy who is remote because he lives on the east coast, vs the guy who is remote because he's in china or london.

The common theme of all that is: timezones matter a lot. It's hard to collaborate with someone really far away because they'll tend to be asleep when you're awake. Programmers like async communication for a lot of reasons, but real-time is important too.

</comment><comment><USER50> I would be interested in reading a PG essay responding to this very point.

</comment><comment><USER51> Meh. Keep the barriers high and the labor market tight for as long as possible. Let companies compete for workers like the good ol' days. Let startups use more of that VC cash on its workers and also help keep rates up for IT workers across the country.

I know we Yanks get no sympathy from the rest of the world, but labor here has taken a beaten long enough.

And, I say this as a dev-turned-founder who would presumably now want to see low rates and a bigger pool. I guess I just appreciate more a little "economic justice" from time-to-time!

</comment><comment><USER10> Let us assume a company where everyone works from home and meetings are held in Starbucks or airport lounges. Such a company would save many thousands of dollars per employee per year, maybe tens of thousands. No real estate, no receptionist, no cleaners, no equipment to buy or IT dept to support it...

Such a company would probably pay less than market rates, due to the "perk" of allowing remote work? But where's that money going? If you are an engineer considering remote working, make sure YOU get a slice of the pie.

</comment><comment><USER52> It is clear various tools can be effective or ineffective for companies and individuals – this is a __very __subjective topic. However, since many tech companies, who have subjectively decided they want to have all of their employees in the same physical location, have a talent shortage problem, it would seem only beneficial to modify our immigration policy to allow more of these highly skilled individuals to work in the US. There outcomes of making such changes are almost exclusively positive.

</comment><comment><USER53> I was part of a virtual team many years ago, before all these tools existed. I was the only one on the West Coast, not in a position to meet others face to face -- at least not more than once, for a conference I attended -- and was the newest to the group, younger than most of the others, etc. There were several dimensions in which I was an outlier for the group. Ultimately, it ended on something of a sour note. I was basically accused of being a "traitor" for doing my actual job. I and the person at the top had very different ideas about how things should be handled and my domain expertise was not really respected. (After my departure, the project that had benefited the most from my input kind of died back down again.)

I spend a lot of my time online and I have taken a lot of online college classes. When I had a job at BigCo, I got in the habit of emailing my questions to my immediate boss, whose role included answering technical questions. For various reasons, I was unable to master the art of catching her at her desk or whatever. Emailing worked better for me.

I and some of my teammates got transferred to a new team that initially did not have someone in the technical role she filled. Until the new team got their own technical lead, we were all still assigned to our old lead. Other teammates of mine who were used to having face-time with our lead were incredibly frustrated. My transition was quite smooth. I rarely needed face- time with her to get good results. I just continued emailing my questions as usual. I also was not particularly "likable." I was quite ill at the time and not at my smoothest socially. I also just come from a more formal cultural background than the people I was surrounded by. I was not interested in being too schmoozy. In the short run, this seemed to hurt me a bit. But once I got transferred to a new team, it was to my benefit: Getting my questions answered had been a purely professional function, not something rooted in being friendly or whatever.

So I think there are good points on both sides of this argument. I see several really good comments here falling on either side. And I think the disconnect probably has to do with some social thing that can be fostered remotely but many people aren't good at it. As we develop more online/virtual/long distance cultural practices, I think this will become less of a divide for some people.

</comment><comment><USER23> Great points. I'm actually working on a longer piece with actual numbers as a follow up to remote working as a solution to the talent "shortage".

</comment><comment><USER54> Just to jump on the point of being physically co-located: I've done both. There are pros and cons to each. What I've found is: it all depends on the people in the company. Some work best when they're right next to you, able to share a drink after work to decompress. Others want to run to the beach to go surfing right after a meeting. Both can be equally talented, but vary significantly in their modus operandi.

</comment><comment><USER55> For entry-level people, I've really found an office helps with mentoring and culture assimilation in a way that fully-remote cannot even remotely reach.

I still don't feel there's any reason you need to physically exist in the Bay area though. Open an office somewhere that's both attractive and affordable for people to live and you enable the best of both worlds.

</comment><comment><USER56> If my business pays for a great programmer, I want that programmer's knowledge, experience and attitude to diffuse to the rest of my team (... not that I have a business, just sayin' :-). Much harder to do this if that great programmer isn't in the office.

<comment><USER57> In my eight years' remote working experience, your statement is false.

<comment><USER58> What he is saying is that it is harder, not impossible.

Are you saying that remote work is as good if not better than being physically-located?

<comment><USER57> I'm saying that's it's not harder. Thus his statement is false.

</comment></comment></comment></comment><comment><USER59> I've written an article on this issue recently as well.

[https://medium.com/@sarperdag/how-to-thrive-as-a-digital- tal...](https://medium.com/@sarperdag/how-to-thrive-as-a-digital-talent- wherever-in-the-world-you-are-6b558ddef519)

</comment><comment><USER60> My $0.02 all here [http://blog.learningbyshipping.com/2014/12/30/why-remote- eng...](http://blog.learningbyshipping.com/2014/12/30/why-remote-engineering- is-so-difficult/)

</comment><comment><USER61> The next question is what happens to people who want to work _in_ the US?

</comment><comment><USER62> This is my inspiration to create [https://github.com/lukasz-madon/awesome- remote-job/](https://github.com/lukasz-madon/awesome-remote-job/)

</comment><comment><USER63> As I work remotely, it is the best. I think it is up to the individual. If the individual does not want to work, he or she does not want to work regardless at home or at the work place.

</comment><comment><USER64> The author is forgetting that this is very unattractive for remote developers. Maybe not so bad if you live in a country without decent health insurance and retirement, but for others you'd lose these benefits by becoming a contractor.

EDIT: being more explicit I was specifically thinking of remote workers from other countries when writing this statement. Obviously, remote work within the U.S. wouldn't make you a contractor. But how would this work for non us- citizens?

<comment><USER65> The article didn't say anything explicitly about remote contractors. The two companies it did reference Automattic and Github have remote full time employees.

<comment><USER66> Another commenter in this thread said that Automattic workers outside the US and Canada are contractors:

[https://news.ycombinator.com/item?id=8811183](https://news.ycombinator.com/item?id=8811183)

</comment></comment></comment><comment><USER67> Remote workers present challenges.

Which is worth more a company with 5 employed engineers or 5 oversea contractors?

Managing developers across time zones can be a big problem. If the developer in the Ukraine has a question for a manger asleep in California, he has to wait.

There is no casual connection between people - no going to a bar to talk things over, no stepping away from the computer to talk. All communication is filtered down through the pipes.

<comment><USER14> The larger point of this discussion is that mass immigration presents other challenges, some much harder to overcome. For example, the nightmare that is the political discussion of immigration in the USA, and for another example, the skyrocketing living costs in US cities that are tech hubs.

Trying to solve the problems you outline seem to be technical, which are easier than the fundamental problems of politics or economics.

</comment></comment><comment><USER68> I read the PG article as a "grass is always greener" argument.

<comment><USER68> I just read the footnote:

[1] How much better is a great programmer than an ordinary one? So much better that you can't even measure the difference directly....

You do not get to hire those people. And if you do it's on their terms. Perhaps you get to invest in their ideas if you're lucky.

</comment></comment><comment><USER69> firstname.lastname@example.com

</comment><comment><USER70> > In a region that prides itself on disruption and working from first > principles, San Francisco's scaling problem is pretty humorous if you look > at it from the outside: otherwise smart and inventive founders continue to > set up offices and try to hire or move people in the most overheated > environment since there were carphones in Cadillac Allantes

This is the best rebuttal to the more-immigration-so-we-can-haz-programmers I've read in a long time. And its so true. The way the current work visa (h1-b) is setup makes it far more likely that good programmers get tied to stodgy plodding firms and not smaller innovative ones that tech needs them to work for. Remote work and rewriting the current h1-b laws to make it so that h1-bs can more easily transfer their work permits and work for whoever they like, whenever they like ... remotely as well ... just like their American contemporaries would open up lots of supply.

but what the big firms really want is more pliant programmers who will work within the rigid confines they set up. Thats why we're not talking more about the mechanics of the work visa and the green card process which is currently set up pretty restrictively.

</comment><comment><USER71> Oh dear sorry to rain on your parade experience shows that the way to get the best performance is collocated teams of developers ideally coloacted with the end customer.

I know this isn't what a lot of HN readers want to hear but I bet Paul and many other VC's would bear me out.

<comment><USER70> Do you actually have data on this, or is this completely anecdotal?

<comment><USER71> 30+ years of experience also read steve McConnell.

</comment></comment></comment><comment><USER72> Hey Matt, I'm so glad you felt it necessary to include that DHTML snowstorm. My laptop fan really needed the exercise and I have your ~500-line JavaScript workout to thank for it!

Of course, I closed the tab pretty much immediately after noticing it so I didn't read the article. Can't wait for unnecessary js to go out of style.

<comment><USER73> As soon as I saw the snowflakes falling, I thought, "Oh jeez, someone on HN is going to be having a meltdown over this!"

Sure enough.</comment></comment>


With workers on edge, SF tech companies offer self-defense classes - <AUTHOR> https://www.sfchronicle.com/business/article/With-workers-on-edge-SF-tech-companies-are-13563235.php <comment><USER2> First lemme start with this: [https://youtu.be/i54grFI- JhA](https://youtu.be/i54grFI-JhA)

Now compare that to the "training" the organization in the linked article, Impact Bay Area, provides: [https://youtu.be/qRgdwH_V07c](https://youtu.be/qRgdwH_V07c) [https://youtu.be/w0xeg0E3_5E](https://youtu.be/w0xeg0E3_5E)

Look how compliant the attackers are. Do they actually expect assailants to just roll over like that? And read the caption on the second video: "I've been backpacking solo around the world since October 2015, and want to empower other women to travel anywhere by themselves and know that they deserve to walk on every single inch of this earth."

^Yeah, that's the sort of attitude I bet those two Scandinavian women had. They ended up getting their heads cut off. I went to the website of Impact Bay Area and there is no indication of the martial arts backgrounds of the instructors (if any). They offer "instructor positions" on their site, which includes 100 hours of training by their existing IMPACT Staff, with no mention of minimum requirements or skillsets for applicants.

But IMO martial arts isn't even the best way to actually achieve improved safety for your workforce in dangerous neighborhoods. A good anti- terrorism/physical security course, combined with "combat hunter" instruction and practical application, would give people the mindset to develop and maintain a keen situational awareness and a sense for potential threats. Then have them do some interval sprints and other cardio training, because the best thing they can do if they ARE physically threatened is RUN.

The sort of "self defense" theater @Impact Bay Area is just going to give people a dangerously false sense of confidence. And they are charging $750 for these "classes"??! Are people really so clueless as to spend money on this sort of training? I feel like I could grab a couple of ex-military friends, charge slightly less, and still deliver a higher-quality curriculum than this. -_- Except I don't live in the States and really have no desire to spend any significant amount of time in SF....

Edit: Here's a video on the combat hunter program: [https://youtu.be/7t-BXqPf- jM?t=85](https://youtu.be/7t-BXqPf-jM?t=85) basically it helps you develop "spidey senses". You are more cognizant of your surroundings and perceptive of oddly-behaving people or objects (in my experience).

</comment><comment><USER3> They could have expanded offices in SJ --lots of space, low-crime, but instead they choose locales known for high relative density of mental disorders (given services for them are in the general area) --but instead they indulge on "cool" factor and not business (as well as employee safety).

<comment><USER4> ya but they could also teach us karate

</comment></comment><comment><USER5> it's so ironic. I can't believe this is the global center of tech.</comment>


Google's misleading security claims to the government raise serious questions - <AUTHOR> http://blogs.technet.com/b/microsoft_on_the_issues/archive/2011/04/11/google-s-misleading-security-claims-to-the-government-raise-serious-questions.aspx

<comment><USER2> TL;DR summary: after Microsoft got a big government contract, Google sued. In their filing, they claimed that Google Apps for Government has FISMA certification. DOJ says no: Google Apps Premier has FISMA certification, but Google Apps for Government doesn't. Microsoft is (unsurprisingly) appalled.

<comment><USER3> It also may not be apparent from the domain name, but this is a Microsoft corporate site.

<comment><USER4> Yes, although the banner "Microsoft on the Issues" is a tipoff.

</comment></comment></comment><comment><USER5> Legal issues aside, does anyone know enough about Google Apps Premier and Google Apps for Government to tell us if there are real security distinctions that would make this something more than lawyers bickering?

</comment><comment><USER6> The author constantly refers to "Google" as if it's a single person. I think the most reasonable explanation will involve some large amount of miscommunication between several people who work for Google. The author seems overly aggressive, and assumes that whatever "Google" did, it did rationally and intentionally.

Nevertheless, Google's response will be interesting.

<comment><USER7> While I agree that it may very much amount is 'miscommunication'. You would think - that a company which proud itself on having the 'best, brightest and smartest' would do its own due diligence before openly starting a significant legal battle with Microsoft - a company renown for suing everyone in existence - and complaining to the government that it's basically being anti- competitive.

It's not about rational intent - it's about suing the government over alleged anti-competitive behavior only to not have certification in the first place. Whether it's a miscommunication or something else - the fact that it appears - prima facie - a complete ass up by Google is humorous.

I say humorous only in the sense that it loathes Microsoft with all it's being - and currently it's eating straight up fail cake.

<comment><USER8> >While I agree that it may very much amount is 'miscommunication'. You would think - that a company which proud itself on having the 'best, brightest and smartest' would do its own due diligence before openly starting a significant legal battle with Microsoft - a company renown for suing everyone in existence - and complaining to the government that it's basically being anti- competitive.

The legal battle is not with Microsoft. It is with "The United States".

<comment><USER7> Sure officially. Unofficially - it's with Microsoft.

</comment></comment></comment></comment><comment><USER9> Microsoft calling _anyone_ out on security issues is laughter inducing to the extreme. For those of you that weren't paying attention in the Windows XP/IE 6 heyday, anyone could find remote exploits that bothered to look for more than 5 minutes.

<comment><USER8> Security is different from certification, which is the article is about.</comment></comment>


Belize's thriving Afro-Caribbean community - <AUTHOR> http://www.bbc.com/travel/story/20181118-belizes-thriving-afro-caribbean-community <comment><USER2> When i lived on the north coast of Honduras i got to know some Garífuna people. It is a challenging language to learn to speak and to read. Courses are limited. I remember a religious group putting a lot of effort into translation into the Garífuna language - good for them to keep it alive.

<comment><USER3> Here's a large section of the Bible in Garifuna:

[https://www.scriptureearth.org/data/cab/PDF/00-WNTcab- web.pd...](https://www.scriptureearth.org/data/cab/PDF/00-WNTcab-web.pdf) [pdf, large file]

</comment></comment><comment><USER4> My youngest son is half-Garifuna. Hard to believe this article goes so in- depth and fails to really touch a critical part of the Garifuna culture: punta dancing</comment>