Pulumi – A new open-source cloud development platform - <AUTHOR> http://joeduffyblog.com/2018/06/18/hello-pulumi/ <comment><USER2> I was a part of the alpha testing and I liked it so much I added Kubernetes support in my free time.

A thing I notice about the space is that existing tooling tends to be very focused on a specific persona (e.g., ops), and when you want to do anything outside those use cases, it starts to feel like you're jamming a square peg into a round hole. So, e.g., Go templates/sed/awk work great if _all_ you want to do is template a couple YAML files, but if your use cases is even slightly more demanding (sharing, dependencies, transforming), it gets painful quick.

Using a "real language" makes all of this much simpler. You can write tooling that captures the needs you actually have. If you have an ops team that wants a mostly-declarative or mostly-hermitic API, you can write that, and you _don 't_ have to map it to CloudFormation, ARM templates, Terraform, etc. Huge win. You can write JS/TS/Python libraries that provide secure defaults for your core infrastructure components. You can use standard dev tools to audit and refactor code you've written.

In Terraform, modules have proven to be very useful. For Pulumi, I'm interested to see what the _tooling_ ecosystem will look like as the product becomes more mature.

</comment><comment><USER3> Hmm, I was excited to see a former Midori developer working on a "cloud development platform". And I was even more excited to read:

>Using Pulumi, you author cloud programs using your favorite language, spanning low-level infrastructure-as-code to highly productive and modern container- and serverless-powered applications.

I'm enthusiastic about the prospect of using a real programming language to deploy and control a distributed system. It would be fantastic to have a library that gives me a nice, clean API for performing low-level distributed system tasks, manipulating and controlling hosts at the level of individual processes and sockets.

But I was disappointed to see that Pulumi doesn't seem to be designed to support deployment onto bare metal. In fact it seems to be just another layer of abstraction over various SaaS providers, or a huge dependency like Kubernetes. Why add another layer?

Today's systems are already heavily abstracted. For me, the value of using a really expressive programming language to implement a system, is that you can keep more of the abstraction in the language, and thereby avoid complexity in the underlying architecture.

To me, it is not very interesting to layer yet another library on top of the Kubernetes API. I'd be much more interested to see an attempt to _replace_ the Kubernetes API with a library. This seems to be the former, and not oriented towards the latter, which is a bit of a disappointment.

<comment><USER4> > Pulumi doesn't seem to be designed to support deployment onto bare metal.

In principle, there is no reason we couldn't support bare metal, provided we have an orchestrator. Pulumi bottoms out on raw CRUD operations that can do anything. It turns out that, when targeting existing cloud providers, that means invoking their APIs. As you say, this is just a layer of abstraction, but the key aspect at the center here is diffable immutable infrastructure.

I was, in fact, inspired to pursue Pulumi in part because of the experience of building a distributed OS that ran on bare metal. Many of the same challenges Pulumi solves around configuration, composition, and the application model, were inspired by this experience, and we've taken some of those lessons and applied them to cloud programs.

> you can keep more of the abstraction in the language, and thereby avoid > complexity in the underlying architecture.

I look at other ways we've integrated with systems as inspiration here. For instance, we can productively code using tasks, and async await, these days, and reap the benefits of concurrency, despite there being massive differences between threading, I/O, and scheduling behavior across different systems. There was abstraction in the language, but it bottoms out on a set of primitives.

In a sense, I view the current APIs we're using as the syscall layer for a given cloud, Kubernetes included. (Also note, we don't require depending on Kubernetes.) That's not to say everybody will want to eschew the syscalls -- there's always a time and a place -- but we can be more productive by using the abstractions.

I believe that frameworks _are_ languages, in that they give you a set of nouns and verbs you can use to express yourself. I do think there's opportunity for language-level innovation here, but if there's one thing I've taken away from our industry experiences building PaaS's, it's that it's a losing battle to bet against the incredible momentum of the public cloud vendors.

> I'd be much more interested to see an attempt to replace the Kubernetes API > with a library.

We are just getting started, so expect to see a lot more progress in this direction in the weeks to come. The foundation of languages is a huge enabler for us, and we already have several projects in the works that I think will make you happier than this initial release.

YMMV, this is just my opinion, and I really love hearing the feedback. Thank you for sharing. This is a vibrant space and time and I'm enjoying the diversity of perspective.

<comment><USER5> I can't speak for the GP with certainty, but maybe the source of the disappointment is that with Midori, you built a new OS from the ground up, throwing out all the accumulated cruft and doing it all in an elegant, unified way. On the other hand, Pulumi is just another layer on top of a cloud stack (or stacks) that many people see as too complex already.

I see the wisdom in it, though. Most developers these days aren't shipping their own servers off to a data center. And for those that want bare metal, there are providers that offer bare metal servers provisioned through a CRUD API, so Pulumi should be able to work with those.

</comment></comment></comment><comment><USER6> When I read a blog about "cloud development platform", I expect to understand how it fairs vs. Terraform. I'm already using Terraform. All the cloud "consultants" I know of, use Terraform. In order to not use it, I need a reason - I need something that Pulumi can do, and Terraform can't.

