Ask HN: Best Git workflow for small teams - <AUTHOR> I have been building up a small team of programmers that are coming from CVS.  I am looking for some ideas on ideal workflows.<p>What do you currently use for teams of 5-10 people? <comment><USER2> We've been using the Github flow (or some variation of it) in teams of 2-10 people for a few years now. We work on feature branches, merge after code review using the github web UI. Here's a few things that help us:

\- Make a rule that anything that's in master can be deployed by anyone at any time. This will enforce discipline for code review, but also for introducing changes that f.e. require migrations. You'll use feature flags more, split db schema changes into several deployments, make code work with both schema version, etc. All good practices that you'll need anyway when you reach larger scale and run into issues with different versions of code running concurrently during deployments.

\- If you're using Github, check out the recently added options for controlling merging. Enable branch protection for master, so that only pull request that are green on CI and have been reviewed can be merged. Enable different dropdown options for the merge button (eg rebase and merge), these are useful for small changes.

\- It takes some time to get used to those constraints. Make sure that everyone is on board, and do a regular review of the workflow just as you would review your code. It takes some time to get used to, but I think it's worth it in the long run.

<comment><USER3> +1 for master always deployable. In teams I've led, I've made it a rule to never commit to master, and sparingly commit to develop.

Features are developed in branches and merged into develop. Once we're happy with things, we tag & merge into master. (Junior dev so my approach may not be the best.)

<comment><USER4> To prevent confusion I think it is better to merge feature branches into master and not have a development branch. Master should always be deployable but if you're not practising continuous deployment you can merge into the production branch to do so. This is further detailed in GitLab Flow [http://doc.gitlab.com/ee/workflow/gitlab_flow.html](http://doc.gitlab.com/ee/workflow/gitlab_flow.html)

</comment></comment></comment><comment><USER5> Continuous integration AKA trunk based development is the workflow you want to have. Ensure you meet the prerequisites first though (reliable automated tests, solid code reviews, feature flags, etc).

To be precise, small feature branches are perfectly fine. They are meant to be reviewed and squashed into master ("trunk") in a few hours to a few days maximum.

Squashing instead of merging has a big advantage of being able to quickly revert the changes if things go awry despite all best practices in place.

PS Avoid gitflow and similar workflows as they introduce leaps and thus risk. As everything in software engineering, you want your workflow to be as incremental as possible.

<comment><USER6> > Squashing instead of merging has a big advantage of being able to quickly > revert the changes if things go awry despite all best practices in place.

Merge with --no-ff. You can revert easily, but you don't throw away the feature branch history.

<comment><USER7> > but you don't throw away the feature branch history

Once a feature is merged, how is the history of a feature branch helpful?

Since I do not see/understand the benefits of retaining feature branch history, my preference is to squash commit and merge. Perhaps, this is a result of my habits that I carry from the ClearCase days, but would love to hear the downsides of this approach.

<comment><USER6> Well given that we're talking specifically about reverting the merge when something goes awry, firstly you want that history preserved so that you can re-start work on it, potentially without pulling in all of the changes in one go; and secondly so that you can determine the precise point at which the problem happened.

Consider the difference between:

* Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through.

…vs:

* Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result.

Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why _wouldn 't_ you pick the more flexible approach?

</comment></comment></comment></comment><comment><USER8> I had a lot of success with a master branch, all features built in feature branches.

Feature branches were rebased then merged with a --no-ff. This creates a merge commit on master which includes the ticket number and short description.

The rebase is done by the feature branch developer who is usually best qualified to do so.

The advantage is that changes are isolated from each other, so nothing is spread before it's reviewed. The rebase makes the history easy to follow because it becomes linear and you can always easily see exactly what was changed in the branch. You still retain the full history of the feature branches.

Disadvantages: it doesn't scale to a massive team because you need to linearize the merges back to master. So it works for upto around 20 people.

I'd recommend against Git Flow because their method of merging makes it very unclear exactly what was changed in a branch. I actually prefer no feature branches to using Git Flow.

<comment><USER9> I would strongly recommend avoiding a rebase-based strategy. When developers at my company run into git issues, they are almost always the result of a bad or confusing rebase.

My team's process is simple and easy for anyone to follow: all feature work is done on feature branches. Branches should be kept small and atomic. When they've passed code review, squash and merge into Master.

If you need to pull changes from master, always merge into your feature branch, never rebase.

<comment> joatmon-snoo I would disagree with the strongly recommend here, because rebasing makes it _so_ much easier to track down bugs and isolate breaking changes.

Of course, this does require someone to be more proficient with Git beyond the simple add, commit, fetch, push model, which has its own drawbacks.

Also, at least in Git, squash is just one use case of interactive rebase, so I'm not quite sure what you're arguing against...

<comment><USER10> Can you go more in depth with this process on how rebasing things makes it easier to track down bugs / breaking changes? Usually you can track down which feature branch is the one that cause a regression in your code base, and you can also look at specific commits to find out where problems happen. I can't tell how a rebasing flow would make this any easier?

