jadeklerk

+1 to this. You have to realize that over a billion users use gmail. You can't possibly imagine that prioritizing .0000000001% of users that know about something like filtering on custom headers is remotely good decision-making against all the other work being done that helps the majority of users.

I'm a fan and daily user of golang, but I thought his understanding seemed very solid and his reasoning concise.

A decade of growth....?? Where were you in 2008?

Import paths are nicer with a flat structure. E.g. the difference between import "github.com/whomever/orm" and import "github.com/whomever/orm/fiz/bang/whiz/resolvers".

Because you didn't want to set an env var?

You mentioned problems with gRPC, but I think every one of your problems is with protobuf. Is that correct?

Also, regarding point 3, I'm confused with two things:

- You want "free form" data, but you're talking about protos in the context of Go. How would you define this "free form" data in Go?

- You explain that "free form structured data is important for systems that accept foreign data ... where the schema isnt known". Why are you using protobufs for this usecase? Protobufs are specifically meant to make the schema known, and be enforced by serialization.

Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides

Fantastic to see open source alternatives. At a previous job, I was repeatedly frustrated using AWS lambda's extremely closed-source environment.

I've used both, and ECS was definitely the bigger pain. I deployed to and managed an ECS cluster for 8 months; the lack of replicability locally (which sucks for testing and CI/CD), the opaque and limited management options, and the lack of community interest / discussion all turned us off.

I think hosted kubernetes was easily the better option for us.

The topic of this article is Google App Engine (GAE), which is a PaaS. Comparing GAE to AWS step functions (which is some wrapping around AWS Lambda) is moot since they are different categories of products solving different problems.

For PaaS products, GAE is comparable to AWS Beanstalk (or Heroku, or CloudFoundry, etc).

For "serverless" products * , AWS Lambda/Step Functions are comparable to Google Cloud Functions.

  * Serverless in the product sense rather than the literal sense.

Sorry, what is 'hiring junior devs from the ranks of biology grads' intended to help with?

Panasonic Automotive | Senior Software Engineer | Denver | Full-Time | On-site

Panasonic is building a connected vehicle system for car-to-car, car-to-operator, operator-to-car, and accident/weather/etc detection. We're still a fairly small team within the larger Panasonic, but we're growing and are looking for someone senior to take the frontend.

The frontend app is Go in the back and react/redux in the front using google maps to do some of the heavy lifting, and several custom layers on top of gmaps. The app (back and front) has to stream data at super high rates over websocket (alongside traditional REST) (cars send a lot of data!) and have it available in near real-time, so there are many interesting high-data-flow visualization, correlation, and aggregation problems that ends up happening in or near the frontend. The future probably holds a fair amount of svg drawing work, which should be pretty cool (graphs, animations, that sort of thing).

Auxilliary technologies include Karma/Jasmine/Enzyme for testing (which is also quite interesting on this project, given the high data flow and reliance on drawing tools), webpack and babel for build, concourse.ci for CI and automated deploy, AWS as our IaaS.

If you're interested in talking to an engineer about what we do, hit me up at [email protected].

If you're interested in applying or talking to a recruiter about the job, hit up Jessie at [email protected].