<comment><USER7> (I'm a product manager on Pulumi.)

If Terraform works for you, then definitely continue using it. Pulumi is just another option and works well for building libraries and components. I did a rundown of different tools for serverless apps at Velocity SF last week. Slides are here: [https://cdn.oreillystatic.com/en/assets/1/event/270/Tooling%...](https://cdn.oreillystatic.com/en/assets/1/event/270/Tooling%20in%20the%20age%20of%20serverless%20computing%20Presentation.pdf) and GitHub samples are here: [https://github.com/lindydonna/velocity- examples](https://github.com/lindydonna/velocity-examples)

There are a ton of tools in this space, all with overlapping functionality, so there tends not to be a clear comparison of tool X vs tool Y.

<comment><USER6> Hi, thank you for the slides and repo - lots of good material there. Just in case I've failed to clarify my intention: I'd really like to know the upsides of "Pulumi". I'm sure it was built for a reason (i.e dissatisfaction wrt other tools). I just don't have the bandwidth to blindly invest myself in tech without some promise that something will end for the better for me or my company. Thanks!

<comment><USER7> The main upside is that it's just regular code. This is more natural for some folks, but mainly the advantage is that you can build abstractions. So, you can build a component that's built up from lower-level resources in AWS. For example, directly setting up API Gateway requires a specific setup (and can be error-prone), so there's a Pulumi library for that.

My colleague wrote a blog post with more of the technical motivation: [https://medium.com/@lukeh/programming-the- cloud-e795cafffc2b](https://medium.com/@lukeh/programming-the- cloud-e795cafffc2b), and there's also this Twitch live-coding video: [https://youtu.be/DM8Wd4f1MNA](https://youtu.be/DM8Wd4f1MNA)

<comment><USER8> Terraform also lets you create abstractions via modules (admittedly with less flexibility than arbitrary code). I'm still not quite seeing the value proposition here over Terraform.

<comment><USER9> How do you share and publish terraform modules? Can you pip install a bunch of common configurations, and compose them together with your own app?

It sounds like the value add for this tool is being able to describe your infrastructure as code rather than configuration, with all the benefits of code over configuration (diffs, loops, package managers, variables, etc).

<comment><USER6> Terraform modules are loaded from local fs, github, or central tf registry - much like pip or npm in spirit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I may be wrong, but from what I can tell this is really a souped-up framework for working with clouds. Most of it looks like primitive for immutable infrastructure, so Terraform but as a library. As far as can tell, there's no deployment system, no orchestration etc. -- a "Pulumi app" doesn't know how to deploy itself. Is that accurate?

So if, for example, you're running an app on GKE, then you can tell the Kubernetes API about the resources you want, but there's no system for building your app (Docker build + push to GCR), no way to do supervised rolling updates, and so on. If you're doing CI/CD, then presumably you have to build, push, then let the Pulumi code inject the right image and tag.

I like the idea of declaring the infrastructure with extensible code (as opposed to a DSL like Terraform where you're completely dependent on upstream support for all the objects you want to manage), but I'm a bit skeptical about crossing the bridge from ops to applications.

Typically applications _aren 't_ self-contained enough that they can, or should, declare all their resources. So presumably then you have to centralize common stuff (e.g. your central Postgres server) in a shared module that all your apps import. Now you get into versioning hell as your app depends on an old version of the "common" module and "pulumi update" tears down your Postgres 10 install and creates a 9.6 install instead. (Presumably it asks first. But still. Versioning has got to be a challenge here.)

<comment><USER7> (Disclosure: I work at Pulumi)

> I may be wrong, but from what I can tell this is really a souped-up > framework for working with clouds. Most of it looks like primitive for > immutable infrastructure, so Terraform but as a library. As far as can tell, > there's no deployment system, no orchestration etc. -- a "Pulumi app" > doesn't know how to deploy itself. Is that accurate?

Not quite. A Pulumi app is always deployed through the Pulumi CLI, which deploys and manages Pulumi programs. Note that most Pulumi code runs at deployment time, not runtime. Instead of specifying resources in a configuration language, you write them in code. The Pulumi CLI turns this code into a declarative plan, and updates your infrastructure when you run `pulumi update`. You may find this doc page helpful: [https://pulumi.io/reference/how.html](https://pulumi.io/reference/how.html)

Docker builds, plus provisioning of a container registry instance (and deploying to it), are handled automatically. This blog post walks through the e2e container scenario (but on AWS, rather than GCP): [http://blog.pulumi.com/deploying-production-ready- containers...](http://blog.pulumi.com/deploying-production-ready-containers- with-pulumi)

> Typically applications aren't self-contained enough that they can, or > should, declare all their resources. So presumably then you have to > centralize common stuff (e.g. your central Postgres server) in a shared > module that all your apps import. Now you get into versioning hell as your > app depends on an old version of the "common" module and "pulumi update" > tears down your Postgres 10 install and creates a 9.6 install instead. > (Presumably it asks first. But still. Versioning has got to be a challenge > here.)

This is just one way to architect an app, and it's unlikely to work well for a database, as you say. In this case, you'd likely use a `database.get` call, where you reference an _existing_ database, that may be managed in a different Pulumi program or stack, or even outside of Pulumi.

</comment></comment><comment><USER11> What is an open-source cloud development platform? I've read the first 5 paragraphs of the blog post and skimmed through the landing page, I've also clicked on the "38 lines of code" example, and I still don't understand where does this fits. I imagined it was something like Heroku, but I guess I was wrong.

I'll keep trying to understand it, anyway.

<comment><USER7> (I'm a product manager at Pulumi.)

Pulumi lets you describe cloud resources using code instead of a config language. It's not like Heroku, it's more like a deployment tool (e.g. Serverless Framework, Terraform, Claudia.js, Chalice, etc).

The difference compared to other deployment tools is that you use regular code, but it's turned into a declarative plan when you run `pulumi update`. So, you get the benefits of a regular programming language, while still following best practices of immutable infrastructure.

Does that help?

<comment><USER12> Then is this something like NixOps [1]? Or how does it differ?

[1] [https://nixos.org/nixops/](https://nixos.org/nixops/)

<comment><USER13> Joe mentions working with "existing language package managers". That probably doesn't include nixpkgs, but perhaps it could.

</comment></comment></comment></comment><comment><USER14> We've had a chance to try out Pulumi when it was in private beta. We are very happy with it so far.

Having used a variety of tools in the space, this is the first time I ever had an engineer say to me: "I really like it, I hope we can keep using it."

</comment><comment><USER15> Reading through it, it sounds very exciting and productive for people who already know what it is and can use it.

But for a complete newbie. Say someone who can write an app and push it to Heroku, what is this and why might it be worth trying out?

<comment><USER2> Pulumi is meant to replace CloudFormation/ARM Templates/Kubernetes YAML. So if you write those things to provision infrastructure, this could be for you.

If you are writing (e.g.) Rails code that you `git push` to a PaaS like Heroku, then they're provisioning this infrastructure on your behalf. So this is a bit lower level than that.

</comment></comment><comment><USER16> Looks very interesting. I have a couple of questions:

1\. One of my pet peeves with CloudFormation is the disconnect between the state of CF and the "actual" state if someone decides to update resources by not using CF. Does Pulumi do checks to verify that the actual state matches its assumed state?

2\. Is there a guide for contributing a new language and/or provider?

Also, I tried getting an invite for the Pulumi Slack community and was greeted with "invite_limit_reached".

<comment><USER17> I'd like to know the answer to that as well... Error handling semantics across languages vary greatly. Does the user code need to handle errors or mismatched state or does Pulumi? If Pulumi does how do you get/ report errors?

<comment><USER18> [Disclosure - I'm a Pulumi employee]

There is a top-level CLI verb called `refresh` that explicitly checks Pulumi's idea of the state of the world against the actual state of the world. If there's a diff, Pulumi reconciles the diff by updating its own state. `pulumi update` does not do this by default, but you can run `pulumi refresh` at any time to verify that your state has not drifted from reality.

</comment></comment></comment><comment><USER19> Python 2 support only, which is sad. I fully intend to try out the Azure provider, but without access to Python libraries there is not much I can create off the cuff.

Also, this reminds me a bit of metaparticle, which I'm quite fond of.

<comment><USER20> I was able to play with the Python support in the Beta. The team intends to stick with 2/3 compatible code and support Python 3 next milestone, so you should be able to try it out soon.

</comment></comment><comment><USER21> All I know is the fonts on HN now look weak and puny compared to the the fonts used in the blog.

I don't mean this as a joke, I am seriously having issues looking at HN fonts after reading the blog. Even my emacs fonts are broken to me now.

How can a site just steal my ignorant bliss away and ruin my entire system with something as simple as fonts!

</comment><comment><USER22> I wish this worked on bare metal. The options for running on premise cloud are slim to none and the CM tools for managing that have shaky support. It's such a shame. I don't want to just be another customer for DO, AWS, Azure, etc.

</comment><comment><USER23> I am coming at this from a competing perspective so take it with a grain of salt...isn't the whole idea of the declarative approach that users/Ops can focus only on specifying what they want and let whatever target execution run- time handle the actual semantics?

An approach that goes back to relying on procedural programming languages as a primary means of configuration seems like it defeats the purpose.

I am working in this space, mainly focused on configurations: [https://youtu.be/4yepPOznakk](https://youtu.be/4yepPOznakk)

The approach we've adopted is to maintain the declarative presentation while providing a way to plug in procedural language programmability without using templates or other similar concoctions (ksonnet..etc).

</comment><comment><USER24> This looks interesting but I really don't like how you're prompted to download and run a shell script from their website without any indication of what it does. I'm all for making it easy to get started, but at least explain what the script does.

<comment><USER25> Thanks for the feedback! The script will download the latest version of Pulumi, extract it to ~/.pulumi/bin and then try to add that folder to your .bashrc or .bash_profile.

You should be able to read the source of the script directly at [https://get.pulumi.com/](https://get.pulumi.com/) or even download it yourself, inspect it and then decide if you want to run it or not. You can also follow the manual install instructions which are listed a little further down on our install page at [https://pulumi.io/install/](https://pulumi.io/install/), if you want total control over where it is installed.

I also just opened a pull request to our docs website: [https://github.com/pulumi/docs/pull/430](https://github.com/pulumi/docs/pull/430) to explain in a little more detail what we're doing with the scripts.

<comment><USER26> I'd appreciate it if I could install Pulumi via e.g. $ brew install pulumi

That way I'd have a convenient way of keeping it updated to the latest version

</comment></comment></comment><comment><USER27> This is beautiful. Looked at the serverless url shortener example. It abstracts over all the configuration garbage and combines all the AWS infrastructure elements as one unified working body.

I'm worried that I might run into a case where it might provision something and I wouldn't know what it did to my AWS account necessarily.

I'll 10/10 give this a go for my next AWS project. Also, no YAML woo!

<comment><USER7> (Disclosure: I work at Pulumi.)

The `pulumi update` command first shows you a preview of the exact resources it will create. Once you've deployed, you can view all your resources on the pulumi.com console, so you know exactly what has happened.

<comment><USER27> Perfect thanks for letting me know :)

</comment></comment></comment><comment><USER28> From the "tour" on the homepage it seems that you need an account with Pulumi ("Most commands will prompt you to login to the Pulumi service when you run them"). Is this mandatory or can I use the open source code on its own?

</comment><comment><USER29> Been looking forward to the launch, congrats to all involved on pulumi team!

</comment><comment><USER30> Hi Joe, congrats on the launch.

What is difference in the use case for Pulumi compared to scripting infrastructure using vendor provided libraries e.g. New-AzureRmVm et c

<comment><USER4> > congrats on the launch.

Thanks -- we're very excited to be out and talking to the community!

> What is difference in the use case for Pulumi compared to scripting > infrastructure using vendor provided libraries

The major difference is that Pulumi does immutable infrastructure. The code describes a goal state and our system manages your environment to ensure that it matches the goal state. This means you can preview changes before making them, and that, if you do make them, you've got a full audit trail of who changed what and when. Rollbacks are trivial because you just point us at an old goal state worked and we can chew on it until your live environment matches. We can even detect drift, so if someone manually updates in the cloud console, we can tell you about it. As a result, we always have a full object graph of your cloud resources, and can tie it back to the source code which created it, opening up some unique diagnostics capabilities.

The difference with scripting libraries, like AWS's Boto, or the Azure PowerShell SDK, is that they mutate cloud resources directly, and in an ad-hoc manner. So, you don't know what they are going to do before you run them. And in the event of failure, you're more likely to be in a corrupt state and unable to recover. Rollbacks are difficult. There's also no audit trail beyond the cloud access logs, and information like dependencies are lost, so resources end up disassociated from the code and workflow that created or updated them. Many people encounter these problems and need to build complex systems on top to address them. Or they end up using a solution like CloudFormation or Azure Resource Manager, which eschews code in favor of JSON/YAML/templates.

The hope here is that we've landed on a sweet spot between immutable infrastructure and fully programmable languages.

</comment></comment><comment><USER31> It's a pity they didn't offer .net support from the start. I wonder what were the reasons, besides popularity contest.

<comment><USER25> > I wonder what were the reasons, besides popularity contest.

(Disclosure: I'm a member of the Pulumi team).

Strictly a timing issue. We brought TypeScript/JavaScript online first and most of our focus was there while building up the supporting tooling. Fortunately, the design of the system makes it pretty easy to add new languages (we've since then done Python and Go). Most of the team is ex-.NET folks and I've been itching to build out the .NET support. Now that we've launched, it will at least become /my/ spare time project.

I'll be really excited when we have it well. Do keep your eye out!

</comment></comment><comment><USER32> this looks really interesting - keep going!

</comment><comment><USER33> > How do we know? We don't need to

Pulumi looks like clever technology but the complete detachment from the underlying services and associated costs seems like the perfect storm for an extremely expensive disaster.

How does Pulumi keep track of which services are launched, especially during testing/development, and how does it ensure those are shut down once they are no longer needed? How does it determine the optimal size of instances/volumes/etc to launch?

<comment><USER34> Hi! I work at Pulumi and have been using it to standup and manage all of our service infrastructure.

> How does Pulumi keep track of which services are launched, especially during > testing/development

Each Pulumi program is ran within the context of "a stack". The stack is essentially a collection of cloud resources. So when the Pulumi program runs, it will create resources that aren't in the stack, or update existing ones.

So if you create any resources during dev/testing, you just need to `pulumi destroy` those stacks and all of the cloud resources will be reclaimed.

This, IMHO, is one of Pulumi's best features. In that it makes it super-easy to create your own instance of a cloud application. For example, I have my own development instance of app.pulumi.com by just creating my own Pulumi stack and rerunning the same application.

> How does it determine the optimal size of instances/volumes/etc to launch?

It doesn't. The Pulumi program ran determines what resources to create. So you are left to configure, tune or tweak that as makes sense.

<comment><USER10> From the examples it looks like Pulumi programs declare their infrastructure, causing it to be created. Doesn't that mean that the program will need privileged credentials? How do you make sure the app only has, say, read access to an S3 bucket it needs to listen to, and can't accidentally delete it? And how does that then allow it to declare the bucket?

<comment><USER34> > Doesn't that mean that the program will need privileged credentials?

Obviously whatever program is actually creating the cloud resources will need credentials to do so. However, they aren't part of the Pulumi program.

When you run `pulumi update` on your machine (or on a CI/CD server) Pulumi will pick up whatever ambient credentials are on the machine. (e.g. ~/.aws/credentials.) So if you to restrict the credentials used to update a particular Pulumi stack, you just need to swap out whatever the current credentials are. (e.g. an AWS_ACCESS_KEY_ID env var.)

> How do you make sure the app only has, say, read access to an S3 bucket it > needs to listen to, and can't accidentally delete it? And how does that then > allow it to declare the bucket?

There are a lot of good questions there, so let me show you a quick example:

```typescript const imagesBucket = new aws.s3.Bucket( "images", { bucket: "example.com-images", acl: "private", }); ```

This snippet will create a new AWS S3 bucket named "example.com-images". It also sets the default ACL for the bucket to "private". Nothing too surprising there.

If you wanted another resource to have read access to that bucket, you would need to configure AWS to grant access. The Pulumi programming model is about how you declare/describe/create resources, but not actually define policy for how they work. So when using AWS, you would potentially need to create an `aws.iam.Role` / `aws.iam.RolePolicyAttachment` object and hook them up. (Or, if using Azure or GCP, configure access using some other method.)

So in short, to configure what _cloud resources_ can read/write other _cloud resources_, it's a matter of how the cloud resource provider exposes that.

When it comes to matters like preventing you from accidentally deleting the resources when you run `pulumi update` on a program, there are a few features that can help you with that. You can mark a resource as `protected`, so that any update that would delete that resource would produce an error. (Until you update the program again, making that resource as not protected.) Also, the `aws.s3.Bucket` type has a `forceDelete` parameter, that does something very similar. Unless set to true, the Bucket object cannot be deleted. (Thereby preventing some accidental dataloss.)

Does that make sense?

<comment><USER10> Makes sense. That makes it sound like Pulumi only runs the infrastructure declarations when you run "pulumi update", and that those things don't run when your program runs. That's confusing to me, because your examples (like the thumbnailer) seems to have the program and the declarations in the same file.

Is Pulumi stateful, then? If you create resources with "pulumi update", change the declarations without updating, and run "pulumi destroy" or whatever, it will only delete the stuff you created in the first step? (That is what I would expect. I would also expect it to support a dry run mode with a diff showing what operations would be executed.) If so, where is this state stored?

<comment><USER7> (I'm a product manager at Pulumi.)

> That makes it sound like Pulumi only runs the infrastructure declarations > when you run "pulumi update", and that those things don't run when your > program runs. That's confusing to me, because your examples (like the > thumbnailer) seems to have the program and the declarations in the same > file.

This is an optional way to do it, by combining the runtime code and infra code. The runtime code doesn't run when you deploy with "pulumi update," but it is packaged and sent to AWS.

You can also put the runtime code in a different file, as in this example: [https://github.com/lindydonna/velocity- examples/tree/master/...](https://github.com/lindydonna/velocity- examples/tree/master/pulumi/pulumi-serverless)

> Is Pulumi stateful, then? If you create resources with "pulumi update", > change the declarations without updating, and run "pulumi destroy" or > whatever, it will only delete the stuff you created in the first step? (That > is what I would expect. I would also expect it to support a dry run mode > with a diff showing what operations would be executed.) If so, where is this > state stored?

Yes, the state is stored on pulumi.com. The state is list of resource IDs that you provisioned. The Pulumi CLI does indeed have a dry run mode that shows a diff: whenever you run "pulumi update", it first shows a preview.

<comment><USER35> Is there an option for self-hosting your state files vs relying on pulumi.com?

<comment><USER14> You could self-host if you want. The default is relying on pulumi.com

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> [deleted per personal request]

<comment><USER37> What are you talking about?

<comment><USER36> .NET, future, responsibility. In that order.

Tangentially touching human ego and how it can spoil the intentions. Unless one finds the way to work with it.

Sorry if that's too intense.

<comment><USER38> Joe's a really nice guy. Have you ever worked with him or been in a meeting with him? Sorry, this type of ad-hominem attack really does not belong here.

<comment><USER36> Sorry. I hear you. I'm deleting the original message.

<comment><USER38> Thank you. Kudos for doing the right thing :)</comment></comment></comment></comment></comment></comment>


Anna Wiener on her book "Uncanny Valley" - <AUTHOR> https://www.theguardian.com/books/2020/jan/06/anna-wiener-uncanny-valley-silicon-technology-political-surveillance <comment><USER2> Essay from n+1 that led to the book: [https://nplusonemag.com/issue-25/on-the- fringe/uncanny-valle...](https://nplusonemag.com/issue-25/on-the- fringe/uncanny-valley/)

(As literary magazine names go, "n+1" is pretty relatable haha)

<comment><USER3> Really incredible writing. I can absolutely see why this turned into a book.

Also the self reflection of being in the industry is notable.

<comment><USER4> It's also semi-unnerving for what it portends regarding the possibility of deep rot in our political economy. Yes, we've seen treatments like this before. Yes, the author is probably missing the mark a bit (or missing it even more if you're an optimist or realist or whatever). But still.

I recently read a number of historical treatments of the late gilded age and the roaring twenties, as well as some notable treatments of 20th century American history that partially covered that era, or provided additional insight into it (e.g. "The Glory and The Dream").

There are two strong impressions of that era that jump out from the historical literature. They are something like: "where are the adults?" and "business activity at full-speed, moving nowhere at all".

</comment></comment></comment><comment><USER5> It's interesting. She sounds like a pro writer. I wonder if her four years were really research for a planned book. That kind of thing is very common. If so, it's paid off. She's hot news, right now. Being exec producer on a movie before the book is even out, is sort of...Silicon Valley.

My own perspective is kinda weird, and I don't pretend to be an expert in the culture.

I started programming in 1983, with machine code, and I've been doing this stuff a very long time. As I look around at folks in the industry, I see that it is a _very_ long time, indeed. There's not many people with the length of time in the industry I have (which is not necessarily something that has been beneficial to me).

I spent most of my career at a top-shelf Japanese corporation. It was a frustrating, but also awesome, experience that has almost no analogue at all with Silicon Valley culture. It was basically a "silo."

After leaving that company a couple of years ago, I have been acclimating to a vastly changed landscape. It's been rather eye-opening.

The one thing that has struck me the most, is that money seems to have become rather corrosive, while also energizing. It powers a lot of growth, innovation and energy, but also brings with it an almost complete moral vacuum. The Japanese corporation had many flaws, but I was impressed by their focus on teamwork and almost insanely high ethical standards (It was a very "old- fashioned" company). I regularly worked (and argued) with some of the most brilliant scientists and engineers in the world.

I like the energy, and I think some of the tools and techniques that have developed are really nice, but I have been rather taken aback by the manner in which our culture is expressed, these days. It's very different from the rather "scrappy" and hopeful way we thought about things back when.

I'm figuring out how to navigate the new world. I need to learn how to work in the fast-paced, cutthroat culture, while holding to my ethical compass, and my workflow.

<comment><USER6> >She sounds like a pro writer. I wonder if her four years were really research for a planned book.

That makes it sound rather nefarious. Rather than the experience motivating a book, it reduces it to a muckraker looking for drama. Non-fiction p-hacking. This is a big accusation dressed up as idle speculation, and it's motivated by nothing other than the fact that she's really good that this? I'm saddened to see this sitting up here as the top comment.

<comment><USER5> Sigh. No nefarious intent meant. I suspect that it started off as genuine employment, but it wouldn't surprise me at all if things changed. I have known a number of folks like that.

Personally, I like them, and I completely support this. It's far better than writing from an ivory tower.

In fact, I find it rather interesting that you assign nefarious intent to me.

<comment><USER6> Nah, I'm not assigning you nefarious intent ("sigh" but i could find it rather interesting that you perceive that I am, if that's how we're doing this now). I'm saying that it would be less innocent of _her_ to go in with the intent of collecting material, which makes your idle speculation potentially damaging.

<comment><USER5> Not at all. I think this is just an example of one of those "differences in culture" that I was mentioning.

We seem to have a "combat psyche" in our communications, these days, where we start off from a critical PoV, and degenerate from there; always looking for wrongs and weaknesses.

I see this a lot, possibly because I don't hide my age, and may be perceived as "ok boomer." It could also be that I simply come across in a rather "starchy" fashion. That's deliberate. If you knew me personally, you might (possibly) have a different view, as I might, of you.

No big deal. I'm getting my comeuppance. I used to be a rather..."pithy" troll, in the UseNet days. I tend to overcompensate for that, these days, and probably come across as "stuffy."

I just don't ever want to go back into that cesspit again. That's a big reason that I stick my personal brand on all my work and interactions on the Web.

I want to be held to account for what I say. If I say something that offends you, you know where to find me (look at my HN account page).

With that said, you actually have a good point. I did not mean it that way, but it's easy to see why it was interpreted that way. I screwed up how I wrote it.

However, just because someone misinterprets my intent, does not make their interpretation correct, even if I screwed up the way I wrote it, and encouraged that interpretation.

I'll see if I still have time to edit it, and maybe correct it.

 _EDIT:_ Nope. Too late.

</comment></comment></comment></comment></comment><comment><USER7> Whomever changed the headline should change it to something that accurately reflects the content, like it was before.

Nobody who doesn't already know Anna Weiner or Uncanny Valley would understand the meaning of the headline.

<comment><USER8> I changed the headline because the site guidelines call for titles to be changed when they're baity, as "the explosive memoir exposing Silicon Valley" is.

That doesn't mean I changed it to anything optimal—I'm at an event this morning and doing moderatory things on breaks, so everything is hastier than normal. If anyone can suggest a better title—that means more accurate and neutral, preferably using representative language from the article—we can happily change it again.

<comment> jagged-chisel "Anna Wiener, and her book 'Uncanny Valley'"

comma grammar at your discretion

<comment><USER9> I like this, but I would change "and" to "on", since it's an interview.

"Anna Wiener on her book 'Uncanny Valley'"

<comment><USER8> We'll use that above. Thanks!

</comment></comment></comment></comment></comment><comment> jagged-chisel Bit of context since the title needs improvement:

Anna Wiener, a former GitHub employee, authors a book titled "Uncanny Valley" about "Unregulated surveillance, ruthless bosses, sexual harassment..." in Silicon Valley.

Also, from TFA: "in January 2018, Universal Pictures optioned film rights; the screenplay is now in its initial development stages and Wiener is executive producer."

</comment><comment><USER10> Anna Wiener will be talking at some events in SF, NY and other places soon [https://twitter.com/annawiener/status/1205176302149484545](https://twitter.com/annawiener/status/1205176302149484545)

</comment><comment><USER11> Is Silicon Valley represented solely by startups these days?

<comment><USER12> Perspective is a problem even on HN.

You have the folks who only think of FANG as far as anything tech / coding practices goes.... or only think of their greenfield startup as how things are done.

Or that everything is some ultra deep back end computer science project ... and they bring those points of view to everything (that isn't necessarily bad or good).

Granted, all that variety is nice, but I suspect a lot of the grass roots coding world just isn't quite what we see on HN.

<comment><USER13> This common criticism misses the fact that FANG, and greenfield startups, and even HN, set the tone for much of the tech industry.

It is very likely that these grass root coders are or will be in the coming years using the very tools, methodologies, and even business practices devised in the Valley.

<comment><USER12> They certainly do those things.

I think they also are a bit of a rabbit hole / and plenty of their tone never reaches the wider world while they chase new and shiny things.

</comment></comment></comment></comment><comment><USER14> >To illustrate this point she highlights public goods or services that are increasingly privatised, like for-profit coding boot camps, which are marketed as an investment or a substitute for a four-year university degree. "The tech industry is trying to provide solutions to crises that they didn't necessarily create, but that they are now exacerbating.

This is a good example of how lines of thought like the author's that purport to be democratic socialist are actually committed to maintaining the institutions that entrench existing inequalities in cultural, social (and of course, financial) capital.

<comment><USER15> What's socialist about VC-backed "bootcamps"?

</comment></comment><comment><USER13> Maybe the writeup doesn't do book justice but it all sounds like boiler plate views journalists have on SV with no real insight. Mike Judge probably doesn't have to worry about any competition even after the series ended.

<comment><USER16> I gave up on SV (the show) when the only female character I saw after several episodes was a hot assistant. I don't care what her character arc turned out to be, that's a bad look. Hopefully, a show based on a female former insider's experience will offer something beyond that.

<comment><USER17> Why is it a bad look ? If you'd actually watch the show they have many female characters that are not hot assistants and they even touch on the subject directly later on. It's kind of hard for me to fathom how that particular aspect can make someone give up on a satire TV-show

</comment></comment></comment><comment><USER18> It's so aggravating going to these news sites. It's almost as bad as the days of search bars installed in your browser. I'm not on the biggest screen in the world, but I can't even see the title of the article. [https://i.imgur.com/UYT7qpN.png](https://i.imgur.com/UYT7qpN.png)

I've been to plenty of other sites just as bad too. It instantly kills my desire find the article and read it.

<comment><USER19> If more people paid for journalism, sites like The Guardian's wouldn't have to have those banners.

To turn it around: what journalism have you paid for recently?

<comment><USER18> I actually am willing to pay for journalism, but it becomes a constant research project to find out what source isn't on a biased agenda crusade. Any recommendations on pure journalism source I should check out?

<comment><USER19> There has never been such a thing as "bias-free" journalism. We all have biases, and so do journalists and their editors.

If you're willing to pay for journalism, find a newspaper – any newspaper – and buy a subscription. I assume from your posts that you're in America, and politically right-of-centre. What about the Wall Street Journal? It broke the Theranos story and many others, and employs a raft of very good journalists doing important work.

<comment><USER18> The wsj does seem to not cater as much to opinion pieces or clickbait titles. I guess that's what I was asking. I get plenty of opinions and editorials for free these days, I don't want to pay for that even if I agree with them. I miss the outlets that seemed to focus on straight up news.

We had a local paper in my area, The Western Star, that ran for 206 years. It was the last source that I was really dedicated to, because I cared a lot more about local.

RIP Western Star [https://ohiomemory.org/digital/collection/p16007coll84](https://ohiomemory.org/digital/collection/p16007coll84)

<comment><USER19> Remember that for a paper like the WSJ or New York Times, opinions/editorials consume a tiny fraction of the budget: an editorial on Theranos might cost the newspaper $500, but the series of articles that eventually led to the downfall of the Theranos might easily cost 100 times that.

</comment></comment></comment></comment></comment></comment><comment><USER20> > left her job at the software development platform GitHub

What is it about GitHub in particular that attracts these activists?

<comment><USER21> If by activist, you mean an excellent writer providing an accurate reflection, that anyone working the bay area the past 10 years can relate to?

<comment><USER20> The headline says "I want this book to be politically useful". Sounds pretty activist-y to me.</comment></comment></comment>


Uber takes its self-driving cars off the road after one flipped over in Arizona - <AUTHOR> https://qz.com/942199/uber-suspended-its-self-driving-cars-after-one-flipped-over-in-tempe-arizona/ <comment><USER2> [https://news.ycombinator.com/item?id=13954323](https://news.ycombinator.com/item?id=13954323)

</comment><comment><USER3> _" Anthony Levandowski, the Otto founder who became head of Uber's self- driving efforts last summer, also shares Kalanick's brash disregard for regulatory authority. Bloomberg reported earlier this month that a running joke at Otto was "safety third."_

Uh oh.

The California DMV won't yet allow testing of autonomous vehicles heavier than 10,000 pounds on California public roads. Otto is thus testing in Arizona. Looks like that was a good decision by DMV.

I wrote this on HN yesterday:

 _An important question is whether their system is smart enough to take evasive action._

 _It 's becoming clear that there are two ways to approach self-driving. The first stems from the DARPA Grand Challenge, which was about off-road driving. For that, the vehicles had to profile the terrain, plotting a path around obstacles, potholes, and cliff edges. The GPS route was just general guidance on where to go. That's the approach Google took, as can be seen from their SXSW videos. Google also identifies moving objects and tries to classify them. With all that capability, it's possible to take evasive action if some other road user is a threat. The control system has situational awareness and knows where there's clear space for escape._

 _The other approach is to start with lane following and automatic cruise control, and try to build them up into self-driving. This can be done entirely with vision systems. That 's the Cruise Automation and Tesla approach. This puts the car on a track defined by lines on the pavement, with lane changes and intersections handled as a special case. There usually isn't a full terrain profile; that requires LIDAR. So there isn't enough info to plan an emergency maneuver for collision avoidance._

 _This distinction is not well understood, and it should be._

<comment><USER4> Maybe I'm misunderstanding, but your last paragraph seems to imply that the "Tesla approach" is unable to "plan an emergency maneuver for collision avoidance"

If true, that would seem to mean that Tesla's self-driving car program is dead on arrival. Clearly emergency collision avoidance is not optional for a self driving car with mass adoption. That's a pretty serious claim to make.

<comment><USER3> Here's 25 minutes of what Tesla is currently shipping as their latest release.[1] This is not freeway driving, but suburban roads, which the current system really isn't intended to support. It gives a good sense of what the system can and can't handle. Traffic islands turn out to be a big problem, especially if the lane line leads to the center of the traffic island, not the edge. This is what happens when you're not profiling elevation. The system also loses its edge reference when passing wide driveways. Realistically, this thing is good for long freeway drives, and not much else.

Detection of other vehicles, as shown on the dashboard display, is far below the level Google has demonstrated. Often, there's a nearby car that's not showing on the display. This probably reflects that Tesla only has vision and radar forward; side sensing is just short-range sonar, like a backup warning system.

What self-driving software Tesla is going to ship in the future is not publicly known, but we do know the sensor suite they're currently using, and it's far below Google or Volvo level for situational awareness.

[1] [https://electrek.co/2017/03/18/tesla- autopilot-2-autosteer-t...](https://electrek.co/2017/03/18/tesla- autopilot-2-autosteer-test-video/)

</comment></comment></comment><comment><USER5> I found this bit the most interesting:

> Recode also obtained documents showing that Uber's self-driving cars > currently need to be handled by their human safety drivers roughly once > every 0.8 miles.

That's _really_ far from autonomous.

EDIT: Here's the Recode article:

[https://www.recode.net/2017/3/24/14737438/uber-self- driving-...](https://www.recode.net/2017/3/24/14737438/uber-self-driving- turmoil-otto-travis-kalanick-civil-war)

and things just get worse. The cars only make it an average of 2 miles between incorrect sudden movements, down from 4 in January. What a joke.

<comment><USER3> Uber is that bad? That's terrible. They shouldn't be off the test track yet. They should be testing at GoMentum Station, which is the former Concord Naval Weapons Station north of Oakland. That place was built to store battleship ammo; if anything bad happens there, there's nobody close enough to get hurt.

Google/Waymo's California DMV disengagement report for 2016 reports 0.20 disengagements per 1000 miles, or one disengagement per 5000 miles.[1] Google's cars drove 635,868 miles autonomously in 2016, so there's enough driving behind this for that number to be meaningful. This is 4x better than 2015, incidentally. CA DMV accident and disengagement reports are worth reading, since they're one of the few objective data sources available on automatic driving. So far, nobody has been willing to turn a self-driving car over to Top Gear or Road and Track.

Google/Waymo is thus three orders of magnitude better than Uber, and about two orders of magnitude better than anybody else who tests in California.

[1] [https://www.dmv.ca.gov/portal/wcm/connect/946b3502-c959-4e3b...](https://www.dmv.ca.gov/portal/wcm/connect/946b3502-c959-4e3b-b119-91319c27788f/GoogleAutoWaymo_disengage_report_2016.pdf?MOD=AJPERES)

<comment><USER6> > Uber is that bad? That's terrible. They shouldn't be off the test track yet.

No kidding! Yet somehow I'm not surprised, as it has always been pretty obvious that these jackasses didn't know what they were doing. This just adds to the many reasons why I am fully 100% behind getting them and other amateur- hour efforts (like geohot's comma.ai) off the road right now, and keeping them off until they can _prove_ they are safe enough to be out on the public streets mixed with human drivers, cyclists, and pedestrians. I live and work in San Francisco and walk pretty much everywhere I go. I don't need to be watching out for some shitty "self driving" car that has to have a person take over every 0.8 miles whenever I'm trying to cross the street. Fuck that. If they keep this up, someone is going to get seriously hurt or killed.

<comment><USER7> This just represents how much corporate DNA can affect outcomes down the road.

Uber grew up on saying fuck you to government regulations. And it worked for them, because the only real losers were taxi cartels, and as much as I hate Uber, taxis were ten thousand times worse (in SF), which is more or less widely agreed on AFAICT. But it fails at dealing with the problem of autonomous vehicles, which is an existential threat to Uber. This is why Uber won't exist a decade from now.

Google grew up and succeeded through throwing lots of engineers at problems and building close, incestuous alliances with the government and academia, to avoid undue negative attention. This has plenty of downsides, but it's definitely the only plausible winning approach for getting autonomous cars actually on the road.

</comment></comment></comment></comment><comment><USER8> Is anyone interested in making a public bet with me about autonomous vehicles? I'm thinking something like, we publicly state that within 5 years a self- driving car will be able to take me from my apartment in Boston to my work in Cambridge, regardless of weather, time of day, etc. If it can, I pay you $1000, if it can't, you pay me $1000.

Basically I'm getting super annoyed at people claiming self driving cars are right around the corner, which I've been reading for a decade, but it's always "just 5 years away". I would love to counter arguments with, "If you are so convinced why not bet me $1000?"

<comment><USER9> "regardless of weather, time of day, "

Thats difficult. People who talk about "self driving cars 5 years away" aren't usually talking about mythical level 5 self driving that is actually 40 years away. They are talking about level 3, which basically means, "end to end travel, in 90% of situations".

Just like how 1/10 times you might not be able to flag down a taxi cab, today, 1/10 times you won't be able to get the self driving taxi to go EXACTLY where you need to go.

But it will work for most situations, most of time, and thats good enough. (IE, imagine if 90% of taxi drivers or truck drivers were made obsolete. That is industry destroying)

<comment><USER10> So on days conditions are bad, the city comes to a stand-still?

<comment><USER9> No. On days where self driving cars don't work, price goes up, and the market puts more humans on the road.

So 10% of the time you pay the normal taxi price that you pay now, and 90% of the time you get the super cheap self driving price.

That's still awesome!

<comment><USER11> > _No. On days where self driving cars don 't work, price goes up, and the > market puts more humans on the road._

So all these humans are just hanging around waiting for it to snow so that they have the pleasure of driving other people around? The market will react instantaneously?

Or are they doing other gigs in the meantime, like delivering people's lunches, laundry, groceries et al?

<comment><USER9> I don't know. The market will decide.

Maybe they will have other jobs. Most uber drivers work part time anyway, so that's not any different.

Maybe you have to pay people a premium to be an emergency driver.

Or maybe people will just drive less when it is snowing. Most of the time when I am using transportation, I don't 100% NEED to go on the trip. Maybe Ill just buy groceries tomorrow instead of today.

But even so, if 90% of the time, transportation prices are near 0 $, that is still crazy distruptive.

The market can easily solve any of the problems you are bringing up, just with behavioral/price chances.

And trucking isn't even affected by any of the issues you brought up. An x% chance of being a day late is easily worth 90% shipping cost decreases.

</comment></comment></comment></comment></comment></comment><comment><USER12> >Local police say there were no injuries and Uber's vehicle was not responsible for the incident.

Seems odd that they'd make this move unless it was to avoid more negative press for continuing the program.

<comment><USER13> Easier to pull the cars from the markets and have less attention be paid to the Waymo suit. Good, bad, meh reports will mention the lawsuit every time and that's a larger PR nightmare than this right now.

</comment></comment><comment><USER14> Makes sense to me. Every bit of "Uber self-driving car" press is going to mention that nasty Waymo lawsuit. At this point, Uber has got to be looking to stop the bleeding.

</comment><comment><USER15> It's weird that there is no way for regulators to know how good a self driving car really is; there might be many hours of driving but it's not like an aeroplane where you can have coverage of most conditions. New conditions could happen all the while.

Add to the fact that Tesla have the richest dataset they have a huge advantage in this area one that will reap rewards and crash less that the competition. I think Uber and Volvo will be far behind.

<comment><USER16> That's an interesting point.

What are the challenges behind creating a licensing test similar to the ones we take as humans(could be virtual)? This would be before allowing the software on the road.

<comment><USER15> Actually this would be a great YC company; tests for self driving cars that added certain unexpected events to proceedings that were internal to the testing.

Such things could include push bikes, road crashes, collisions, crazy Deathproof style driving, etc. How do self driving cars react to other drivers using their horns or ambulances for that matter? How does a police car pull over a self driving car?

</comment></comment></comment><comment><USER17> Reading the comments below. Looks like a rush to judgement as I've seen other articles suggesting that the Uber car was bit by another driver who failed to yield. Should driverless cars be under scrutiny for every counterpartt human error.

</comment><comment><USER18> I imagine this is a response to the awful press around the company the past several months. The Uber of 2015 would not have taken these cars off the road.

<comment><USER19> I think the odds that Uber would make money developing self driving cars was approximately zero. Look where Tesla Motors is after fourteen years in terms of producing and selling automobiles and without internal competition from another primary line of business.

Self driving vehicles will have the same profile as the existing automotive industry: high capital costs and commodity margins. The existing automotive mega-corporations already have the capital investment and distribution networks like ships and rail cars and lots and auto-carrier semi-trailers. Tesla is building some of that and the jury is still out on whether Tesla will make a meaningful dent.

Even the idea of Uber rolling out a self-driving fleet means a massive infusion of capital that is at odds with its current cost structure. And the existing automotive mega-corps can step into the ondemand business with a cost advantage in regard to rolling out vehicle fleets.

<comment><USER20> What still isn't clear to me is why Uber is involved in the _development_ of self-driving cars, vs. profiteering and duplicating once the first viable examples have been released.

On the surface autonomous vehicles appear to be a long-term capital draining exercise. Do they view the first mover advantage as that beneficial in this case that they'd risk all their future growth to be first to market for something that they could, conceivably, get a better ROI for being "second" to market with a more durable option?

<comment><USER21> Uber reached its current success with a first mover advantage.

But I think the real reason is that everyone building self-driving cars today - including the big car manufacturers - will have little interest in selling to Uber. They will be running their own Uber-style Car-as-a-Service.

<comment><USER22> IOW, Tesla will be to Uber as Uber wants to be to its drivers.

</comment></comment></comment></comment></comment><comment><USER23> As much as I dislike Uber, I hate the uniformly negative tone the media has switched to now that it's the popular thing instead of singing Uber's praises far more. The same with the possibilities with autonomous driving. Like Theranos, it's not as if many of these issues weren't there for some time, but we've magically transitioned from them being visionary and daring to evil.

<comment><USER24> Like Theranos, the mistake is ever having positive coverage, not only now having negative coverage.

</comment></comment><comment> awinter-py it was probably trying to drift park a la stanford's 'Junior'.

[https://www.youtube.com/watch?v=RY93kr8PaC4](https://www.youtube.com/watch?v=RY93kr8PaC4)

But that trademark Volvo understeer doesn't like to powerslide.

</comment><comment><USER25> I think at this point it is clear that main problem with self-driving cars is not technology but social, psychological, political and legal challenges. People often forget that having good tech is just one step that does not guarantee any commercial success.

People dont change their habits just because new tech is available. People are not going to start buying or using self-driving cars just because tech is available. There is huge psychological and social environment around car driving - e.g. think about all legal paperwork you have to go through to start driving, learning how to drive, buying insurance, all traffic regulations. All this cultural/human factors are based on specific definition of what car is and they all rely there is human subject operating this car. If self-driving cars are really going to succeed all this huge extremely social framework would have to change. I don't think this will happen. I think there are simply too many strong human emotions and purely financial interests around cars.</comment>


Posterous (YC S08) Takes On TwitPic With New API - <AUTHOR> http://www.techcrunch.com/2009/04/17/another-contender-emerges-the-posterous-api-is-like-twitpic-on-steroids/

<comment><USER2> I love the balls of these guys. And they work really, really hard. I don't know how they're both so productive _and_ have the stuff they do be so polished.

<comment><USER3> Normally I'd see somebody coming out and saying 'this is a replacement for X' to be both desperate and a little misguided; desperate because they're putting their (more successful) competitor's name right there in the title, and misguided because by setting yourself up as a X Replacement you quite often both establish yourself in the audience's mind in the exact same space and context as the established service, and also basically communicate: 'You already use X. But you shouldn't. You should stop right now.' Rather than say, 'Look at how cool Y is! You are probably so interested you're going to sign up right now and if you like it, maybe you'll forget about lame old X!'

In Posterous's case, though, they just keep churning out such powerful functionality that the reader ends up agreeing, 'Well hell, why _don't_ I use this?' A look at the official blog just shows you major, polished, easy-to-use feature after MPEtUF.

(But if they don't add Markdown support soon I'm gonna cry.)

</comment></comment><comment><USER4> Rainn Wilson likes it. That's big news: <http://twitter.com/rainnwilson/status/1529141277>

<comment><USER5> and then oddly enough sarah silverman ignored his suggestion and began using twitpic: <http://twitpic.com/photos/sarahksilverman>

</comment></comment><comment><USER6> Tried it, liked it, will use again.</comment>


Ask HN: Can you recommend some 33c3 talks? - <AUTHOR> Which talks of the 33c3 have impressed you and you can recommend? <comment><USER2> I found this one very interesting, about using ultrasound for tracking

[https://media.ccc.de/v/33c3-8336-talking_behind_your_back#vi...](https://media.ccc.de/v/33c3-8336-talking_behind_your_back#video&t=3)

I think it was also on HN a few days ago..

</comment><comment><USER3> In no particular order I found these quite I interesting:

Dieselgate – A year later

Where in the World Is Carmen Sandiego? (Hacking flight tickets)

Visiting The Bear Den (cyber espionage)

Welcome to the Anthropocene

Shining some light on the Amazon Dash button (Super advanced Hardware hacking skills on the dash button)

</comment><comment><USER4> I liked and recommend "The Transhumanist Paradox"

[https://media.ccc.de/v/33c3-8064-the_transhumanist_paradox](https://media.ccc.de/v/33c3-8064-the_transhumanist_paradox)

</comment><comment><AUTHOR> Also see _Great talks and presentations at 33C3_ [1]

[1] [https://news.ycombinator.com/item?id=13309534](https://news.ycombinator.com/item?id=13309534)</comment>


30 Days to 30,000 Downloads - <AUTHOR> http://trivi.al/30-days-to-30000-downloads/

<comment><USER2> Great write. What about total expense for PR during this time period?</comment>


Other Forms of Tinder in China - <AUTHOR> https://kr-asia.com/these-are-some-of-the-most-popular-alternatives-to-tinder-in-china <comment><AUTHOR> Found it quite interesting that these different permutations of Tinder exist in China, appealing to different dating requirements. Are there similar permutations in the US other than the usual few?</comment>


Google search for "blink html" - <AUTHOR> http://www.google.com/#q=blink+html <comment><USER2> <marquee direction="up"><marquee direction="left"><blink>Look at me gooooo!!!!</blink></marquee></marquee>

<comment><USER3> Reference: [http://codepen.io/anon/pen/axgKD](http://codepen.io/anon/pen/axgKD)

<comment><USER4> Alas, people have forgotten the "data:" URL scheme.

data:text/html,<marquee%20direction=up><marquee%20direction=left><blink>Look%20at%20me%20gooooo!!!!</blink></marquee></marquee>

<comment><USER5> "data:" is also disabled by default in Firefox.

<comment><USER4> You mean hyperlinks to data: URLs? At least that's not a problem here, as HN doesn't linkify them anyway, so you'll already have to open the URL manually.

<comment><USER5> No, I meant manually opening data: URLs is disabled. It's a social engineering worry.

</comment></comment></comment></comment></comment></comment><comment><USER6> I feel slightly ill now. I once did this on my netscape binary:

        perl -pi -e 's/<blink>/\0/'

<comment><USER7> Did the binary still run after you did that? (I assume you actually replaced <blink> with 7 NULs?)

<comment><USER6> Oops, yes. It still ran sans blinking text. And I may have actually used emacs on the binary.

</comment></comment></comment><comment><USER8> Kind of awkward given that Chrome's new rendering engine (which has branched from Webkit) is called Blink

[http://blog.chromium.org/2013/04/blink-rendering-engine- for-...](http://blog.chromium.org/2013/04/blink-rendering-engine-for- chromium.html)

<comment><USER9> Aparrently the name is partly a reference to the tag:

> _Why did Google call the new rendering engine Blink? Upson told me it's > obviously supposed to signify how the focus here is on speed and simplicity. > Browser developers, however, also tend to have a tendency to have a bit of > fun with their names. Chrome, for example, is all about making the "chrome" > disappear as much as possible and Blink, he told me, is meant to remind > people of the good old (and annoying) blink tag the Netscape Navigator > introduced in the 90s._ [0]

[0]: [http://techcrunch.com/2013/04/03/google-forks-webkit-and- lau...](http://techcrunch.com/2013/04/03/google-forks-webkit-and-launches- blink-its-own-rendering-engine-that-will-soon-power-chrome-and-chromeos/)

</comment></comment><comment><USER10> Google search for marquee html and you shall see that the result count being displayed as a marqee

</comment><comment><USER4> I looked at it and wondered what was so special about it. Only when I read the comments did I suspect that I had been protected from some great evil by my browser.

You see, I use Firefox. Firefox removed <blink> support a while ago.

<comment><USER11> I see the blinking. Firefox 27.0.1 here

<comment><USER12> Same here.

</comment></comment></comment><comment><USER13> I've wanted them to do this for years, and I know I'm not the first person to think of it. I wonder what made them decide to finally try out a user experience like this.

<comment><USER14> A developer had some spare time and decided to spend it on this, most likely.

</comment></comment><comment><USER15> This reminds me of the old days. [http://www.liu- may.com/notebook/html/01marquee.htm](http://www.liu- may.com/notebook/html/01marquee.htm)

Fun and simple.

</comment><comment><USER16> I am somewhat inspired to put an easter egg in my current project.

</comment><comment><USER17> Why google does it? If its for publicity then why dont they list all of those.

<comment><USER18> Eastereggs are a simple way of getting sympathy (for the less geeky ones like 'tilt') and geek cred (for the geeky ones just like this). Probably, some engineer just built if for relaxation (or training with the code), so the cost of it is neglectible.

A huge part of the appeal of eastereggs is the discovery. Listing them would actually remove that.

It is basically the same as collections of jokes: the are just not as great as one of those jokes randomly being told to you one evening.

</comment></comment><comment> el-mapache This is what happens when you run the internet</comment>


Walney £1bn offshore wind farm is world's largest - <AUTHOR> https://www.bbc.co.uk/news/uk-england-cumbria-45424559 <comment><AUTHOR> £1bn for 659 megawatts doesn't seem to bad - though I guess it doesn't blow the whole time. £1667 per house based on their "enough power for 600,000 homes." My electricity bill would cover that in 2 or 3 years.</comment>


For News Outlets Squeezed from the Middle, It's Bend or Bust - <AUTHOR> http://www.nytimes.com/2016/04/18/business/media/for-news-outlets-squeezed-from-the-middle-its-bend-or-bust.html?_r=0&pagewanted=all <comment><USER2> This is the bed you made, by hitching your wagon to ad revenue. I understand why you did it, it was oh so lucrative, and oh so easy. When you were the gate keepers of news and the primary communications conduit for an entire community you could rake in mountains of cash with very little work. Just rewrite those wire reports; zombie through the motions of reporting local weather, crime, and bullshit; and keep on publishing family circus and cathy strips. The crux of it is that you thought that was noble, that you think it was any different from what buzzfeed does today.

The fall has always been happening, and it didn't start from such a great height either.

The fact is that the news has long been about gathering eyeballs, not about generating quality content. In fact in so much as that happened, it happened by accident or happenstance. Indeed even buzzfeeed does some good work. The difference between you and they is you define yourself by your good work, while you define them by their bad work. And when eyeballs are the measure of success and of revenue, you do whatever is cheapest that gets the most views. Remember the OJ Simpson trial? Remember the news industry descending into tabloid journalism even more so over the past 2 decades? Remember "it bleeds it leads" and disaster-porn?

For the most part the media establishment has become a parody of what a robust media should be. It doesn't do investigative journalism well (usually issues have to be forced down their throats by an already knowledgeable public before they are covered). It doesn't educate the public well on almost any subject (and in some cases, as in Fox News, it demonstrably makes people less well informed). It has a ghoulish relationship with tragedy and disaster (as the movie Nightcrawler so well portrayed). And due to its success it no longer represents the interests of the majority of the public, instead siding with establishment or elite interests most of the time.

You can't merely erect some arbitrary barrier and say that journalism should stick to some particular frozen moment in time as it slides along the same trajectory its been on for ages. You need to get out and build a new trajectory by establishing new standards and developing new revenue streams that reward high quality content instead of low effort content. It's actually already happening without you, but you're too blind to see it. And the answer is not to dumb down hard hitting investigative journalism and add fancy infographics. How do I know? Because that's been what you've been doing for _decades_ and it hasn't worked yet has it?

<comment><USER3> You seem to be implying there is something else they could have hitched their wagon to that would have worked better. I can't see any, and you don't seem to have any better ideas, so it seems like you're effectively criticizing them for trying to exist.

</comment></comment><comment><USER4> There's something very meta about "serious" news organizations writing about how much trouble they're having, competing with "silly" organizations like buzzfeed. I guess this is a minor, backpage story (actually, not quite: [0]), and consists of a nearly-negligible fraction of the NYT's output and resources.

But I wonder what the purpose is of these articles? Is it an attempt to write news with themselves portrayed as simply another exterior subject to write about? Is it an attempt to shame readers into abandoning Buzzfeed with a "shouldn't you be spending your time reading about _real_ news?" piece?

[0] From the bottom of the article: "A version of this article appears in print on April 18, 2016, on page B1 of the New York edition with the headline: For News Outlets Feeling the Squeeze, It's Bend or Bust."

<comment><USER5> The purpose is... <drumroll> informing the readers? Why should the media be prohibited to write about the media and, more importantly, who should do it if they can't?

And of course they'll be reporting from a certain perspective, which is probably going to assign a higher value to the Watergate leak than the ice bucket challenge. But it's unlikely to be a conspiracy - nicely exemplified bt the fact that the "real news" in this article would be Fox News. I doubt the NYT has a secrect pro-Murdoch agenda.

</comment></comment><comment><USER6> Seems like whoever should have edited this piece has already been fired. Long, rambling, and surprisingly myopic -- barely any mention of the Times' response, and full of classic "blame Buzzfeed" insight.

<comment><USER5> It's just not an AP-style news bulletin and more of an essay with about 2.5% Hunter S Thompson thrown in. Nothing wrong with that, some people enjoy it. And and article in the NYT is not a press release by the NYT management. Their reaction to a changing market has exactly as much relevance in such an article as the WSJ's reaction.</comment></comment>


After 3 Months of JavaScript Linting, It's Pretty Much All Pain and No Gain - <AUTHOR> https://www.bennadel.com/blog/3312-after-3-months-of-javascript-linting-it-s-pretty-much-all-pain-and-no-gain.htm <comment><USER2> This is a fantastic example of how to not write a blog post. Putting aside the ridiculous self quotes, the author has missed the point and value prop of linting entirely and set up a perfectly silly straw man in it's place.

Linting exists for two reasons: 1\. To catch silly mistakes (unused variables) 2\. To provide a standard style

In most code bases, and I imagine this is probably true for Invision, code is read much more frequently then it's written. Someone reading my code shouldn't struggle because I prefer tabs or spaces, or because I happen to appreciate an odd spacing scheme. Code should be relatively consistent, expected and non- magical.

Instead this blog post reads like a school kid mad that they have a dress code. There are valid concerns around linting:

\+ linting rules can hurt good practices (what makes sense for one codebase may not make sense for all code bases)

\+ they require regular review (is this pattern still the best one for the team?)

\+ they may be overly designed (and require developers to spend more time fighting whitespace alignment then actually helping readability)

Of course, all of the above are fixable problems. There's no sense in throwing linting out with a ruleset. For most developers linting provides a lot of value in the form of immediate feedback, even if the rulesets used can be flawed.

</comment><comment><USER3> > _Formatting is part of my being - an extension of my genetic makeup. And, > when I write code, my formatting is the fingerprint that I leave behind._

I've read so, so many blog posts that all argue that when working on a team, you should _not_ own code. It's the _team_ 's code, the _app_ 's code, whatever. Don't feel so paternalistic about it.

Don't... don't leave your DNA all over it. I mean, come on, that even _sounds_ gross.

Dude's even inconsistent:

> _That said, my approach to code formatting is the best. If it weren 't, I > wouldn't use it._

> _And, as time goes on and I collect more evidence and experiment with new > choices, my approach to code formatting will continue to evolve and become > more refined._

And, ugh:

> _That said, my approach to code formatting is the best. If it weren 't, I > wouldn't use it._

> _Years ago, I was naive enough to try and make an objective case for my > design choices - I even used science. But, today, I now realize that, while > there is some validity to my argument, personal preference is ultimately the > source of Truth on such topics._

This guy seems really, really not fun to work with.

</comment><comment><USER4> In general, I don't really give a shit about style - I could care less about tabs vs spaces, semicolons vs ASI, etc.

I just want it to be consistent, readable, and not pollute my code reviews with superfluous changes.

So, I prettymuch only use style rules that can be enforced and corrected automatically (usually with `eslint . --fix`). Anything else is just annoying.

I'm also a huge fan of prettier and starting to use it everywhere - [https://github.com/prettier/prettier](https://github.com/prettier/prettier)

</comment><comment><USER5> His examples are kind of strange.

First, I don't really consider const vs let to be the same kind of stylistic rule as single quotes vs. double quotes. Single quotes vs double quotes really don't matter too much. Const vs. let though don't mean the same thing at all, and using them correctly can go a long way to reducing cognitive load. The two keywords simply don't mean the same thing and if his linter is complaining often, it's probably because he doesn't understand the difference.

And if you can't standardize on tabs vs. spaces, you're going to have all sorts of trouble in your commits. This is basic stuff. This article reads like the author has spent his entire career working on individual projects, and doesn't really understand working with a team.

</comment><comment><USER6> > When I'm asked to change my style, I am - quite literally - asked to deny a > fundamental Truth of my being.

Ugh. Come on.

I used to indent with 4 spaces. I lead a team where in the early days I added linting and had to decide one rules. Some of these I felt fine about - semicolons, for instance. But others the team had a fairly unanimous feeling about, 2 spaces being one of them. So I set the linter to 2 spaces, and now that's what I use for everything. I like it.

If we didn't have linting to standardise this and other rules across the codebase, it'd be a mess. It's one thing to be able to identify who's written a thing, but it should be a subtlety in amongst consistency. Not a glaring stylistic mis-match.

[https://github.com/prettier/prettier](https://github.com/prettier/prettier) looks promising, on this topic.

Edit: a rebuttal [https://news.ycombinator.com/item?id=14921580](https://news.ycombinator.com/item?id=14921580)

<comment><USER7> Yes, just a kid crying about having to follow style guidelines. If manually running his team's tool is really wasting as much time as he claims, they should switch to a tooling that automatically corrects style. I use tabs, but the policy is spaces. When I commit a change, my my tabs are automatically controverted to spaces. Zero time lost and no one fights about tabs vs spaces.

<comment><USER8> Just a thought -- it would be neat to see a project that would allow you to check the code out again with your tabs instead of the committed spaces. More of a style translator than an enforcer.

<comment><USER9> It should be relatively easy to set up with git hooks:

Take one of the many Git Hooked Autoformaters: For example: [https://github.com/michalrus/git-hooks-code- autoformat](https://github.com/michalrus/git-hooks-code-autoformat)

Then add similar hooks for pulling on "post-merge" and "post-rewrite". There is no hook for "pull" per se, but either a merge or commit rewrite (rebase) happens after pull that changes code. So you should be good with those both hooks

</comment></comment></comment></comment><comment><USER10> Totally agree with this article. An Emperor-has-no-clothes situation which baffles me that more programmers don't see as obviously as I do is the following sequence of logic:

1\. If the code format check can be automated, then the code format _change_ can be automated.

2\. If the code format _change_ can be automated, then the change could be applied as you type, or as the code is loaded.

3\. If the format change is applied as the file is loaded, it could just as easily be an editor view-setting, much like syntax highlighting or font size.

4\. QED we're collectively wasting time on a lot of pointless B.S. that should just be a checkbox on the Tools... Options menu.

Or to put it another way: the fact that editor background colors, font, and text coloration are not part of plaintext files, but whitespace and line breaks are (and that plaintext files, as opposed to databases, are used to store program code) is an historical accident. One could easily imagine an alternative history in which things played out differently in terms of what is and is not a "view option" vs intrinsic to the source text.

For example, a lot of developers seem to like the white-on-black or "midnight" theme for their IDE; personally, I hate it, and prefer black text on paper- white background. I just thank goodness that that is an editor option, rather than that being encoded by the source file. If it were, maybe we'd have requirements like every source file needs to be on a black background, except for viewmodels which need to use a purple background, etc.

When I'm not forced to use a coding standard, I use line breaks, spacing, etc. to communicate whatever I think is important about a particular section of code, rather than following a prescribed format mechanically. Indeed, breaking style in a particular section can be used to show "hey, something different is happening here".

However, if people are going to get pedantic about style choices _which have no effect on compiler parsing or output_ , I would gladly trade away this freedom of expression in return to gain freedom from code-formatting-busywork by making all of these formatting choices be part of the editor view options. Then if a busybody has an opinion about non-functional source formatting, let him change the settings on his own IDE.

</comment><comment><USER11> Something I think that programmers don't always appreciate is that linting isn't an either/or proposition necessarily. A linter is exactly like the spelling/grammar checker in your word processor. It's there to _advise_ you. It's not always right, and it's often a distraction to what your actual goal is (telling a story, etc).

Common advice among writers is: for the first draft, turn off spelling/grammar checks. Ignore the distraction to focus on the important bits (the plot arc). When it is time to polish, then turn them back on.

I've seen too many teams that don't trust linters and have them entirely off, because they find it too much of a distraction.

I've seen too many teams that get hobbled in the minutiae of linters and mandate that a linter be on 100% of the time, that every last rule of the linter be 100% followed, that linter advisement/warnings should be taken as gospel and break the build.

Absolutely don't use a linter if you don't think it is helping you and you don't like the advice it gives. On the flipside, don't treat a linter as gospel, not just because there are many ways to style something and have it be readable/useful, but also because it distracts sometimes from the actual importance of the work (building working coed), and sometimes the _creativity_ (creative styling used sparingly can enhance the code's readability; just as creative spellings or intentional grammar breaks can be useful in a work of fiction). It's easy to forget that programming is a creative act and that people aren't machines and don't need to follow every rule to a T every time.

I treat linters as a weirdly pedantic code review friend. I tell it to go away if it is bugging me and I'm trying to focus. I take it's advice with a grain of salt, and I use my own human judgment sometimes.

I understand why teams make lint errors build problems, and invite linter checks directly into their PR reviews, but that's not something I care to do in my own projects. Being a slave to a linter dehumanizes the experience of a programmer, and sometimes as programmers we deride the creative chaotic mess that a linter prevents, but that chaotic mess is sometimes art and poetry, too.

</comment><comment><USER12> Linting not only addresses syntax but also addresses a lot of other issues:

\- Unused variables (more often an error than not)

\- Redefining the same variable name twice

\- Having a class method that doesn't use the "this" keyword (usually a logical error)

I think it is worth keeping those kind of rules on even if you turn off ones like how many spaces at the start of the line.

Linting also isn't just for you. It is for the other people on the team so that they don't have to deal with the B.S. of either "fixing" the 50 lines of code you indented with tabs or dealing with multiple styles in the same file.

Although it is a good point that linters could just fix the formatting rather than just complain for a lot of issues.

Although coincidentally when I started using the AirBnB style guide, it corresponded almost identically to the style I was already using so the shock wasn't there.

The author clearly has a hacker "get shit done" kind of mentality and to an extent I love that. But it would drive me nuts if he was on my team.

</comment><comment><USER13> "my approach to code formatting is the best. If it weren't, I wouldn't use it. Formatting is part of my being - an extension of my genetic makeup. And, when I write code, my formatting is the fingerprint that I leave behind. When I'm asked to change my style, I am - quite literally - asked to deny a fundamental Truth of my being."

This is some seriously arrogant, even anti-social (coding) shit. I'm sure his approach is the best. And the next person will say the same. Pretty soon, you're stuck because you can't agree on style and you've wasted all the time debating style. Get an automated formatter and be done with it. Or do it manually in a consistent style. Such arrogant attitudes don't belong anywhere in the professional world. Imagine if people said that about blueprints and CAD drawings. Nothing would ever get built.

</comment><comment><USER14> I disagree that there's no positive effect. A difference in code styles can introduce cognitive load, though naturally the actual effect will depend on the individuals involved, and the actual differences (for some, I agree it could be a non-issue).

> Hopefully, you feel as passionately as I do about your own stylistic > choices. My approach works best for me; but, it's not for everyone. And, > clearly, other people's choices don't thrill me. It's a completely > subjective matter.

I do not. I do have preferences, but I'll let them go quickly in favour of following a standard convention for a given project. I care more about consistency than my own subjective opinions on code style.

I would agree that manual code style checking is painful. I've previously used jslint, eslint, tslint, etc. and I always forgot to run it locally, and then get frustrated when it inevitably failed during CI. There's tooling to address that (syntax highlighting in editors, git hooks, etc.) but it doesn't completely alleviate the problem.

Personally, I quickly adapted and the initial friction of adjusting my workflow (and co-workers theirs) meant a more consistent code base. I was pretty happy with that.

Lately, I've been using Prettier.js that runs on save, and frankly I think it's fantastic. I don't always agree with the specific format it's chosen, and there's at least a few things it doesn't handle (e.g. superfluous new lines), but for the most part I no longer need to think about what my code looks like (stylistically, anyway).

A lot less cognitive load, more consistent code base.

</comment><comment><USER15> You are lucky that you work with talented and engaged people. I had to bring in a linter at my new job because my coworkers were incredibly lazy about their code. No indenting at all, or the indenting is all mixed up and they didn't care to fix it. They would commit completely broken javascript without testing it.

I stand by linting for development teams that don't have the luxury of good talent.

</comment><comment><USER16> Fundamentally, the big problem is, most engineers don't understand opportunity cost. So, whenever a new review tool comes along, we always say: yes! let's do that because only good things can come from it. And, that's simply not true. You always need to evaluate the benefits vs the cost - the cost being your time. Spending all day, replacing quotation marks and other arbitrary coding style won't help much.

You gotta remember, coding quality is not something you increase just for it's own sake. the whole purpose of increasing code quality, is to increase future productivity. Any process or decision you add to your coding process, should reflect positively on those goals.

</comment><comment><USER17> Bind prettier ([https://github.com/prettier/prettier](https://github.com/prettier/prettier)) to run on your editor/IDE "Reformat code" shortcut. Follow the github page to add the automatic git pre-commit hook. Add eslint-config-prettier if desired. Done. No more bikeshedding.

You'll be in good company, with React, Babel, Yarn, Webpack etc.

And just use const by default. Let/var is a warning sign that side effects are happening, like a traffic warning to slow down and stay alert.

</comment><comment><USER18> Suck it up. Either set your IDE to conform to the house style whatever that may be, or deal with the drubbing in code reviews and, by extension, negative marks on your performance evaluation.

</comment><comment><USER19> ... but there's a semantic difference between `const` and `let`...

The least interesting component of style is syntax and form. Therefore use tooling to eliminate such concerns from your code. Javascript is a syntactic mess with ASI, braces, indentation. Linters remove such concerns.

The important components of style are preference to _declarative_ vs. _imperative_ code, heavy use of `class`, the `prototype` chain, or preferring function composition and purity. These are the concerns your style guide should be focused on.

Javascript, like C++, is what I call a _kitchen sink language_. If you use all of it your code will be a frightening mess to maintain. Choose to use a subset of the features and stick to it.

</comment><comment><USER20> > I am talking solely about stylistic rules. Tabs vs. Spaces. Const vs. Let. > Single quotes vs. Double quotes - that sort of thing

let vs const is not stylistic - they mean different things and V8 can optimize for them differently.

</comment><comment><USER21> JS linters catch sources of bugs. That's a gain.

A standard style makes code easier to read across a codebase. This makes the code easier to understand and easier to find bugs in.

So no.

</comment><comment><USER22> 100% agree with this. I relax a lot of the rules for my personal projects. I want linting to tell me when there is a potential problem. Other than that it just slows me down.

If a computer can lint it, it can also beautify it. Leave me alone and take care of it for me automatically.

Stop wasting my time and breaking builds because I forgot a comma after the last key in an object and dumb stuff like that.

</comment><comment><USER23> > there's no real value in [linting]. Because, the choices that can be > controlled by a linter are, ultimately, not the choices that matter.

Interesting. He says there is no value in linting and then follows it up with the main value of linting. You're right, they aren't the choices that matter. That's why I don't want to waste time thinking about them.

</comment><comment><USER24> We're using prettier on a project at work. I was reluctant, I thought that there would be lots of bugs and mangled code, but it has been wonderful.

We run eslint with the fix option and prettier all in one command. It even formats JSON that you paste in for a test and changes the quotes to your preferred quote.

A+

<comment><USER25> I introduced Prettier at work because I got rather sick of seeing poorly formatted code strewn about.. it is indeed wonderful. I don't want me or my coworkers to have the freedom to write weirdly formatted or bad looking code - reading and understanding other people's code is hard enough even if it's perfectly formatted.

More importantly, Prettier + ESLint fix on save makes coding quicker! I don't have to waste time getting things lined up any more.. I just write write write awful looking code and on save.. boom! it looks nice.

You're not writing a novel, you're not painting a picture.. you're writing code that _I'm_ going to have to read, understand, and modify at some point. Having a consistent style and enforced line lengths makes my job easier. Don't make my job harder just because you want some extra freedom to make your code look weird.

I have no idea what this author is going on about.

</comment></comment><comment><USER26> The value linters should (hopefully) provide is to keep code reviews focussed on actually important things instead of having to renegotiate naming, spacing, and other "arbitrary" things. Also, a decent linter for JavaScript will detect some obviously buggy code.

</comment><comment><USER27> I've never disagreed with a title of HN subject stronger in my life.

</comment><comment><USER28> Yes. This so correct.

Linting efficacy is one of the many myths about software quality and team efficiency that abound in this industry.

</comment><comment><USER29> Go fmt

<comment><USER30> And clang-format for c/c++/java/js/typescript. Tools like these are fast enough to be hooked to version control commits, and even on save

</comment></comment><comment><USER31> > Hopefully, you feel as passionately as I do about your own stylistic > choices.

Nooooo. No. Hopefully the exact opposite. The correct feeling about this is, let's pick a style and move on. Ideally there's a tool that just formats the code according to the style so coders don't even have to do it.

Arguing about style details is absolutely one of the least productive possible things a programming team could do. It's aggravating and pointless. Getting upset that your pet style rule isn't in the official style is egotistical and childish. Code that way on your GitHub when you're not working, if it's so important to you.

This is one thing Go got right.

<comment><USER32> Note how he explicitly recognizes how everybody has their own best style. Nowhere does he encourage arguing about style details.

<comment><USER31> I just think it's silly. It's a silly thing to get attached to or care about. The code just needs to be legible and consistent.

<comment><USER8> Consistent is a big one.

Imagine every time you reach for a module in your codebase you have to remember that Joe came from C# so he likes to use PascalCase for his methods instead of camelCase like the majority of JS libraries. And John likes Snake_case for his classes because he came from PHP and that seems more natural to him.

I've been in that environment. It will make you tear your hair out in a week.

<comment><USER31> (Just don't mention PHP has this in spades, people hate when you point that out.)

</comment></comment></comment></comment></comment><comment><USER33> > Three months ago, I joined an internal team that uses the JavaScript linting > library, Standard.js.

My life got so much better when I started avoiding taking jobs with people who make bad decisions.

Using Standard.js is a huge red-flag for me. If you think leaving semi-colons out of Javascript is a good idea then I can only deduce that you value style over functionality and complexity over simplicity.

<comment><USER34> Thank you. I still have this argument with people today. I think it's laziness for many devs. ASI is an _error correction mechanism_ that Eich added because there was no compile step in JS in 1995. It helped people ship code without having to spend forever tracking down missed semicolons or worry about getting bit by one in an undertested code path. It is part of the language. If you hate semicolons that much, go write VB/Ruby/Python...</comment></comment>


Your Company Wants to Know If You've Lost Weight - <AUTHOR> https://www.wsj.com/articles/does-your-company-need-to-know-your-body-mass-index-11549902536 <comment><USER2> Paywall workaround: [https://outline.com/xw2jV9](https://outline.com/xw2jV9)</comment>