</comment></comment></comment></comment><comment><USER11> I generally like GitHub Flow ([https://guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)) because it gives you isolation for individuals, but with only one ceremonial branch (ie. master). It might not be sufficient if you have formal release and QA cycles where you need to batch a bunch of changes to push to a staging environment, but all else being equal I prefer to optimize for branching, merging and deploying to production quickly. And with current cloud and/or containerized setups, it becomes possible to have on-demand staging environments (or even using ngrok with dev workstations!), but YMMV.

The main cherry I like to put on top is to always rebase before merging then merge with --no-ff (which is the default with GitHub PR merge button). This gives linear history for purposes of git bisect but preserves the topic branch structure so you don't have to read the tea leaves of the individual commits to piece together the overall development timeline. That one little piece goes a long way to addressing the concern that "rebasing destroys history" (which I don't agree with anyway, but that's the topic of another post).

This might not be worth it for certain types of contributors who are not programmers by trade, but for career programmers I believe mastering git and rebase in all its flavors (-i, --onto, pull --rebase, etc) pays big dividends that your team will appreciate more as the years go by. For git beginners maybe you start without rebasing, then learn the ins and outs of rebasing with local branches only before pushing, before finally going the whole hog and rebasing topic branches with force push before merging.

One last idea I like is Zach Holman's recommendation of deploying topic branches directly and then merging if there are no issues ([https://zachholman.com/posts/deploying- software](https://zachholman.com/posts/deploying-software)) in order to have easier rollbacks. Then you have 100% guarantee master is always stable.

</comment><comment><USER12> Paul Hammant has some interesting blogs about the topic and he has been talking and promoting Trunk Based Development for a while. We use a variation of it at work, though we have several teams of ~5 working on the same repository.

[http://paulhammant.com/2013/04/05/what-is-trunk-based- develo...](http://paulhammant.com/2013/04/05/what-is-trunk-based-development/)

[http://paulhammant.com/2014/09/29/shades-of-trunk-based- deve...](http://paulhammant.com/2014/09/29/shades-of-trunk-based-development/)

[http://paulhammant.com/2013/12/04/what_is_your_branching_mod...](http://paulhammant.com/2013/12/04/what_is_your_branching_model/)

</comment><comment><USER13> At my previous team (5-6 people worked simultaneously) we used CI & CD and we relied on feature flags, so we could merge our branches more often and make smaller pull requests on Github. Each part of the feature had its own branch with a clear goal and tests written for it (we never pushed to master, every time you start working on something, you create a branch prefixed with your initials, make a PR, merge after review and then do it all over again). Of course, master branch was always deployable.

Right now, I work on a smaller project, we use similar workflow - we haven't implemented feature flags yet, but I suppose we will in the future (the project hasn't been released yet actually). I personally don't like developing an entire feature in a separate branch and then merging when it's all over, because code review becomes tedious (and ineffective) and the risk of merge conflicts increases. I would suggest you invest time in writing tests, so you can become better at it (if you aren't already) and it becomes a natural part of your development. Same goes for feature flags :) I was a junior when I started working like this (I still am, kind of) and it meant the world for me :)

</comment><comment><USER6> Your master branch really should be your _master_ branch. A branch that represents the most up to date working version you have, that everybody works in relation to.

Only working, tested code should make it into master. Code reviews and automated tests are great tools for this, but ultimately, it's up to the individual developers to not be sloppy.

Avoid long-lived branches and big merges. If you've got big features that take a while to complete, break them into smaller things you can deploy sooner or use feature toggles.

Don't leave it too long between deployments. Small, frequent updates are far easier to manage and far less risky. A dozen deployments a day are better than a dozen a year.

Everybody should stay up to date with master. Rebase on top of master before merging instead of having awkward merge commits that only obfuscate history.

If you have people working on features that take multiple commits to implement, use feature branches. These should be rebased onto master and cleaned up before merging into master.

If you combine all of the above, you're heading down a path similar to GitLab Flow or GitHub Flow, so strongly consider using one of those instead of coming up with your own from scratch. Don't use Git Flow. It overcomplicates things and offers zero benefits over the alternatives. As far as I can see, it's only popular because a lot of inexperienced Git users were feeling like they were adrift without a workflow, and a blog post with a snappy title came along at just the right time to catch their attention.

If your team don't have good VCS habits, you need to do something about this. Small, frequent commits that do one thing and one thing only, good log messages, push and pull frequently, etc. If you can't describe the change briefly, you are doing too much in one commit. There's lots of best practices articles for Git that have been written – read them. Also read Pro Git, which is free on the Git website.

</comment><comment><USER14> We work as small team, 3-5 people max.

We just keep it simple like:

\- No one pushes to master.

\- For every feature (or update on a feature), create new branch.

\- Send pull request for reviewing (one of us is the reviewer).

\- Merge pull request into master.

\---

You could try git workflow, but it's just too complicated for small team (and for large teams too?).

<comment><USER15> > You could try git workflow, but it's just too complicated for small team > (and for large teams too?).

git flow seems overkill, unless you regularly need to patch older versions. For software where you control which version(s) are deployed, you can usually get away with (much) simpler workflows.

</comment></comment><comment><USER16> [https://docs.gitlab.com/ee/workflow/gitlab_flow.html](https://docs.gitlab.com/ee/workflow/gitlab_flow.html)

<comment><USER17> It bothers me that all the arrows are backwards. Commits point at their parents not their children.

<comment><USER18> That's an implementation detail. Most people think of git history as more of a stream, forking and merging _while moving forward_. In this context, the arrows pointing in the direction of chronology is perfectly sensible.

</comment></comment></comment><comment><USER19> This is what's working for us:

      - Branch off master to make your fix/feature. Prefix branch name with "fix/" or "feature/" accordingly. We occasionally use a "script/" or "migration/" prefix too.
      - Do work. Use "git app -p" so commits are fairly small.
      - Make GH PR into master, get code reviewed. CI test are run automatically.
      - Deploy branch to staging environment and test.
      - Merge with GH, deploy to production.

Notes:

      - master is always in sync with production, and so is always deployable.
      - never commit to master.
      - we don't use a develop branch.

<comment><USER20> What is this 'git app' you speak of?

<comment><USER21> I think the GP meant `git add -p`

</comment></comment></comment><comment><USER22> No branching at all + integrated CI/CD.

<comment><USER15> To elaborate a bit: That's usually called "Trunk based development", and it works pretty well in small teams (at least that's where I have experience with it), and if you have automated test, and infrastructure that runs them automatically.

See for example [https://www.thoughtworks.com/de/insights/blog/enabling- trunk...](https://www.thoughtworks.com/de/insights/blog/enabling-trunk-based- development-deployment-pipelines) for a much more in-depth discussion.

<comment><USER23> you usually also need feature flags.

</comment></comment></comment><comment><USER24> Start out by ensuring your CVS refugees understand Git basics. We've got a free talk on this (outline: [http://www.verticalsysadmin.com/git/git- intro.html](http://www.verticalsysadmin.com/git/git-intro.html) video: [https://www.youtube.com/watch?v=j6Se3jH60dA](https://www.youtube.com/watch?v=j6Se3jH60dA)) and provide professional training.

Also, the Pro Git book: [https://git-scm.com/book/en/v2](https://git- scm.com/book/en/v2)

</comment><comment><USER25> For my senior design team of 5 developers using Scrum and JIRA:

master ("production") branch:

\- this is deployed

\- nobody (not even GitHub Org administrators) can push; master is only changed via approved PR

dev branch:

\- the base "working" branch during each 3-week sprint

\- pushing is allowed iff the change is trivial or already has team consensus (e.g. changing linter rules)

\- this is where we demo to our Product Owner

"story" branches:

\- branched from dev

\- named along the the lines of "alternate-checkout-TFF-75-story"

\- base branch for any work that needs to be done for a user story

"task" branches:

\- branched from the corresponding story branch

\- (usually) named along the lines of "item-unavailable-TFF-92"

For all branches:

\- CI must pass

\- all PRs require >= 2 approvals, unless it is a trivial change then only 1

\- require PRs when merging upstream (i.e. task -> story -> dev -> master)

\- merge freely when going downstream (i.e. master -> dev -> story -> task)

\- do not merge from story-A to story-B nor task-A to task-B

\- squash commits when going task -> story and story -> dev

\- do not squash when going dev -> master

Having stroy & task branches help keep the changes for each new feature in easily digestible chunks. The story branch is particularly helpful when two tasks need the same code, but the story, task-A, nor task-B branches are ready to go to dev. So we merge the shared code to the story branch, then the other task branch can merge down the required code from the story branch.

Currently, there is some contention over our verbose branch naming scheme. Previously, when 3/5 of the team was working on a different project, the branch naming scheme was "name-of-story-TSS-XX-story" for stories and "name- of-story-TSS-XX/name-of-task-TSS-XX".

</comment><comment><USER26> My team comprises 4-5 Software Engineers and 1 Developer-in-Test. We develop three (related) websites + a bunch of back-end services.

There is only one long-lived branch in each of our repositories: master. All other branches in our GitHub repos exist only to perform a Pull Request/code review.

PRs must not be merged in to master until all unit tests are passing (the unit test suite is run for each new commit to a PR branch) and the change has been reviewed by another member of the team. In almost all circumstances the person who raised the PR is responsible for merging it. Once the PR has been merged in to master the GitHub branch is deleted.

Our CI server creates a new build for _every_ merge commit to master, automatically pushes this build to our integration environment, and then runs a series out automated integration tests on the system. If the build or automated tests fail then only PRs that fix the build are allowed to be merged in unless they are trivial.

Once our DiT is ready to perform a test, she promotes a build to the test environment and does her thing. Tickets that have been tested are then reviewed by a product owner and if they are happy the build gets promoted to the Live environment.

<comment><USER27> +1 on only having master as a long-lived branch.

where we started 5 years ago at work we had various different kinds of 'develop' branches and process around merging between two different eternal branches. as we've scaled from a startup to a 200+ person company we've mostly simplified our github workflow and gone to single-eternal-master.

</comment></comment><comment><USER28> I've used both gitflow and the feature branch workflow which is explained here: [https://www.atlassian.com/git/tutorials/comparing- workflows/...](https://www.atlassian.com/git/tutorials/comparing- workflows/feature-branch-workflow)

both work well I think for small teams just depends on how well you want to organize things.

</comment><comment><USER29> For my team of about 10 people per app -

      1. Never commit to master
      2. master is always deployable and gets built and deployed (CI/CD) automatically so its sacred
      3. Everyone codes in their own feature branch (username/feature)
      4. These are merged into a topic branch (origin/topic_feature) if there are more than 1 person working on a feature together
      5. That topic branch is treated as a master - no force pushes, everyone rebases and merges from their personal branches
      6. Topic branches are rebased with master periodically/sensibly and often times get built and deployed as beta for feature testing
      7. Topic branches are merged into master

There is a code review process at each step. Developers create merge requests for their personal feature branches into the topic branch and then merge requests for the topic branch into master for periodic code reviews.

We don't force push and maintain history. Proper commit message formats are enforced to ensure that everything is standard and readable.

</comment><comment><USER30> Git can adapt to any workflow. Why not start with whatever they are used to from CVS and then tailor it to your needs over time?

</comment><comment><USER31> We use what is basically the "GitHub" flow... forks and PRs on an instance of GitHub enterprise.

This is nice because in addition to the isolation it provides when everyone is working on their own fork it's easy to code review changes BEFORE they land in the "blessed" repository.

It's also nice because junior developers aren't pushing directly to the blessed repo either.

This model is really nice for maintenance and small feature development.

For major new development (new version, major feature that multiple people will work on) we tend to revert back to the behavior of committing directly to the blessed repo.

</comment><comment><USER32> For 5-10 people it depends on what everyone is doing. I typically push some code out in the wild (master) for stuff that wont change and do releases or branching for incremental updates and patches. Git Branching + Git Releases should help you out mostly also bonus if you are using github throw in some good 'ol kanaban action using projects.

</comment><comment><USER33> GitHub flow is the ideal way to go IMO. It is simple, easy to understand, and widely used.

In the end, however, it is going to come down to the specifics of your app and environment. What sort of CI do you have set up? Do you have anything that controls when or how you are able to release code? These types of things are what generally push teams to other models.

</comment><comment><USER34> Like others are saying here, the branch named "master" is always deployable.

Feature branches are named after a ticket. Pull requests are across branches in the same repo, not across repos. (It's marginally easier to collaborate on feature branches if they're all in the same repo.)

We don't (yet) do full continuous deployment, so many feature branches get grouped together before a release. Our strategy is to test* each feature independently and then merge all the tickets together to a branch named "staging". The staging branch then gets run against some extra regression/acceptance tests and whatever manual tests we may want. If they pass we merge to master, tag, and deploy.

Seems fine so far. Specifics about our tests and deployment process drive the Git workflow more than anything else.

*Run the test suite, test manually, whatever.

</comment><comment><USER35> Quarterly website release cycle with 3-5 developers. usually one liner bug fixes are the only thing pushed to master without a branch as in master -> master. Everything else is a branch / independent feature each developer is working on and we pull them all into a staging copy of master to pretest Which makes it easy to just delete the staging if we want to repull a feature or two and scrap what other features we pulled, once staging is well tested we merge with master on bitbucket as the new release.

The biggest change for us when we starte was do not push features for the 3 month release into master so at any moment or bug fix master is always ready to go live anywhere without some dumb new feature we don't want. Keep master clean dammit :)

</comment><comment><USER36> I think that a lot of people here make assumptions about the project that are not necessarily true. For example "everyone can deploy from master at anytime" is a great rule for a website that can actually be deployed by one click of a button, but a very bad practice for an iOS app, each new version of which can, theoretically, spend up to two weeks in review.

Also, what's your QA process and what is the usual quality of your builds? How R&D heavy are your new features, and how long do they typically take to develop? Are your programmers own different parts of the codebase, or is every one of them able to work on anything?

Without all this details it's impossible to know which workflow is ideal for your particular team.

<comment><USER6> > For example "everyone can deploy from master at anytime" is a great rule for > a website that can actually be deployed by one click of a button, but a very > bad practice for an iOS app, each new version of which can, theoretically, > spend up to two weeks in review.

What is meant by that is that what ends up in master should always be working, complete, tested code, not half-finished stuff. It doesn't mean that you need to deploy each and every commit to the public. It means that master is the canonical source of truth for the current state, disregarding tasks that are not yet complete. It means that there's a solid base for people to branch from without worrying about things that are temporarily broken.

What I normally do with iOS teams is have the CI tool produce a new internal build for every commit to master. That way everybody, including testers, have the most up to date version of the application readily available. That starts to fall apart if developers treat master as just the place to put work-in- progress stuff. It doesn't mean that we're submitting to Apple several times a day, it just means that we're sure what's in master is " _done_ done".

<comment><USER36> > What I normally do with iOS teams is have the CI tool produce a new internal > build for every commit to master. That way everybody, including testers, > have the most up to date version of the application readily available. That > starts to fall apart if developers treat master as just the place to put > work-in-progress stuff. It doesn't mean that we're submitting to Apple > several times a day, it just means that we're sure what's in master is "done > done".

I did that, but it turned out of little relevance to our QA process: new builds were happening once an hour, while QA wanted to get a version that they can run at least a full regression on, and it takes much more than that. So they ended up not using this CI builds at all, instead relying on a "release" branch version which they would get once every few days.

</comment></comment></comment><comment><USER37> We use develop branch as a pre-master. All feature branches get pushed to origin and pull requests created to merge feature branches to develop from there. Once a sprint is finished we merge to master and deploy to staging. Staging gets promoted to production using pipelines. As we are in early stages the develop branch is good but I can see us dropping it and using only master once we start doing daily releases.

</comment><comment><USER38> From my experience working in a small team (3 devs + 1 designer). Here are some tips:

1- every dev works on a topic branch

2- always rebase before committing

3- have a jenkins running somewhere\

4- everything that gets merged into master gets automatically built and tested

5- everything that gets merged into -RELEASE gets automatically built, tested, packaged and deployed

6- Use issues from gitlab/github

7- Did I mention to always rebase before committing?

This isn't much and isn't exaustive, but it's a start.

<comment><USER39> One note: do not rebase published branches. Do so against local branches only.

</comment></comment><comment><USER40> You need to figure out your release cycle first, before creating/picking a workflow.

Will you only have one version of the app released at a time, (websites) or multiple versions (native, mobile apps). Will you have just one team or multiple teams working on the same app at the same time?

Answer these questions first, then and only then should you seek for a workflow.

</comment><comment><USER41> I'm going to say something not popular but I miss SVN when working with teams. Git is great for distributed open source work but it sucks at being centralized/mono repo . SVN made it easy for instance to lock some parts of a mono repo or to even manage who can access to what. I don't get tall that for free with Git.

</comment><comment><USER42> Master, dev, feature and release. Mostly always in fact.

An admin merges a release back into Master and back through to dev after a milestone build, demo or production release.

Keep the same Workflow with other teams in your organisation if it exists - unless it is fatally flawed - so that team members moving around have the same experience. Consistency and all that

</comment><comment><USER43> I am currently solving the same problem and what helped me a lot was the Git manpage about workflows:

[https://www.kernel.org/pub/software/scm/git/docs/gitworkflow...](https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html)

</comment><comment><USER44> The link is down. Here is the cache version [https://webcache.googleusercontent.com/search?q=cache:Vk2On-...](https://webcache.googleusercontent.com/search?q=cache:Vk2On-9psscJ:https://msdn.microsoft.com/en- us/magazine/mt790182.aspx)

</comment><comment><USER45> Everyone says what Git branch workflow should you use, but honestly, it can be complicated especially for junior developers.

Just commit everything to master and that's all! Sound stupid but worked best for us. I have seen a big software company using this, I learned this from them and never looked back!

<comment><USER46> Just make sure to rebase every time you start work to avoid merge conflicts, but yes, this is the single most effective git workflow for small and probably larger teams too! I'm in a small team where the lead dev comes from a top SV company and he introduced this workflow and it works great.

<comment><USER47> Are you being serious or sarcastic?

<comment><USER48> I'd assume he is serious. It is a lot simpler to avoid merge conflicts that are hard to solve if you always rebase first.

</comment></comment></comment></comment><comment><USER49> If most know CVS already just use it. The burden of switching a tool and learning a new one is not worth it if the old one is good enough. I'd just set up a CC list for patch reviews, put a TODO file in the repo and go on with whatever VCS my team is used to using.

<comment><USER50> CVS is terrible in comparison to modern VCS tools. It's not even atomic. I strongly recommend against using it.

<comment><USER49> It's relatively worse in some areas but terrible is a blatant exaggeration. Ignorant prejudice doesn't apply to technical decisions.

<comment><USER50> I honestly don't believe it is an exaggeration. Take a look at this video for Linus's thoughts [https://www.youtube.com/watch?v=4XpnKHJAok8](https://www.youtube.com/watch?v=4XpnKHJAok8)

</comment></comment></comment></comment><comment><USER30> There is the philosophical discussion, if you should rebase or not. If your team comes from CVS there is probably no bias yet. Pick for yourself if you prefer a clean or an accurate history.

</comment><comment><USER51> I Have 3 main branches, alpha, beta and master.

Next to feature branches.

Jenkins for updating

Beta = production databases, but automatically copied, to avoid production errors ( lots of parameters to customize stuff)

No develop in master, just merging

</comment><comment><USER52> Any advice for a workflow using Gitlab?

<comment><USER3> Take advantage of GitLab CI.

<comment><USER24> [https://about.gitlab.com/gitlab-ci/](https://about.gitlab.com/gitlab-ci/)

I'm putting together a course on GitLab CI. It's powerful stuff!

<comment><USER52> This looks great! Thank you. :)

Is there a contact address for basic non-technical feedback?

<comment><USER24> I didn't mean to claim credit for GitLab's CI page. I was just posting the URL to be helpful.

You can get in touch with GitLab via [https://about.gitlab.com/contact/](https://about.gitlab.com/contact/)

I _am_ developing a tutorial on GitLab CI which I'll post on Show HN once done and I'll mention it in this thread.</comment></comment></comment></comment></comment>


Detroit's gleaming startup tower - <AUTHOR> http://www.theatlantic.com/technology/archive/2012/09/detroits-gleaming-start-up-tower/262730/

<comment><AUTHOR> I think the author should have visited Detroit four or five years ago to have some perspective. The City has made amazing progress in that time.

Where boarded up buildings once existed there are now clusters downtown with lots of activity. The Madison has been nothing short of a miracle. What he hasn't reported is that it is becoming a magnet with companies from all over the city moving nearby.

Sure you can walk a few short blocks and it's a desolate wasteland. Detroit didn't go downhill in a couple of years and it is going to take time to recover but you don't have to look too far to see progress.

Five short years ago no one wanted to live downtown. Now there's a boom in new apartments downtown and despite the construction there's still a 97% occupancy rate.

[http://www.freep.com/article/20120926/BUSINESS06/309260037/T...](http://www.freep.com/article/20120926/BUSINESS06/309260037/Tight- market-for-downtown-Detroit-apartment-rentals)</comment>


Ford Releases An SDK For Their Cars - <AUTHOR> http://bits.blogs.nytimes.com/2013/01/08/c-e-s-2013-have-you-programmed-a-ford-lately/ <comment><USER3> This sounded awesome right up to the point that they said that this was a hotly pursued space due to advertising potential to a captive audience. If I am in my own car and my music is interrupted with an ad every time I drive by a McDonalds - I would find that extremely annoying.

On the other hand, if you could lease a car at a subsidized price in exchange for ads, that might be an attractive offer to some.

<comment><USER4> It ought to be flatly illegal to visually advertise through an in-car app. An ad is designed to engage attention; visually engaging a driver is the last thing we want on the road. It's beyond stupid.

YOU ARE PASSING A GAS STATION. PLEASE STOP AND BUY IT.

YOU ARE PASSING A SANDWICH SHOP. PLEASE SWERVE LEFT AND BUY SANDWICH.

5 POINTS IF YOU CHANGE TO THE FAR RIGHT LANE!

<comment><USER5> Hm. I wonder if anyone has ever attempted to ban billboards under the guise of being worried about distracted driving.

<comment><USER6> This is actually already the case in a few European countries I am aware of. Not all streets, but next to the highways there can't be any visible billboards.

<comment><USER7> Like Germany. The one country where there is no general speed limit on highways.

Actually, everytime I visit countries with billboards on highway, it seems really bizarre and stupid to place ads next to highways.

</comment></comment></comment></comment></comment><comment><USER8> Since we are on the topic: I wish Tesla would finally live up to their obligations and release the GPLed parts of their product (that includes, at a minimum, the Linux kernel with all modifications).

<comment><USER9> GPL compliance (sigh) and a new SDK for a vehicle aren't really the same topic. They just happen to have cars in common. If I left a comment about the camshaft on my Jeep, that wouldn't be on topic, even though it's about cars.

That aside, what do you hope to gain from their GPL compliance? Pop open the GPL compliance kit from, say, a Netgear router and you get a kernel, a few drivers, and the toolchain used to build it. And BusyBox. How useful will the drivers for things in a Tesla be to you? Do you _own_ a Tesla, or is it just curiosity?

If it's curiosity, well, I wish we weren't enforcing that with the GPL.

<comment><USER10> > If it's curiosity, well, I wish we weren't enforcing that with the GPL.

It's simple, either you comply with the GPL or you don't distribute GPL-based code. As an author of GPL licensed software, I think it's pretty damned arrogant for someone like you to imply curiosity isn't a good enough reason to get back modifications in accordance with the chosen license. Who are you to judge? And anyway, what reason could possibly be more worthy than curiosity?

It's the authors' choice, not the peanut gallery's; and if they hadn't intended for _all_ distributed modifications to be made available under the GPL, they would have chosen BSD or another license instead. And if you don't like that, too bad.

<comment><USER11> Because "for curiosity" isn't a term stated in any GPL license. You can be offended as much as you want for them not releasing it but unless you own a Tesla they don't have to share their modifications with you. If you are unhappy with that, I suggest sharing your work under a different license.

<comment><USER10> I'm perfectly fine with that, but you seem confused about the argument here. GPL code distributors don't have the right to say curiosity, or any other reason, is invalid cause to enforce the GPL.

And while I do not have standing to request GPL licensed code from Tesla, they have a legal obligation to either distribute that code directly, or a provide a _transferable_ offer to distribute that code, to their customers. Code properly distributed as such inevitably would make it back out into the wider open source community; this is the design of the GPL. If Tesla currently does not meet this obligation under the GPL, that is a problem.

<comment><USER11> Yes, they are legally obligated to share their modifications with their customers. No arguments here.

> Code properly distributed as such inevitably would make it back out into the > wider open source community; this is the design of the GPL

The design of the GPL is to protect the users rights to use, access and modify the software in perpetuity. There is no provision in the license that modifiers have to share modified works with the author specifically - <USER2> just have to make it accessible to the people they are distributing it to.

Being the author of a GPL work and wanting access to those changes because you are merely curious or want those changes to be merged into the original work, the unfortunate reality is that the GPL will do squat for you in that regard.

<comment><USER12> > Yes, they are legally obligated to share their modifications with their > customers. No arguments here.

Nope, if you distribute something with GPL code, you must make the source available to _anyone_ that requests it. Not only to your customers. And you can't put any kind of filter on reasons for the request.

One can only charge a "reasonable" amount for the work of making it available (CD, hosting, etc).

The only corner case I see is if they claim that they are selling a device (like the whole car) as a single package and there is only a single package of code along with it.

<comment><USER13> > if you distribute something with GPL code, you must make the source > available to anyone that requests it. Not only to your customers. And you > can't put any kind of filter on reasons for the request.

That's patently false for both the GPLv2 and GPLv3. For v2, see section 3. Only _one_ of the three compliance options requires universal fulfillment of requests for source.

GPLv3 has no similar requirement. The closest analogue to v2's section 3(b) has its scope explicitly limited to "anyone who possesses the object code."

<comment><USER12> GPLv2 makes no such distinction or limitation in section 3.

I states that distribution of binaries must include either: a) Complete corresponding machine-readable source code; or b) Written offer to give any third party a complete machine-readable copy of the corresponding source code;

Item c) applies only to non-commercial cases, which is not the case here.

So if they are not doing a), they need to do b). And written does not imply regular mail (which you mentioned in your other reply), it can be anything on their web page or an e-mail.

If every distributed copy includes full source, then that's covered. Otherwise any request must be fulfilled, as there should be a written notice offering it somewhere. There is no limitation to who can request it.

GPLv3 on the other hand is more "legalese" and harder to read. Section 6 mentions possession of object code only for item b), which is the case for "written notice". So it will only apply if there is such written notice upon distribution.

Item c) is only for non-commercial cases. Items d) and e) require making source electronically available. Item a) says that if it is a physical product it needs to include full sources in some media.

If the distributor doesn't do d) or e), they need to do a) or b).

So, nowhere it is "patently false". Only if using GPLv3, and the binaries being provided along with a physical product, then there is no obligation to provide the code to any request.

The "corner case" I mentioned in my comment is related to item a). The limitation on item b) is actually something I had never noticed before.

