HN user
+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.I found the original golang blog to be a fantastic resource on the topic: https://blog.golang.org/profiling-go-programs
Sorry, what is 'hiring junior devs from the ranks of biology grads' intended to help with?
There is a PR to add it back in: https://github.com/easylist/easylist/pull/500
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 jadekler@gmail.com.
If you're interested in applying or talking to a recruiter about the job, hit up Jessie at jesseyjean@gmail.com.
runC is the tool that fits the OCI spec. It spawns containers on your host OS. runV is another tool that fits the OCI spec - it spawns container on hypervisors (type 2 AND 1).
runC is the most commonly used - it is used by containerd (which is docker's wrapper), garden (which is cloudfoundry's wrapper), and CRI-O (which is kubernete's wrapper).
rkt is another container company, whose wrapper is (afaik) just called rkt, and whose runC equivalent is systemd-nspawn, which does not meet OCI spec last time I checked.
It's fly login -t <my target>
You can save targets.
Also, if you want logs to appear somewhere you can pretty easily set up a after-fail job to ftp em somewhere.
100+ jobs in one pipeline?
However it performs like a dud. No scheduling to speak of, just runs everything as soon as it can. We've run into nodes dying under load (-not- underprovisioned, could run all these jobs manually at once on these monsters). We've run into problems with volume reaping, fork bombs, ui freezes, everything under the sun.
I've used concourse as a consumer for 3 years and I've very, very rarely seen any of the problems you're describing, even on the older versions and certainly not in the last year or so.
no scheduling to speak of
Concourse has a massive scheduling system built into it.. https://github.com/concourse/atc
Furthermore, you can configure jobs to run in serial (default is parallel).
ui freezes
Put your `web` binary on a decently-sized VM and your problem should disappear. Also, don't have your workers on the same VM as your `web`.
The arcane incantation to login? Seriously? It's literally fly login. You're being ridiculous.
Concourse looks good on the surface but it's really not that great.
I've used teamcity, jenkins, gocd, circleci, concourse, and travisci. For multi-project systems, concourse is king. (I like travisci for by-itself, non-system projects)
The UI is clunky.
What? You just said the UI looks good... It's simple and clean; everything is async javascript (no page loads).
The abstraction layer is too low and leads to a lot of repeated YAML. Which leads to YAML programming.
Which is an intentional choice. If you don't like YAML, use one of the MANY yaml abstraction layers of your choice...
There are simple scenarios like deployment rollbacks who are hard to do.
First of all, a CI system shouldn't be your answer to rollbacks. Your deployment system should handle that. Secondly, assuming your deployment system can do rollbacks, concourse has on-fail jobs that can trigger rollbacks just fine.
For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue. It's generally slow and we had 100% CPU usage when the worker was doing almost nothing.
garden is used because cloudfoundry builds it. It is not slow... it is a light layer on top of runc (as opposed to docker which is a rather heavy layer on top of runc). You should pretty much never have to care about it, and in 3 years of using concourse I haven't had to - and we have some pretty gnarly large pipelines.
Also I call rubbish on your 100% CPU. I have two workers t2.xlarge workers running 22 and 30 containers (like, right NOW) and neither is above 10% CPU (which, actually, I should make those a lot smaller). Don't run workers on a potato and you'll be fine.
Gitlab CI is much better. Or even Jenkins is better.
Ohhh you're trolling.
Of course, and you can - you can manually hit the + button to retrigger a build, and if you want specific inputs you can select the exact one you want in the resources tab (which is slightly less common, since you probably haven't been committing since your build broke, but it's totally doable).
- Just trying to find logs is a pain, and getting the UI to show a full log output is basically impossible
What? It's just STDOUT.. Are your logs going to a file or something?
- There was no way of retriggering a CI run on a single PR (without force pushing to the branch, which removes Github reviews)
A CI that runs one job (test) for lots of branches is differnet than a multi-pipeline CI that runs lots of jobs for a single branch (which is what concourse aims to be).
UI is pretty but often breaks. Is unusable when you have a pipeline with dozens of concurrent jobs.
Are you running it on a potato? :) We have massive builds that have never had problems in the UI.
Did your evaluation happen a long time ago? Or, another question... did you run the binaries and appropriately screen them? I had the same problem until I realized I sucked at making a binary live a long time, and my eyes were opened to screen :)
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 jadekler@gmail.com.
If you're interested in applying or talking to a recruiter about the job, hit up Jessie at jesseyjean@gmail.com.