But I have no idea which license version Tesla uses, so I don't know if this applies.

PS: Just to clarify one thing: trying to download a file from a URL or via P2P also constitutes a request. It's just on another media.

<comment><USER13> I apologize for my tone, and I think we're in agreement. "Patently false" is a bit extreme, but we seem to agree that it's _possible_ to comply with the GPLv2 without being required to distribute source to anyone that asks. That's section 3(a): include source alongside the object code. If the Tesla cars come with a CD-ROM or a USB stick containing the source, then they're in compliance.

I mention mail order because, oddly, the GPLv2 actually requires that you provide source via postal mail to people if you're opting to comply under 3(b). That subsection states that in response to a written offer, you must provide source "on a medium customarily used for software interchange." That's interpreted by the FSF's GPL FAQ as "if any [third party] would rather get the source on physical media by mail, you are required to provide that" [0].

There's an additional entry in the FAQ [1] specifically covering the definition of third parties for GPLv2: "If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it."

So written-offer-for-source appears to be the exceptional case for GPLv2: you have to provide it on physical media, and to anyone that asks. But if you choose to distribute source alongside the binaries, per section 3(a), then you're free from that obligation.

Given that GPLv3's section 6(b) intentionally constrained this to only people who possess the object code, it feels like the universality of v2's section 3(b) is a bit of a fluke, and not representative of the goals of the GPL. Thus, in responding to your claim that "you must make the source available to anyone that requests it. Not only to your customers." I'd argue that the GPLv2 clearly and explicitly allows you to only make source available to your customers, if you comply with 3(a).

[0]: [https://www.gnu.org/licenses/gpl- faq#DistributeWithSourceOnI...](https://www.gnu.org/licenses/gpl- faq#DistributeWithSourceOnInternet) [1]: [https://www.gnu.org/licenses/gpl- faq#WhatDoesWrittenOfferVal...](https://www.gnu.org/licenses/gpl- faq#WhatDoesWrittenOfferValid)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I was notified today that GM also came out with there API today. Seems a bit odd that they would both release the exact same feature on the same day. I wonder how similar their SDK's will be. [http://media.gm.com/media/us/en/gm/news.detail.html/content/...](http://media.gm.com/media/us/en/gm/news.detail.html/content/Pages/news/us/en/2013/Jan/0108-sdk.html)

<comment><USER15> GM's is cool too because they have an API that allows you to remotely get vehicle data through Onstar. This allows approved apps to get data like fuel level, vehicle alarm alerts, oil life, fuel economy, remote start/stop, location, speed and direction etc. Not sure Ford has anything like that..

</comment></comment><comment><USER16> Nice, I like the forward thinking by ford on this. I only wish next they open up the engine controller, and let the real hackers in!

<comment><USER17> I can't imagine the amount of penetration testing they'd need to do before opening up core components of a car. I would not want to be in charge of that project.

<comment><USER16> Of course they'd never open that up, that was just me dreaming.

<comment><USER18> Isn't that what stage 2 systems for cars already does? Updates the car's internal computer, as well as changing out physical components?

</comment></comment></comment></comment><comment><USER19> "Certain kinds of apps will be barred, like games, elaborate video and anything that would require extensive reading." .. "Ford also announced nine new apps that would be part of the Sync system, including The Wall Street Journal, USA Today..."

Good that these don't require extensive reading

<comment><USER20> I would assume like NPR it would be for controlling audio streams of news?

</comment></comment><comment><USER21> Which means that briefly we'll live in a time where a stack overflow vulnerability will cause your car to break or accelerate at very inappropriate times.

Just google for "researchers car software vulnerability" (without quotes) to see what I'm talking about.

[1] [http://www.computerworld.com/s/article/9229919/Car_hacking_R...](http://www.computerworld.com/s/article/9229919/Car_hacking_Remote_access_and_other_security_issues)

<comment><USER22> It seems like you know that hackable cars are already the norm. Hopefully, with a focus on security and open software development, cars will become more secure.

</comment></comment><comment><USER23> When I bought my 2009 Ford Fusion it was marketed as having "Microsoft Sync", the Sync name has stuck around but I haven't seen any mention of Sync being or derived from Microsoft technology in Ford's marketing in the last couple year (nor in the article). I wonder if that is still the back end of it or if Ford rebuilt Sync from the ground up?

<comment><USER24> [http://en.wikipedia.org/wiki/Ford_Sync#Exclusivity_agreement...](http://en.wikipedia.org/wiki/Ford_Sync#Exclusivity_agreement_with_Microsoft)

</comment></comment><comment><USER25> It is going to make a huge difference whether dealerships work to set up accounts for customers. If ford apps try to survive on ad support it is going to turn into a pile of garbage apps and irritating ads.

</comment><comment><USER26> This video explains better IMO: [http://cnettv.cnet.com/ford-touts-car-app- development/9742-1...](http://cnettv.cnet.com/ford-touts-car-app- development/9742-1_53-50138474.html)

</comment><comment><USER27> Would developers have to buy a Ford Car to test Apps on the device ?

<comment><USER26> The video below mentions that there's a hardware "SYNC in a box" available, and a software emulator in the works.

[http://cnettv.cnet.com/ford-touts-car-app- development/9742-1...](http://cnettv.cnet.com/ford-touts-car-app- development/9742-1_53-50138474.html)

</comment></comment><comment><USER28> Perhaps the article mentioned advertising as an example of a source of apps; perhaps non-advertiser-funded apps are just what the SDK lets anyone build.

</comment><comment><USER29> I am looking forward to playing Angry Birds while driving.

</comment><comment><USER30> This is Kind of Old news SYNC APi has been around a while

<comment><USER31> Yes, it's been around for awhile but the general public hasn't been able to develop apps for it until now.

</comment></comment><comment><USER32> So can I get a free car? Er I mean dev kit? :)</comment>


How to build a drone with ML face recognition for $200 - <AUTHOR> https://www.oreilly.com/ideas/how-to-build-an-autonomous-voice-controlled-face-recognizing-drone-for-200 <comment><USER2> It's so crazy what you can do with affordable tech these days...</comment>


Hillary Clinton says when life's tough, 'keep going'. I'm not so sure - <AUTHOR> https://www.theguardian.com/commentisfree/2019/oct/03/hillary-clinton-life-keep-going <comment><USER2> It's amazing how badly written, meandering, and plain dumb this article is!</comment>


Y combinator application - <AUTHOR>

Does Y combinator accept applications from foreign applicants with an idea <comment><USER2> From the FAQ's (<http://ycombinator.com/faq.html>)

Do we have to start a company in the US for you to invest in us?

Yes, but that's usually not a problem. It's easy for foreign nationals to start US companies (much easier than remaining here physically), and investors and acquirers prefer them.

Do we have to be US citizens?

No, as long as you can get here for at least three months. We've funded many startups founded by non-citizens.

Can you get us visas?

No, sorry, we don't do that. You'll have to figure out visas for yourself. If you know people from previous YC-funded companies who came from outside the US, we suggest you ask them for advice. They understand the options better than we do.

</comment><comment><USER3> Yes but the regular deadline has passed. You can apply late I believe but chances of acceptance are much smaller.

You can alway apply late ad get going on your idea and if you are not accepted apply on time for the next cycle with development of your idea already under way.

</comment><comment><USER4> Yes.

Although, you might need a bit more than an "idea".

<comment><AUTHOR> Actually it's an online web game with multiplayer.a gambling game that we have here in our country and not yet patented

</comment></comment><comment><AUTHOR> Thank you everyone.I appreciate.

</comment><comment><AUTHOR> I mean non US-Citizens</comment>


The Panama Canal Expands - <AUTHOR> http://www.wsj.com/articles/the-panama-canal-expands-1466378348 <comment><USER2> I grew up in the Canal Zone, Panama. I'm in the last generation of true Zonians. When the Panama Canal Treaty started to take effect on October 1, 1979 we all thought it was the beginning of the end of the Panama Canal. When Panama took over the railroad it shortly became defunct so our beliefs weren't entirely without foundation. Military personnel at one point were banned from riding it.

We were angry about losing, from our perspective, our homeland. The Canal Zone police force was disbanded and the PDF (Panama Defense Forces) started patrolling my home town. More and more Panama encroached on what I thought of as my homeland. During Noriega I was convinced Panama would run the canal into the ground.

I went back to Panama 8 years ago and I was pleasantly surprised at the progress the country has made. They've done a great job in running the canal and the country has noticeably benefited from America's withdrawal. My anecdotal experience is that colonialism is bad. Even in benign forms.

I talked with an elderly rabiblanco the last time I was there. He said America leaving made Panama grow up. By all indications they have done so and I'm glad to see it.

<comment><USER3> > They've done a great job in running the canal and the country has noticeably > benefited from America's withdrawal.

Your comment is missing the part where the US military had to go in and take down Noriega. The intervention allowed Guillermo Endara to take power and dissolved the Panamanian Defense Force. Without it, Noriega would certainly still be in power.

Under Torrijos–Carter Treaties the US has a right to intervene militarily to protect the canal. This is probably the biggest thing keeping it from becoming a defacto Russian or Chinese port or drug-runner owned port. Look, I'm all for local politics but your post suggests that everything just went fine with the locals, but in reality the port will always be under US protection in one form or another, which helps keep it thriving.

Remember locals were outraged and protesting in the streets that the US dare attack their beloved bloodthristy dictator. Dies hards still exist:

>Eighteen years after the invasion, Panama's National Assembly unanimously declared 20 December 2007 to be a day of national mourning.

Source: wikipedia.

<comment><USER4> Panamanian here.

> Without it, Noriega would certainly still be in power.

That's debatable. Thankfully the US took care of the situation efficiently, but the general climate was pointing towards a bloody civil war.

> Under Torrijos–Carter Treaties the US has a right to intervene militarily to > protect the canal.

Thankfully in my opinion. Though you could argue that it also makes the Canal a target.

> Remember locals were outraged and protesting in the streets that the US dare > attack their beloved bloodthirsty dictator. Dies hards still exist

This is the only part I truly disagree with. A very small minority actually protested in favor of General Noriega. Pretty much the whole country was on board with removing him from power with the obvious exception of people that followed him to power of their own. Panamanians were not outraged because of the removal of their dictator, but of the methods used to do so that left a bloody trail and piles of dead bodies.

December 20 is a national mourning day in recognition of the people that gave their life during such turmoil, not in the name of a power hungry and greedy Noriega.

EDIT: The US soldiers where super nice to me as a kid. I even got to drive in a tank and they gave me a shitload of soda.

<comment><USER5> Some useful context can be found at [https://en.wikipedia.org/wiki/Panamanian_general_election,_1...](https://en.wikipedia.org/wiki/Panamanian_general_election,_1989).

I've always found it notable that the purpose of the 1989 U.S. invasion of Panama was to remove a dictator and replace him with a democratically elected government.

</comment></comment></comment></comment><comment><USER6> They increased the lock size from 1000 _100_ 42 feet to 1400 _180_ 60 feet.

Until now, the maximum amount of containers on a ship that could fit was 5000. New locks - 14,000 containers.

One thing I hope though is this is future-proof by building for larger than the largest current ships. Is this the case?

<comment><USER7> It helps to use "x" instead of shift-8 (star) as the star is used for italics which is why your comment is a little hard to understand at first.

<comment><USER8> Or spaces "lock size from 1000 * 100 * 42 feet to 1400 * 180 * 60 feet."

</comment></comment></comment><comment><USER9> There was a TV documentary on about the expansion all I remember is the lock doors cost $500 million each!

</comment><comment><USER10> It is really disturbing to look at an article like this and not see a single mention of the HUGE amount of fresh water being dumped into the ocean in order for these locks to function.

<comment><USER11> A single downward lock cycle uses 100,000m³. About 35-40 ships per day transit the canal, so a single day wastes about 4,000,000m³ of water.

The Mississippi River discharges about 17,000m³ a second. Each day, that river alone discharges 1,450,828,800m³ of water.

Closer to the canal, the Amazon River discharges as much water as a ship locking does every ½ second. Admittedly, the Amazon River is by far the largest river in terms of discharge.

If my math is right, the Panama Canal uses less water than a small metropolis.

<comment><USER12> I think it's important to point out that "uses water" here means "temporarily restrains water on its natural way to the ocean."

This water isn't being pulled out of storage and dumped in the ocean, it's precipitation that would be going into the ocean anyway.

Using it in the canal first could very well _reduce_ the amount of fresh water that reaches the ocean, since retaining it would cause some evaporation loss. Although I'm sure that's completely insignificant either way.

<comment><USER13> The artificial lake created by the canal (Gatun Lake) has a surface of 425km² so indeed we can effectively say that some water has been restrained on its natural way to the ocean.</comment></comment></comment></comment>


Ask HN: are you stuck on your side project? - <AUTHOR>

have a side project, but you are stuck on a problem? or have some spare time to help a fellow programmer? give us the link to your Github repository and get help from HN <comment><USER2> I've been building a web based comic book reader on and off for some time now. I am integrating it into a chrome packaged app and am struggling with reading zip and rar files via javascript.

Right now I am using bitjs (<http://bitjs.googlecode.com/>), but it is very slow and often results in corrupt images. I am thinking of using NaCL to use a native unzip / unrar in chrome application, but have no experience with NaCl or C++. Has anyone done anything similar?

<https://github.com/balaclark/chrome-comic-reader> <https://github.com/balaclark/HTML5-Comic-Book-Reader>

<comment><USER3> >I am integrating it into a chrome packaged app and am struggling with reading zip and rar files via javascript.

Does it have to be a chrome packaged app? If not, take a look at appjs or node-webkit.

</comment></comment><comment><USER4> I'm trying to build a kind of IRC-clone using socket.io. I know that I'll have to reduce the commands to be implemented, but there's still a lot of work to be done. I do not have a specific problem, but sometimes I just don't know how to start. For instance I'm going to implement an in-browser multi-room feature, but currently it's only possible to be in one room using a specific username. I would be really happy about new features or/and ideas. Feel free to contribute. <https://github.com/blubbi2/Thor>

<comment><USER5> Really good app, nice work!</comment></comment>


Four major cities move to ban diesel vehicles by 2025 - <AUTHOR> http://www.bbc.co.uk/news/science-environment-38170794 <comment><USER2> This is a bold move. I wish India shall implement this too.</comment>


Griffonnage: Scribble careless drawings with friends, privately - <AUTHOR> https://griffonnage.now.sh <comment><AUTHOR> Hi folks,

Over the last few weeks, I've been hacking an end-to-end encrypted collaborative drawing app. I started coding this after seing all my friends and colleagues using Skribbl.io which is very far from being a privacy-first service. And I'm a regular user of Excalidraw, so I figured I could bring the best of both worlds!

I am looking for some help developing it as this is just a fun side project. If you have some coding skills, the tech stack is composed mainly of Nuxt.js + Fabric.js + Socket.io + TweetNaCl.js. The code is completely free and open- source: [https://github.com/griffonnage](https://github.com/griffonnage)</comment>


Ask HN: Where/How to find good contract/telecommute opportunities? - <AUTHOR>

I see the occasional post on here for jobs, but what other sites have you used to find good opportunities...especially contract/telecommute. Thanks. <comment><USER2> I'm looking for this myself. It's not easy. Most major job sites have a telecommute option (so you can search for these kinds of jobs). Craigslist is another good option.</comment>


Show HN: DemonTunes.com, web based music player. - <AUTHOR>

I've been working on a new project of mine, and it's near completion for release.
You can listen to music for free, streamed via youtube. It's all web based and works via ajax!
It is really easy to share music with your friends, here a few examples:
A playlist of mine: http://demontunes.com/p/br
Link to a song http://demontunes.com/s/CCsPt6ZTbIQ
The website is: http://demontunes.com/  or http://demontunes.com/player/
Would like to hear some feedback! <comment><USER2> Great site. I used to own audiolizer.com that did the same thing but with less features.

One thing that worked out really well for us was allowing users to import their itunes libraries/playlists. You just need to parse the iTunes XML and map them title/artists to YouTube videos and users would be able to import thousands of songs in seconds.

A few questions:

\- How do you plan to make money?

\- With YouTubes new song filtering, a lot of songs aren't the original pitch anymore- how do you deal with that?

\- Have you considered using the Grooveshark API?

Good luck with the site!

</comment><comment><USER3> The interface is clearly a clone of iTunes, but boy is it done well! Nice work.

</comment><comment><USER4> did you do both the ux and the coding? It's very impressive work.

<comment><AUTHOR> I made it together with someone, but I did all of the coding and most of the design.</comment></comment>


Richard Stallman nominated to be in MIT 150 exhibition - <AUTHOR> http://museum.mit.edu/150/entries/1289

<comment><AUTHOR> I actually had a hard time deciding whether to nominate Stallman or nominate the GPL. Then I realized that the MIT License could also deserve a nomination. But when push comes to shove, if you figure only one representative icon of FOSS might be included in the actual MIT150 exhibition, it seems like it should be Stallman.

</comment><comment><USER2> RMS in a museum? The jokes almost write themselves.</comment>


CES Gadget Show: Surveillance Is In – and in a Big Way - <AUTHOR> https://apnews.com/eb29de015e3d454ca24025777a8784ed <comment><USER2> I try to remain optimistic about the future, but stuff like this really makes very difficult.</comment>


Ask HN: Renaming jade due to trademark, is it really necessary? - <AUTHOR> https://github.com/pugjs/pug/issues/2184 <comment><USER2> As a practical matter it is more about the value of hiring attorneys to provide advice and potentially litigate.</comment>


We are sacrificing the right to walk - <AUTHOR> http://aeon.co/magazine/society/step-by-step-americans-are-sacrificing-the-right-to-walk/

<comment> m-i-l Previous discussion: [https://news.ycombinator.com/item?id=10141795](https://news.ycombinator.com/item?id=10141795)

<comment><USER2> Why has the limit to resubmissions been lowered so much? It used to be months.

<comment><USER3> I thought the limit was "is currently in ram".

<comment><USER2> Maybe it's just increased submission volume then? I'm pretty sure you couldn't resubmit a 4 days old url a couple of years ago.

</comment></comment></comment></comment><comment><USER4> Another previous discussion: [https://news.ycombinator.com/item?id=8111353](https://news.ycombinator.com/item?id=8111353)

Me and my scientist buddies came back from Galveston, Texas with a lot of stories about how Police addressed us while walking, how we were threatened and made people feel very threatened by walking into a drive through, how we couldn't cross a road in a large shopping area anywhere (one was supposed to drive between parking lots), how at 3 in the morning the streets were still full of cars.

Here in the Netherlands we bike but I had a student from Bulgaria who had absolutely no trouble walking an hour to work. American culture is very car oriented, drive through ATMs, drive through pharmacies and yes I talked to someone who went to a drive through funeral, just sign the register hanging out the window, nod to the casket and drive on.

Perhaps it has to do also with the fact that in Europe for example many city centers are not even accessible by car because they were build hundreds of year before cars existed?

<comment><USER5> If driving in NL was as affordable and enjoyable as it is in the US, I'm convinced more people would do it.

</comment></comment><comment><USER6> The car culture seems to be strongly linked with an obsession of living in suburban in the US. Is there a causation relationship, and which direction would the causal effect be?

<comment><USER7> > obsession of living in suburban

Well, you want to be able to afford it, not have to drive more than 45 minutes to work and not get killed on the way from the car to your house. That kind of narrows down the viable alternatives.

</comment></comment><comment><USER8> Recently I was asked "You don't drive? Aren't you a man?", so I guess it is not masculine to be a pedestrian in some circles.</comment>


NewLisp - <AUTHOR> http://www.newlisp.org/index.cgi?Home <comment><USER2> Has anyone ever used NewLisp for something interesting? Would you mind talking about your experience? NewLisp, despite the name, is actually quite old at this point, and its release cycle has slowed down a bit over the years. I'm assuming it landed so high on the front page because people are interested, so some real-life stories would be helpful.

(I have a real-life story that concludes with "so I got fed up and rewrote the thing in Python", but I'm not all convinced that the problem wasn't with me.)

<comment><USER3> I remember looking at it 12 years ago or so, for embedded applications. For some reason I decided to go with ISLISP instead, though I no longer remember why.

<comment><USER4> oh, so newlisp is not that much new then.

<comment><USER5> > oh, so newlisp is not that much new then.

Well, its new compared to Lisp in general.

<comment><USER6> its features are comparable to old Lisps from the 70's, prior to Scheme and Common Lisp. Nothing really new here at all and lots of old bugs passing for features.

</comment></comment></comment></comment></comment><comment><USER7> Dynamic scope.

Pass everything by value.

No closures.

No GC.

Implement almost the whole thing in one giant 7k line file[1].

I can't tell if this is a work of genius or madness.

[1]: [https://github.com/kosh04/newlisp/blob/develop/newlisp.c](https://github.com/kosh04/newlisp/blob/develop/newlisp.c)

</comment><comment><USER8> I'm just going to list all of my criticisms after reading what's on the website:

1\. Treating functions as lists effectively makes this a weakly typed language like C, whereas both Scheme and Common Lisp are both strong.

2\. What advantage does having implicit function arguments (using nil if not provided, not default arguments) have at all unless if you just hate type safety and would prefer unreliable software? There are lots of other ways to maintain type safety while eliding runtime type checks in hot loops.

3\. Changing the binding time for free variables within a closure would also imply that a binding by that name must be in scope at the time the function is called, no? This sounds like dynamic scoping... which is known to be difficult to use and error prone. Do you just assume 'nil' when no binding exists?

<comment><USER9> NewLisp was designed by a psychologist, who took meticulous care to endow it with design elements such that it would be instantly hated and denounced by anyone who has had anything to do with real Lisp, causing them to spew babble that is incomprehensible to NewLisp n00bies, save for the lingering perception that something gratuitously negative has been spoken. This, in turn, has the calculated effect of making them dig deeper into their trenches.

It is best to remain silent upon the subject of the NewLisp design. Let people make their bed and lie in it.

By the way, if you want to see a really crazy NewLisp zealot, search for Kazimir Majorinc. Wow ...

Maybe he's quit since (and even reformed?); it's been a few years.

> _Changing the binding time for free variables within a closure_

What closure? NewLisp has done away with those, and offers "name space contexts"

[http://www.newlisp.org/index.cgi?page=Closures](http://www.newlisp.org/index.cgi?page=Closures)

These are basically something like modules with static variables.

<comment><USER10> I'm not sure it's fair to tar all newLISP advocates with the same brush. I understand the design choices that Lutz Mueller made, and I can understand how they might be considered unsatisfactory by other Lisp users. That's fine-- I don't expect newLISP to be everything to everybody, and I don't consider it to be the be-all and end-all of languages.

I do find it to be very lightweight and flexible, with excellent documentation and a good built-in library. This makes it useful as a scripting language and for rapid prototyping. I wouldn't recommend it for very large-scale tasks or for projects developed by large teams.

<comment><USER9> > _I don 't expect newLISP to be everything to everybody, and I don't consider > it to be the be-all and end-all of languages._

Lutz Mueller does. For instance, quote: _LISP is an old language born, grown, and standardized in times very different from today, times when programming was for highly educated people who engineered programs. newLISP is LISP reborn as a scripting language: pragmatic and casual, simple to learn without requiring you to know advanced computer science concepts._

Sure, no advanced computer science concepts: just five different hacks to choose from to do some aspect of what a lexical closure does. (Just pick the one whose assumptions are least likely to break in your use case: but no engineering knowledge required to do that, nope!)

NewLisp requires the users to absorb advanced concepts that have fallen by the wayside of the computer science mainstream. A fexpr or self-modifying code are still computer science concepts.

Basically what Lutz is the real problem in NewLisp; other than that, the thing is what it is, take it or leave it. More than needing a compiler, garbage collection or lexical closures, it just needs a dose of humility, really.

On that note, it's somewhat good to see that a lot of the anti-Lisp ranting has been toned down compared to just several years ago. I don't get the sense that Lutz is yet eating any real crow. At best, he's pouring crow-flavored syrup over his ice cream. But at least that's a start!

</comment></comment></comment></comment><comment><USER11> People interested in NewLisp may also like Pixie, a small Clojure-like scripting language.

[https://github.com/pixie-lang/pixie](https://github.com/pixie-lang/pixie)

<comment><USER12> But, newpLisp's tiny C codebase can be compiled and made to run on even obscure UNIXes like AIX, Solaris, HPUX etc without installing any dependencies which Pixie needs.

<comment><USER11> Of course, Pixie is not the most appropriate tool for every possible application. How fortunate that we have so many great open source tools to choose from!

</comment></comment></comment><comment><USER13> [http://picolisp.com/](http://picolisp.com/)

</comment><comment><USER14> The memory management scheme is very novel: [http://www.newlisp.org/MemoryManagement.html](http://www.newlisp.org/MemoryManagement.html) I don't get how it can work since it would require most objects to be passed by value and not reference.

<comment><USER9> It isn't novel. Basically, it assumes that objects are stack allocated and blows them away when expressions finish evaluating. Anything which escapes out of an expression is copied, so there is no reference graph.

Copying objects to avoid lifetime computations is far, far from novel. It is ancient. Think about all the C program modules that use strdup on strings that are passed around, over the place, so that they can then `free` their copy with confidence that nobody else has a pointer to it. In C++, there are smart pointers for one-reference only, like std::unique_ptr. (Long before that became standard, C++ coders did similar things from scratch.)

Stack allocation of temporaries which go away when a stack frame is blown away is certainly not new. The implementor of NewLisp just had to look to the implementation language C to get this idea.

Mature Lisp implementations have this as a built-in optimization in their compilers. That is to say, recognizing non-escaping temporary objects and optimizing their reclamation, and even allocating them on the stack. ANSI Common Lisp also has the (declare (dynamic-extent ...)) declaration to manually request, or suggest that this may be done with an object. (The programmer promises not to let that object escape, and in return, the implementation can stack-allocate it.)

NewLisp's claim is that the memory managent is novel in _interpreters_ (because the author knows that Lisp _compilers_ can identify temporary objects that don't need to be retained past the evaluation of their containing expression). Is it really novel? It might be true of the limited number of interpreters that the author knows about. If we were to exhaustively research the history of computing, we'd probably find other interpreted languages with copying memory management. Oh, here is one: GNU Bash. Look for uses of the function copy_word_list in the Bash sources. GNU Bash seems to be implementing "ORO" memory management for lists of strings passed around as arguments and other structures.

</comment></comment><comment><USER15> On a tangentially related note, there's a project that aims to redesign some of Common Lisp's semantics to be more modern [0]. Its name is CL21, as it's meant to be "Common Lisp for the 21st century", and it's written entirely in Common Lisp, relying on the kick-ass features of _reader macros_ to introduce new syntax to the language. In my humble experience, integrating it with Shelly [1] and the large swath of Quicklisp [2] libraries can turn it into a terse and reasonably efficient scripting language. (Sadly, you still need a CL implementation and runtime, and they are mostly quite slow.) Definitely worth a look if you like NewLisp's syntax and libraries, as I can see some similarities in the philosophies.

[0]: [http://cl21.org/](http://cl21.org/)

[1]: [http://shlyfile.org/](http://shlyfile.org/)

[2]: [https://www.quicklisp.org/beta/](https://www.quicklisp.org/beta/)

<comment><USER16> > Sadly, you still need a CL implementation and runtime, and they are mostly > quite slow.

Say what now? SBCL is normally within a factor of 2 of C, and sometimes faster than C, and the commercial Lisps are even better.

<comment><USER15> I was referring more to their startup time. The runtime introduces delay when you type in the script command on a CLI.

Regardless of that, the factor-of-two-or-sometimes-faster argument sounds a little far-fetched for me, care to provide some sources on the benchmarks? Not saying it's not true, I'm just not accustomed to seeing highly extensible and dynamically-typed languages such as Common Lisp perform so fast.

<comment><USER17> Check out the benchmark game for some decent benchmarks of various languages. Here's sbcl vs gcc c:

[https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...](https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=sbcl&lang2=gcc&data=u64q)

On several benchmarks sbcl is less than three times slower than c.

And I never noticed a startup delay with sbcl. Let's do a simple test.

        $ echo 'print("hello")' > test.py
        $ echo '(format t "hello")' > test.lisp
        $ time python test.py
        hello

        real    0m0.033s # 33ms
        user    0m0.027s
        sys     0m0.003s

        $ time sbcl --script test.lisp
        hello
        real    0m0.006s # 6ms
        user    0m0.000s
        sys     0m0.003s

        # I couldn't figure out how to run newlisp w/o starting
        # the interactive interp so I'll give it a string
        $ time newlisp -e '(print "hello")'
        hello"hello"

        real    0m0.002s # 2ms
        user    0m0.000s
        sys     0m0.000s

So sbcl starts up about 5 times faster than python, which lots of people use for scripting. newlisp seems to startup about 4ms faster than sbcl. I really don't see a scenario where the startup time of sbcl is a problem. Just for fun let's look at java.

        $ java -version
        openjdk version "1.8.0_60"
        OpenJDK Runtime Environment (build 1.8.0_60-b24)
        OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
        $ time javac hello.java

        real    0m0.386s # ouch
        user    0m0.910s
        sys     0m0.040s

        $ time java hello
        hello

        real    0m0.066s # 66ms, once compiled
        user    0m0.067s
        sys     0m0.007s

</comment></comment></comment></comment><comment><USER18> I discovered this a while back, because Nearly Free Speech has it as a CGI scripting language. The details of it's GC was rather interesting -- I've been meaning to implement it in one of my lisp projects.

EDIT: I just checked, apparently nfsn doesn't support that? Weird, now I have to work out what website I found it through...

<comment><USER19> It is listed as a LISP on the NFS CGI versions page:

[http://ultraviolet-cgi.nfshost.com/](http://ultraviolet-cgi.nfshost.com/)

<comment><USER18> Ah, that's where it got to! I was searching somewhere entirely different for some reason. Thanks.

</comment></comment></comment><comment><USER20> I saw this [https://news.ycombinator.com/item?id=2909881](https://news.ycombinator.com/item?id=2909881)

</comment><comment><USER21> This is an honest question: why create a lisp instead of a scheme? What is the fundamental feature that makes NewLisp a LISP more that a scheme language?

<comment><USER22> newLISP is not a derivative of Common Lisp or Scheme or any other Lisp. It's a different language in a similar style.

I wish the Common Lisp camp wasn't so insistent on equating "Lisp" to "Common Lisp." It's annoying having to tiptoe around them by saying "Lisp-like language."

<comment><USER23> When people developped Rust or Go, did they say "this is a C", or "This is newC"? They said: "this is new language with a C-like syntax with such and such features". Why not be precise?

<comment><USER22> When Stroustrup created C++ or Hejlsberg created C#, did C progammers spend decades whining about their choice of names and alienating newcomers?

<comment> muuh-gnu They didnt have to, neither Stroustrup nor Hejlsberg called their languages "a C".</comment></comment></comment></comment></comment>


Bitcoin is near-perfectly following the platonic form of a bubble - <AUTHOR> https://twitter.com/rhcm123/status/910506163778834437 <comment><USER2> Doesn't anyone remember that the number of total bitcoins is limited in supply, like Gold? [https://i0.wp.com/bilbo.economicoutlook.net/blog/wp- content/...](https://i0.wp.com/bilbo.economicoutlook.net/blog/wp- content/uploads/2009/09/USD_gold_price_1900_2008.jpg)

</comment><comment><USER3> This shape has been seen again and again in bitcoin, every time there is a bubble this occurs.</comment>


Historic documents in computer science and engineering - <AUTHOR> http://www.fh-jena.de/~kleine/history/history.html <comment><USER2> Strictly, the algol family.</comment>


Stanford's Has Long Offered Free Entrepreneurship Lectures - <AUTHOR> http://ecorner.stanford.edu/podcasts.html

<comment><USER2> I absolutely love Entrepreneurial Thought Leaders and have listened to every one of them, many two or three times.

The two podcasts that have really spoken to me are both on negotiations. "Secret to Successful Negotiations" and "The Art of Negotiation".

</comment><comment><USER3> From the title the post seems to be a reply/response/comment about the recent attention given to the free programming classes. While these podcasts are certainly useful they pale in comparison to the free class project.

Sure opencourseware is great and has been around for a while. But stanford is actively engaging with the distance students who are using the materials for free. It is an amazing contribution.

Its 2011 and the internet is finally making good on one of the utopian promises that we first heard of with the advent of radio, then TV and most recently the internet.

</comment><comment><USER4> Tip: You can also subscribe to these on iTunes. They are perfect for work commutes.

<comment><USER5> Yup. I get these on my windows phone. Perfect companion for my lunch time listening.

</comment></comment><comment><USER6> If you're interested, here's info on the newest lecturers at Stanford for the fall: <http://stvp.stanford.edu/blog/?p=4269>

</comment><comment><USER7> They are brilliant. The list of speakers is mind-blowing. Thanks.

</comment><comment><USER8> Carnegie Mellon: <http://www.cmu.edu/itunesu/>

MIT: <http://web.mit.edu/itunesu/>

Michigan: <http://itunes.umich.edu/usingitunes/>

All have pretty good lectures, though on entrepreneurship the ones from Stanford seem to be best

<comment><USER9> Don't forget open courseware: <http://ocw.mit.edu/courses/>

There are similar resources for a lot of top tier universities. I've since lost my bookmarks, but maybe someone can post the ones for Harvard and others.</comment></comment>


Chicken Scheme internals: the garbage collector (2014) - <AUTHOR> https://www.more-magic.net/posts/internals-gc.html <comment><USER2> I wanted to learn a LISP-like language and tried Chicken for a bit and then switched to Racket. Reason: Documentation. I constantly got stuck with Chicken, often because the documentation available is for a previous version. No such problems with Racket and their, imho, excellent guide.

No doubt Chicken is a great language with cool features, it's just not very beginner friendly.

<comment><USER3> The documentation for eggs of the previous version has a link at the very top to the latest version.

For other cases, please consider letting us know exactly where you got stuck on IRC or on the mailinglist. Without feedback we can't fix things! The community is very friendly to beginners, even if the documentation isn't.

<comment><USER4> This I have also found to be the case, though ultimately I also focused more on learning Racket because, coming from Python, I was used to a more "batteries included" experience.

</comment></comment></comment><comment><USER5> Previous discussion: [https://news.ycombinator.com/item?id=7499101](https://news.ycombinator.com/item?id=7499101)

Unfortunately, the pipeline.com links no longer work, and I haven't been able to coax the Wayback Machine into giving me more than the first page of the Cheney on the MTA paper.

<comment><USER6> This link works for me:

[https://web.archive.org/web/20170811235424/http://home.pipel...](https://web.archive.org/web/20170811235424/http://home.pipeline.com/~hbaker1/CheneyMTA.pdf)

That site was one of the better collections of lisp technical papers. I hope it's not gone for good, it was there earlier this year.

<comment><USER7> It's gone up & down a few times; I _really_ hope that it hasn't gone for good.

</comment></comment></comment><comment><USER8> Cheney-on-the-MTA is a classic. tl;dr:

1\. Transform into continuation-passing style.

2\. Use the C stack as the young generation by calling each continuation as an ordinary C function.

3\. When the stack reaches a limit, copy all reachable objects to the heap, "free" the young gen via longjmp() back to the bottom of the stack, and continue on.</comment>


Ask HN: Viability of selling expertise in languages for academic purposes - <AUTHOR> I have a friend that is currently doing her Master's thesis and will need to use R for statistical work. She has no programming experience and little R experience. I'm not a professional programmer but do it for fun, for open-source or personal needs. I have some experience with the likes of ruby, bash, html, css, javascript, and processing.
Since her deadline is looming I've decided to learn R to help her. I figured it'd be easier for me, due to my programming background. So far, that seems about right. I can quickly find newbish mistakes and help with understanding the documentation of the commands she needs.
This got me thinking. What if I learn languages used in academic circles (R and LaTeX come to mind) and then sell my expertise? I'm thinking of academics that need sections of their work done in those tools but have little time or skill. They might prefer spending both on the rest of their study, hiring me to help with the technical bit.
Is this a viable idea? I've read (from patio11?) students and teachers are the worst consumers/clients, as they never want to spend money. Perhaps researchers are a bit different in that regard.
I'm mostly interested in the LaTeX / other languages part of the question. I haven't enjoyed R much and it's clear programming experience is not enough if the client doesn't have a grasp of the statistic behind the models.
Is anyone having success doing this, freelancer or not? Is it worthwhile? Any tips to get started (including languages I might not know about)? <comment><USER2> Learning how to use the fundamental tools of your field is part of the job, whatever field you are in.

It is generous of you to help her with R (which is not used in all fields). Latex is mandatory for any scientist in STEM, she won't escape it. Moreover, Latex is not at all like programing, content and Latex instructions are mixed. It may help to think about it like an empowered HTML/CSS for scientific writing.

I think your idea is doomed for several reasons:

\- Becoming an expert to the point you can sell your skills to scientists will take you a lot of time

\- Money is going thin in labs, it is unlikely that anyone has a budget line for this kind of thing

\- As a scientist, I would be very suspicious of someone contacting me for this kind of work. I would suspect an attempt to steal ideas and/or work.

\- There are (were?) people in the labs to help scientists: research associate.

</comment><comment><USER3> Might want to go find some scientists and ask them.</comment>


Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go - <AUTHOR> https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581 <comment><USER2> This is a good example of an absolutely pointless comparison. The author is making some bold statements:

> Go performance is comparable to Java

> .Net Core 2.0 can execute up to 3x faster than Go.

> Consistent performance of compiled vs dynamic

But what are they measuring? How fast can a lambda function return "200 OK hello"? This is just sad.

<comment><USER3> They are effectively measuring how fast AWS infrastructure can reach whatever it needs (VM?) for each language.

But these are not even cold start times. I'm assuming after the first request this is using the same VM (/backend job, whatever) to reply, so now it just depends on latency to get to that VM. (I'm assuming the runtimes' ability to return "200 OK" is similar and the latency of that is negligible compared to AWS infra that is involved.) Not completely meaningless, but not super useful either, esp without any details while making those bold statements. This is not "Go is equal to Java". This is "AWS Lambda infrastructure for Go is comparable to AWS infra for Java". Article is unclear on that.

Maybe this tells us AWS lambda backend infra is way different for .NET Core than Go and Java? ¯\\_(ツ)_/¯

<comment><USER2> > This is "AWS Lambda infrastructure for Go is comparable to AWS infra for > Java"

I wouldn't even go that far. They are not measuring anything that any real- world application would do. Heck, it's not even a todo app, it's just a "200 OK hello".

It's more like "AWS lambda function invocation overhead for Go is comparable to AWS lambda function invocation overhead for Java".

<comment><USER4> Sure but if you start adding in language specific Web frameworks / json handling / db work you're no longer testing AWS.

I agree there's questionable value here but at least it's bring constrained to as few variables as possible.

<comment><USER5> Benchmarking the lambda-add latency is something that is useful as long as it's called out as such a benchmark.

</comment></comment></comment></comment></comment><comment><USER6> Why the hate? The methodology is sound, the results are interesting and they show that there is some room for improvement in language support. Also the source code has been provided in case anyone wants to alter the benchmark to be more comparable to their workloads.

Hopefully this sparks a race between the different teams within Amazon. Great job!

Oh! These test scenarios seem to have a pretty good acceptance in case you decide to do another benchmark in the future: [https://www.techempower.com/benchmarks/#section=code&hw=ph&t...](https://www.techempower.com/benchmarks/#section=code&hw=ph&test=fortune).

</comment><comment><USER7> To the extent that this benchmark is valid, this is interesting:

"In the original 2017 benchmark results, the compiled languages of Java and .Net Core 1.0 were clearly more consistent compared to the dynamic languages — Python and Node.js.

Based on the latest 2018 performance testing results — we are no longer observing any significant variances between Java and the newer compiled languages (.Net Core 2.0 and Go), and the original dynamic languages."

TLDR: You may be able to use a "slower" language for Lambda without necessarily losing much.

<comment><USER8> >> You may be able to use a "slower" language for Lambda

at least for small projects

</comment></comment><comment><USER9> Ok, now being serious, they need to include a real example here. Whenever I run a Lambda function is to process something and make a call to at least one external service. I was a .NET developer for a long time and I seriously doubt .NET Core has been improved to the point where blocking http calls are handled better than in Go runtime. I may believe .NET Core may have some performance advantages in some CPU bound scenarios, but nothing more. Until then, this benchmark proves nothing.

<comment><USER10> In which scenario would you use a blocking http call?

<comment><USER11> Not necessarily HTTP, but I imagine hitting some sort of database from a lambda is not uncommon.

<comment><USER12> Isn't the intent with a system like Lambda that you'd not do any kind of blocking action. Instead, you'd trigger some event that the AWS database solutions would receive. Once the DB has finished the query it sends the data back and triggers another lambda function.

EDIT: I write this as someone who does no web programming and has only toyed with AWS. This was my understanding from what I read, but not something I actually made.

<comment><USER13> No. "Once the DB has finished the query it sends the data back and triggers another lambda function"

What mechanism is the DB 'sending' data via? Is it just the response part of the initial query? Then it's executing in the context of the same lambda function. You -could- then call another lambda function from the running lambda function (but why?), but more, what was the function that executed the query doing while it waited?

If it had something it -could- be doing, it should be doing it, so non- blocking is important. If it had nothing it could be doing, it literally does not matter if it was a blocking call or not; it doesn't effect anything.

Now, if you meant you have a trigger in the DB that calls another lambda function, such that the original lambda could complete, yes, of course you could do that. However, if this was a GET style call, not a PUT, your options to get the data back to the user are limited if you don't just keep the REST request open and respond that way. Certainly, any other solution is more complex, probably more expensive, and may not be possible.

</comment></comment></comment></comment></comment><comment><USER14> Lambdas bill at a 100ms minimum. What's the point of a few ms of difference here, unless you're running some computationally-intensive code? If that's what you're doing, the efficiency of the language itself is going to be what matters, not Lambda's speed of executing the runtime.

</comment><comment><USER15> > we are no longer observing any significant variances between Java and the > newer compiled languages

<proceeds to show averages instead of mean and/or 90th percentile even though maximum spikes are easily orders of magnitude higher than average>

</comment><comment><USER16> Go on par with Java? .NET 2.0 beating everything else out?!

I feel like my world has just flipped upside down.

</comment><comment><USER17> I have been doing a lot of experiments with Go and Lambda and have an open source boilerplate app here: [https://github.com/nzoschke/gofaas](https://github.com/nzoschke/gofaas)

This benchmark leaves some room for improvement. With Lambda and X-ray you could really deep dive into where time is spent in a request. Here's an example trace for a Golang function that does some actual work against KMS and DynamoDB:

[https://twitter.com/nzoschke/status/969598630033162240?s=20](https://twitter.com/nzoschke/status/969598630033162240?s=20)

One thing I found surprising about the Go support is that the 'lambda.Start' helper uses reflection to invoke your go func. This could contribute to some of the cold start time.

<comment><USER18> Yeah that certainly seems...non ideal.

</comment></comment><comment><USER19> I am glad that the person who created this intended for the results to be reproducible. I will try my hand at what's in the git repo, and perhaps compare with some other languages too.

</comment><comment><USER20> Comparing their open-source ecosystem, I still prefer to build my lambdas with NodeJS (or even Python) over C#. (if my only concern is performance)

</comment><comment><USER21> What would be the right way to test this?</comment>