You Don't Need All That Complex/Expensive/Distracting Infrastructure - <AUTHOR> https://medium.com/@dmfutcher/you-dont-need-all-that-complex-expensive-distracting-infrastructure-a70dbe0dbccb <comment><USER2> Good old KISS policy.

Sure, Kubernetes, fully automated CI/CD, autoscaling, lambda functions are all cool and very useful if you have a problem and paying users in that scale.

Majority of the applications even today in 2019 would be served well by the reliable Nginx + (Python, C++, Rust, Go or other language of choice), PostgreSQL and backups. If you keep things simple, you can even have a standby mirror of the same infrastructure to take over if needed, and it would still cost you less than spinning up nodes after nodes for the complexity of running your own Kubernetes.

<comment><USER3> Or just set up Elastic Beanstalk with AWS or something similar, hand it a zip file of your code and let AWS configure your load balancer, autoscaling, patching your OS and runtime, managing your database and backups, etc.

<comment><USER2> What you suggest may be "simple" in terms of the amount of work the user needs to do, but my comment is about reduced complexity and $$ because you don't need them yet.

When you set up such an infrastructure like you proposed, there are still too many wheels in motion(complexity), and even worse they are abstracted away from you further and further. And, I'm sure the AWS bill is not going to be pretty considering they do all those bells and whistles.

<comment><USER3> You literally click a few buttons and it sets up all of the infrastructure. Then you give it a zip file. The EC2 instance that it creates is a regular VM.

Elastic Beanstalk itself is free.

<comment><USER2> It is true that Elastic Beanstalk is free, and is very easy for a developer to use to begin with. However, If I were to advice a new startup on their infrastructure, I would not recommend it for the following reasons. It is my personal judgement. Others may prefer to go all in on Amazon.

1\. It is clearly a vendor lock in. You build your business upon all AWS services, using an AWS orchestrator - good luck ever getting out.

2\. Abstraction. It is a controversial opinion. I'd rather have less magic when possible and know what goes on underneath, and possibly have control over. Now, a startup may choose to offload the duties of operating a database(RDS), storing files(S3), performing backups(S3/Glacier) in the interest of time and trade-off control, optimisation and $$. However, considering the generalisation of simpler startups, IMHO operating a small scale Postgres on a standard EC2 instance is not really much of a hassle...

3\. Cost - however small it may be in terms of actual dollars, AWS managed services(S3, RDS, SES, SQS etc..) come with added cost over simply running their open source equivalent yourselves.

Again, Keeping it simple - not in terms of what the user needs to do to deploy their application, but in terms of what components do you need to get your application running in production.

<comment><USER3> _1\. It is clearly a vendor lock in. You build your business upon all AWS services, using an AWS orchestrator - good luck ever getting out._

If you are starting a business, the least of your business risks is lock in to AWS.

Besides that, you're handing a regular old zip file with your code to Elastic Beanstalk, it creates a VM with the standard web server package installed depending on your language. If later on, you need to go to another environment (and in the grand scheme of things, few companies ever switch out their infrastructure no matter how many Repository classes they write to abstract their database), you create your same webserver set up in the new environment.

Every cloud vendor has a hand-me-your-code-in-a-zip-file-and-I-setup- everything-for-you service.

 _However, considering the generalisation of simpler startups, IMHO operating a small scale Postgres on a standard EC2 instance is not really much of a hassle..._

Why would I want to manage my own Postgres database and worry about backups, patching, etc. when I can pay someone else to do it?

 _Cost - however small it may be in terms of actual dollars, AWS managed services(S3, RDS, SES, SQS etc..) come with added cost over simply running their open source equivalent yourselves._

And that's more for your developers to manage, I'm sure if you can find some gullible young developers to work 60+ hours per week pulling double duty as developers and infrastructure operators it will be cheaper. I for one am not willing to do that. Every hour that your developers are spending maintaining infrastructure and doing the "undifferentiated heavy lifting" they are spending time not creating features adding business value.

You're talking about adding more servers (and no redundancy) to save a few pennies. I would avoid any company managed like that like the plague.

I actually have walked away from offers where the company was "on AWS" but all they were doing was running a bunch of EC2 instances and hosting everything themselves and expected their developers to be on call for infrastructure failures.

On the other hand, I did take a job where the new manager's marching orders were to move as far away from managing any infrastructure that could be done by AWS. We have to have a serious justification to put anything new on EC2 instances instead of using Lambda or Fargate.

<comment><USER4> > If you are starting a business, the least of your business risks is lock in > to AWS.

You are locking yourself into a cloud provider that is a part of a really hostile country in terms of digital privacy. Your customers may not care right now, but they really _should_. If you can sell that kind of behaviour to yourself because you're "starting", then your customers deserve the kind of business they are getting from you. To me it sounds incredibly unethical.

<comment><USER3> So which provider should a US based start up use? If they use a colo which country do you think it's going to be in?

Seeing that all of the most valuable tech companies in the world besides the ones in China are based in the US, do you suggest they host with Alibaba Cloud?

<comment><USER4> There is more to the world than the US and China (both of which are terrible choices). Outside of those places there are also cloud providers that give good service at a reasonable price.

<comment><USER3> Where would that be where there is a better startup scene than the US?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> >Your users to don't care how your code gets onto your server.

I don't like arguments like this. This is true for any number of tasks that a layman wouldn't care to understand. You still will do them anyway, regardless of whether or not your user cares. It doesn't take a lot of experience to see the correlation between poor engineering practices and poor user experience.

Now, I don't think the author was using this argument to pitch poor engineering, but there are good reasons for setting up resilient and consistent build deploys, as he addresses. I think the only real takeaway is "dont over-engineer your infrastructure" which is just an extension of generally "don't over-engineer."

Every time infrastructure gets talked about on HN the conversation gets so sidetracked. The real problem is that people don't think about infrastructure in the context of a holistic view of a project. The hours you spend setting up your project with resilient and consistent CI builds are many times more valuable down the road.

I think people need to not be so afraid of spending time on infrastructure. People already err on the side of spending less than more time on infrastructure. I don't think it's wrong at all that the author spent _hours_ building an automatic build process for his project, especially because now that he's set it up he can refer to it in the future. Maybe with his newfound knowledge and experience on the problem means that he can leverage it with little effort in the future. None of this is a bad thing especially if you think about your engineering career on a macro scale instead of week to week.

<comment><USER6> I agree that CI is a brilliant investment. Also it can initially be as simple as a git hook. However, I agree with the author's point that you do not need a Kubernetes distributed NoSQL megagalaxy when you have a number of customers which you can count on one hand. I've seen so much time wasted on this sort of thing.

One obvious benefit of the whole single/simple server idea is that you can make changes to the system so quickly and easily, which is very important at the beginning.

<comment><USER7> Ya nosql can be useful at scale, but it's not a great choice for most new projects. It really locks you into your schema and makes querying the data at scale difficult outside of use cases you originally designed for. I've seen aws architects recommending just starting with sql, and adding nosql later as needed. Definitely agree with this approach for most use cases.

</comment></comment></comment><comment><USER8> There's an obvious and overlooked middle ground between "massively complicated infrastructure" and "a cheap VPS" \- charge more and use PaaS. Heroku and Engine Yard are expensive, but they deliver a huge amount of value. You've got better things to do than patch Nginx or deal with a crashed server at 4am, just pay someone a sensible amount of money to run your infrastructure for you.

<comment><USER9> I agree. There are also options to make some of the things from the article relatively easy. Off the top of my head, a CI/CD pipeline can be set up using Gitlab , Azure DevOps, Bitbucket Pipelines, and I'm sure tons of others. They do some of the heavy lifting and you still get the benefit of an organized build that's easy to deploy to one of the services listed above.

And yeah, this may be layered on later when it seems like the idea has legs and you'd benefit from this. It most likely doesn't need to be the first step.

</comment></comment><comment><USER10> While I think you can definitely get too fancy with all of that sweet infra, I feel this is missing an important point:

Once you have a working pipeline in place, you can focus on the features, that's the whole point of the exercise: enabling developers to ship features for users. If I have to SSH into some machine and restart a set of services manually in the correct order, it will keep me from releasing features. I am afraid / lazy / whatever. Spending time on this is not something that will never ever reach the user in any way.

The user does not care if something is using Heroku, K8s, or something else, yes, but the user definitely appreciates a product that can reliably iterate on things without major downtime or similar problems.

It's kind of like saying, "well unit tests are nice and stuff, but does the user ever notice?". I would strongly argue the user will notice unit tests in the long run as they ensure the software keeps being maintainable.

<comment><USER11> > Once you have a working pipeline in place, you can focus on the features

Bullshit, its just another layer of complexity to be managed and that may fail. My guess is that it will take more time maintaining it than it will save you in the majority of cases.

<comment><USER10> > My guess is that it will take more time maintaining it than it will save you > in the majority of cases.

From my experience, this has almost never been the case. Exceptions were when there was infrastructure for the sake of infrastructure.

<comment><USER12> If a leader is worried about their organization having infra for the sake of infra, then they should also worry that their user-facing product has features for the sake of features—- features that complicate an interface and don't help a user get their job done. The solution is PMs, UX designers, and engineers who know to ask "why?" when a project is proposed.

<comment><USER7> That's a good point. Many things can be overengineered/overdone, including UX design.

</comment></comment></comment></comment></comment><comment><USER13> I saw so many places falling for this fallacy.

Instead on working on the core products, engineers would have "fun" adding more microservices, redundant Kubernetes clusters, istio controllers etc etc. (all of that with less than 10 users).

<comment><USER14> I had an argument with a co-worker about this. He wanted to use Kubernetes, so I asked him what problem he was trying to solve. No answer- just wanted to because he could put it on his resume.

You deploy tech to solve a problem. Don't go solving problems that you don't have yet.

<comment><USER15> That, actually, is a bigger problem. Some people are using things not for the benefit of the thing they're building, but for their own (AKA resumes).

</comment></comment></comment><comment><USER16> Please at least use a managed database. Treat that linode box like it might disappear at any moment. It is so easy to shoot yourself in the foot with a database and lose everything.

Also FWIW configuring Linux machines manually over SSH and building and deploying your code too it, isn't always easier. Make sure you write everything you did down, because in 6 months you will completely forget how you built this thing, where it was deployed, etc...

<comment><USER17> And whatever you choose, TEST YOUR BACKUPS. Spin up a new instance and practice recovery. This needs to be done at least quarterly, both to test your backups and train yourself and/or your people in this process.

</comment></comment><comment><USER18> I agree with the author : start simple, then use more complex tools when and if you need to.

I believe it is true about infrastructure, and about features and code as well.

When my team needs to release a functionality for the "product"[1] that we maintain, we have a very simple strategy : we go step by step. The users tell us what they need, and we start to deliver as soon as we can. Our first release only solves a portion of the user's problem, but the second release solves more, and so does the next, and so on. I devised this strategy with the users to make sure they are fine with it: they expect a perfect product... eventually. But in the mean time, they having only some portions of their needs met, and we avoid the feeling of being overwhelmed by a great apparent complexity.

[1] The context is a bit complicated... and irrelevant. We don't exactly maintain a product, but it's close enough for the argument here.

<comment><USER18> Oops! Sorry for the huge typo in my comment. "they having only some portions of their needs met" should be read "they are fine with having only some portions of their needs met".

(It is a bit more than a typo)

</comment></comment><comment><USER19> > 'Engineers get sidetracked by things that make engineers excited, not that > solve real problems for users'

The real question is why business allows them to. I find it entertaining to try to substitute another profession for engineer in the sentence above and see if it still works. Lawyers, teachers, doctors, civil architects...

<comment><USER20> The precious commodity with our work is cognitive load. We can build tooling that reduces future cognitive load. As a result, we have access to multipliers. There is no analogy to this with the other fields.

<comment><USER21> The idea that tooling "reduces" cognitive load is based on the assumption that tooling lets you work in terms of abstractions rather than worrying about what the tooling actually does. This assumption breaks down as soon as the tooling itself breaks down. At that point, not only do you have to worry about the underlying problems that the tooling is intended to solve, but you also have to worry about the implementation details of the tooling itself.

Tooling breaks down more often when it's more complicated, and you need more complexity when your tooling abstracts over a large amount of complexity, so the more that your tooling is supposed to _reduce_ your cognitive load, the more likely it will break in such a way that it actually _increases_ your cognitive load.

</comment></comment></comment><comment><USER22> I run a small team, but we do a large number of projects. Each project is developed fast and then maintained at low intensity for a long time. Have found great use for a nifty complex DevOps pipeline.

Before, when I built the same app for two years, the nifty pipeline was overwrought.

I think the context switching inherent in what I do now makes the nifty pipeline useful.

</comment><comment><USER7> > Kubernetes clusters? Load balancers across multiple cloud regions? Zero- > click, Blue-Green deployment based on real-time metrics from a continuous > deployment pipeline?

Kubernetes, multi region, canary deployment, immutable infrastructure, even infrastructure as code is overengineering for a brand new indie project, for sure.

BUT, there is a certain minimum amount of quality, availability and scalability any product needs, especially a new product that might show up on hacker news or product hunt and get 100-300 concurrent requests a second for multiple hours at unpredictable times.

To not use fargate because you have to dockerize your app and build it during a codepipeline stage is silly. That takes what, a week, max, the first time you ever do it? Once you've done it, you can do it faster for future products. To not use an autoscaling and high availability database when it costs the same and is so simple to set up makes no sense either. To not use ci/cd to test your db migrations and new code on staging before pushing to prod is just dumb and asking for pain and suffering. Why put yourself through that when products have been built to make these things _so_ easy and inexpensive now?

</comment><comment><USER23> Right on! I am enjoying the book "A Company of One" right now and the author makes the same point of only doing what it takes to provide great service to a few customers. Another point is to spend more effort servicing existing customers than spending time trying to get new customers.

For deployment: if you can tolerate rare service downtimes then it is difficult to beat Linode or Digital Ocean. I am probably in a minority, but I also really like GCP's AppEngine: turn on billing, set the minimum instance count to one and the maximum to two or three, and you have a resilient system. That said, I run my primary web site on a single tiny GCP VPS instance with no fault tolerance.

For heavier compute requirements, I also really like a physical server from Hetzner- for about $100/month you can get a GPU, i7, and lots of RAM and bandwidth.

<comment><USER24> Thanks for the "A Company of One" book recommendation. I just ordered it.

</comment></comment><comment><USER25> You don't need it if you are a one-man band doing a small side project.

> _I spent hours setting up a simple and free continuous deployment pipeline. > Commit to git, Semaphore CI builds the Docker image, uploads the image to a > container registry, then pulls & restarts the container on my server. It's > really cool. I felt like a wizard once I got it working … and it was free! I > actually sat down here to write all about how to do it yourself, until I > realised how long I spent on it and how much value it delivered to my users_

If you have a team of some size, the time you gain over the lifecycle of the project can be very significant when you have a smoothly running automated dev/test/UA/live pipeline.

> _Not build the fanciest deployment pipelines, or multi-zone, multi-region, > multi-cloud Nuclear Winter proof high availability setup._

If your downtime can be measured in appreciable lost revenue or reputational cost, then yes, you need all of that, as well as a solid SRE or 5 to keep it all running.

<comment><USER26> > _Obviously if you're FAANG-level or some established site where that 0.1% > downtime translates into vast quantities of cash disappearing from your > books, this stuff is all great. You have the funds to do things "right"._

<comment><USER3> You don't have to be a FAANG. You can be a B2B startup with one or two major clients who if they see you aren't highly available will jump ship taking a lot of your revenue with them.

I've been in enough meetings working for small startups where our clients grilled us about our resiliency, availability, redundancy etc. and where they forced us to put our code in escrow as part of our contract.

</comment></comment></comment><comment><USER27> Usually,. the thing that you lose is scalability, availability any reliability.

You will need a remote backup and a secondary located service, just in case. Potentially a third development one to not push breaking changes directly into production.

Skipping any of this will make your service brittle in addition to not being scalable.

And it already hits the rule of three... (of "don't repeat yourself") that makes a lightweight Kubernetes deployment worthwhile. (Perhaps without all the bells and whistles.)

Remember, downtime is usually lost money. A day's worth can be thousands of dollars at least, and that's two nines already. (99.99%)

<comment><USER28> Or, you ship 2 months earlier, and the trade off being suffering a day's worth of downtime.

It makes no sense to start with a more complicated setup, until there is clear evidence of a need.

<comment><USER27> The main problem is that usually low quality infra bites you when you get exposure. Which is exactly when you don't want it to fail...

For a start, Heroku or AWS instance will do and they scale. (As the other commenter said)

If you're doing your own infra, you need at least basic fallbacks and safety.

</comment></comment></comment><comment> q-base I see this "Push for new and shiny solutions"[1] across everything from startups to large corporations. And I am genuinely surprised at how often I see people falling for this good old trap of over-optimization/engineering. I genuinely cannot fathom why people want the complexity.

It is by no means constrained to infrastructure, it is architecture, technology, management the whole lot.

[1][http://jesperreiche.com/the-push-for-new-and-shiny- solutions...](http://jesperreiche.com/the-push-for-new-and-shiny-solutions-to- old-known-problems/)

</comment><comment><USER29> It depends on who your customer is. If your customer is the investor, then there is no limit to the amount of hardware, infrastructure, and experts sitting behind a desk and multiple monitors in every concevable separation of concern you can think of in every major city across the globe. Your product is amazing, and its going to change the world and how people percieve things. You need everything you can throw at it. Investors want to be the best. And thats if you customer is the investor.

</comment><comment><USER30> One of my web sites is run by a "bundle exec rails s" in a tmux window on an EC2 instance. New deploy? Run "git pull" (and maybe "rake db:migrate") in tmux pane and restart the "rails s" command. Easy peasy.

I'd make it more complicated and resilient but why?

</comment><comment><USER31> The problem with Kubernetes (and microservices in general) is getting a team productive with it, and that requires lots of time, dedication, and tooling. It's not the right solution for most teams, but it could be if we streamline it more

</comment><comment><USER32> When you are building a startup, there is always the question, "will this scale?" or "in the event of an investment or going viral are we ready to scale automatically ?"

I think that there is a lot of worries around this, it conditions technology choices, sometimes pushing early optimisations, and it is hard because you don't have the data on how many concurrent users your product will have. The best you can do is to extrapolate from you current data or other products data.

So many people end up following a recipe, it could be Firebase recipe, AWS Fargate, Serverless... you name it. Recipes that promise limitless autoscale.

I think indeed is distracting and premature, but again is hard to avoid it, if the premise is that there will be a massive growth overnight, which is imposible to predict that will potentially kill us, and we have to be ready.

<comment><USER33> I've wasted a lot of time during my attempts as a solo developer to build a product with a scalable backend architecture for the hordes of users that never materialize.

Next idea I have, I swear I'm going to throw all my effort into the frontend and go with as minimal a backend as I can get away with (heck, depending on the application, human-in-the-loop might be fine early on) until I get some validation. It'll feel "wrong", but whatever.

</comment></comment><comment><USER34> This is a pretty dumb article.

Like, no shit don't build more infrastructure than you need. If you're a one or two man team you don't need anything more complicated than 'push container here, pull down here' or 'push code here' et. al. Once you get above that having a repeatable process (repeatable by someone besides the person who built it) becomes valuable.

The 'every second spent on infrastructure isn't spent on features' line makes me think I'm going to have to blackmail into working on security updates or paying down technical debt. And the picture you picked is cheeky.

I will agree with this statement, "You need the most simple, least time consuming infrastructure that gets you to that point." But that WILL become more than just 'throw it on a linode instance' after you get some customers and more than 2 people working on whatever uber for dogs project you have going on.</comment>


The New Economics of Summer Camp - <AUTHOR> http://www.nytimes.com/2011/07/10/business/summer-camps-are-facing-new-economics.html?hpw

<comment><USER2> $9700 * 900 kids is over $8 million.

Salaries are $1 million (for 500 people? most must be part time volunteers or getting paid minimum wage for those 2 months).

Food costs are $500k

Maintenance of $700k.

Even rounding those up, that's $3mil. There's $5mil per year left for the capital investment stuff they need to do. I'm assuming they're paying off earlier purchases. Certainly there's a lot of marketing they need to do well in advance of the next summer, but it really seems like a pretty good profit for 2 months of service.

<comment><USER3> Insurance is expensive as well!

<comment><USER2> Good point. I can't imagine is $3-$4 million though. But I might be wrong.

</comment></comment></comment><comment><USER4> I love the quote from Michael Eisner: ""Nobody fails summer camp, a nice respite from winters of fortune and misfortune at school."

Hopefully parents can get over their obsessive drive to make kids "achieve" something every time they leave the house, and just let camp be camp.

No smartphones, no video games, just kids in the woods getting up to some trouble and fun.

</comment><comment><USER5> That's some very good press. It should give them a nice boost for the rest of the year.</comment>


AT&T/T-mobile Merger, submit your comments to the FCC, proceeding number 11-65 - <AUTHOR> http://fjallfoss.fcc.gov/ecfs/hotdocket/list

<comment><USER2> Just added my comments.</comment>


Japan Now Has More Electric Car Charging Spots Than Gas Stations - <AUTHOR> https://transportevolved.com/2015/02/17/official-japan-now-electric-car-charging-spots-gas-stations/ <comment><USER2> Unlike the majority of gas stations in Japan however, the 40,000 electric car charging points quoted by Nissan includes ones in private homes, causing some critics to cry foul. After all, if a charging station is hidden in a privately-owned garage, it isn't easily accessible to the public. Yet while we understand that criticism — and it's why we used an asterisk in our headline — the rise of charger-sharing sites like PlugShare.com means that more people than ever before are offering their private charging station for others to use, either as an altruistic gesture or for cold, hard cash. Moreover, it's possible to argue that because privately-owned charging stations are enabling owners to drive their cars without visiting public charging stations, they're providing just as valid a service to everyday drivers as publicly-assessable, higher-powered ones. But while electric car charging stations may now be far more common in Japan than a gas station, the numbers of electric cars on the roads of Japan still represent a tiny proportion of the total cars registered. It includes public and private charging spots but the article does raise some good points about 'charge spot pooling' and reducing the dependency on petrol stations. Interesting times ahead!

<comment><USER3> I'd like to read exactly what those critics say because I'm curious to see if they are accounting for the difference in driving culture between the US and Japan. Specifically, in Japan:

1\. Owning a car in Japan is no where near as simple as in the US. One of the requirements that makes the private charging stations criticism sound ignorant is that you must have a legal verified parking spot to own a car. So the majority of people who own electric cars will only need to use a charging station when they are away from home for longer than a single charge. This is probably not applicable in most daily use.

2\. Charging stations can be left unattended for 24 hour use. That's a huge plus as electric cars start spreading. Why? Because in Japan, many gas stations close and are unavailable during most night hours. Finding 24 hour stations (usually self pump ones) after 7-8pm can be difficult in some areas. So the gap between accessible fill-up/charge-up spots isn't as big as most Americans are imagining. Of course a gap exists, but that will only close over time. (edit: people also are much more conscious about having a full tank before departing on long trips. It's just one of those things you have to think about when driving in Japan.)

3\. Last is the daiko/taxi system in Japan. Read about the 0% alcohol tolerance system and how this car service system works to make people's lives easier here. Heck, you can't even ride your bike while drunk in Japan. The way people approach transportation here is just different.

The driving culture in Japan is very different and it's hard to take that criticism seriously unless some hard numbers and studies are done to take into account the massive difference in driving culture.

<comment><USER4> _> Heck, you can't even ride your bike while drunk in Japan._

That is true in many places officially, though a blind eye is often turned.

In the UK (my location) this is covered by section 30 or the Road Traffic Act (1988): "It is an offence for a person to ride a cycle on a road or other public place when unfit to ride through drink or drugs".

You can't be breathalysed (well, you can but you can't be forced to, if they ask you can decline unlike when in a car or other such vehicle) or be made to give other samples (though as with breath, if they ask and you volunteer the sample _can_ be used as evidence), but other tests _can_ be demanded (i.e. the standard finger-to-nose, straight-line, and alphabet physical & mental coordination tests). It'll not affect your driving license if you have one but there are potentially significant fines.

<comment><USER5> [That is true in many places officially, though a blind eye is often turned.]

This is kind of off topic, but there are some places in the USA where you can get a DUI for riding a dirt bike in your own back yard (while drunk).

Since DUI laws often even extend down to roller skates, one could extrapolate that you could technically get a DUI for roller skating drunk around your kitchen.

Of course, no sensible judge would let that fly (I hope).

The problem in this case is that many of the DUI laws don't distinguish between private and public property.

<comment> squeaky-clean > This is kind of off topic, but there are some places in the USA where you > can get a DUI for riding a dirt bike in your own back yard (while drunk).

In what situation could this happen though? I feel like other laws would prohibit this from happening. A police officer can't enter your property without a warrant or probable cause. So unless you're visible in your backyard, and very noticeably intoxicated, how could they tell you're not just clumsy and practicing?

But if you end up driving through your neighbor's fence, or run over a guest/family member in your own backyard, I don't think a DUI is unreasonable. Or if you drive into your own home, tree, whatever, and try to contact insurance for damages, it also makes sense to consider that you were intoxicated.

<comment><USER6> I suspect people also tend to get busted for this sort of thing when the cops get called for some other (possibly related) reason, e.g. you're doing drunken donuts on your property and the neighbor calls the police because you're disturbing her with loud music.

In most places the cops would probably tell you yes, indeed, you can get a DUI for driving drunk on your own property, so turn off the radio, go inside, and we'll call it even.

When you're dumb enough to start mouthing off at that point, _that 's_ when you get the DUI.

</comment></comment></comment></comment></comment></comment><comment><USER7> Here's the interactive map.[1] Most of those charging stations are not public. Hotels and auto dealerships have some of them. I've been looking for them in Google Maps. Here's one that's in a public parking lot and has signage.[2] You have to pay for parking to charge, but that's not unreasonable in Tokyo.

[1] [http://www.chademo.com/wp/jpmap/](http://www.chademo.com/wp/jpmap/) [2] [https://goo.gl/maps/M5WYLuM4uEK2](https://goo.gl/maps/M5WYLuM4uEK2)

</comment><comment><USER8> This is hardly surprising. Or terribly newsworthy. Just reinforces how early we still are in the adoption of electric vehicles.

The amount of gas stations available has plummeted in most places over the last 20 years. I presume Japan is similar. It's been equally down to supermarkets getting into petrol supply and the oil companies introducing large weekly mininimums. UK probably has 1/2 or 1/3 the number of petrol stations compared to y2k. It's ruined the convenience of filling up and tiny 1 and 2 pump stations are consigned to history. Live somewhere rural? Now you can drive 20 miles just to fill up.

Meanwhile charging points are being put in everywhere - towns are making charging bays in car parks, or on street. Much like happened with petrol in the 1920s.

Oh, and let's not forget a charging point caters for a lot fewer vehicles than a petrol station.

<comment><USER9> Gas stations are incredibly damaging to the environment, and the land is very expensive to remediate if ever used for something else. That's why they have been disappearing.

<comment><USER10> As soon as EVs take off and gas stations start closing up shop, I'm going into petrol station remediation. There's gold in them there hills!

<comment><USER11> Oil, not gold ;+)

</comment></comment></comment></comment><comment><USER12> It is a strange experience to be jealous of countries with high population density. However, every time bicycles, electric vehicles, or renewable energy comes up, I feel profoundly embarrassed the US can't form a similar effort given our resources, even if I rationally understand it's probably not worth it to have a high speed train hit all the small towns in Montana, or how solar panels might not work as well in Forks, Washington as they do in California.

<comment><USER13> While I too agree that high speed rail (and even Internet) in absolutely rural areas doesn't really make sense...

The US still has areas of fairly to -really- high population density, and arguably, areas that should be far higher (city cores with skyscrapers, and city outskirts with 6-8 story high multi-use buildings), even the current suburban density is more than dense enough to support better transit experiences than we presently see.

Transit of both the mass people and the mass-data kind.

<comment><USER14> > While I too agree that high speed rail (and even Internet) in absolutely > rural areas doesn't really make sense...

Yeah, it's not like rural areas have power or phone service. /s

Seriously, what makes high speed internet so special that rural areas should _not_ have it?

It's not like we don't know how to build networks and we've already built the power and telephone networks. Internet access is getting to be as important as phone service and power and it's undeniable that from a societal perspective everyone would benefit from having equal access to internet services.

<comment><USER15> > Seriously, what makes high speed internet so special that rural areas should > not have it?

Internet is not considered a utility in the same way that power and phone lines are. If this is the change you are suggesting, the ongoing debates about net neutrality, as well as rather confusing bandwidth monetization by telecom companies, are big issues in the way of commoditizing the Internet.

<comment><USER14> > Internet is not considered a utility in the same way that power and phone > lines are.

I would not mind that the Internet be classified as a utility. Regardless of if it is or not, a co-ordinated effort should be made to bring high speed broadband access to all, including rural areas.

What I do take exception to is claims that bringing high speed Internet access to rural areas does not make sense or should not be done.

> If this is the change you are suggesting, the ongoing debates about net > neutrality, as well as rather confusing bandwidth monetization by telecom > companies, are big issues in the way of commoditizing the Internet.

Excuse my ignorance, but how does network neutrality stand in the way of commoditizing the Internet?

I'm much more inclined to say that mandating network neutrality, open access, transparent pricing and verifiable metering and billing would go a long way to solve any problems.

<comment><USER15> > I would not mind that the Internet be classified as a utility. Regardless of > if it is or not, a co-ordinated effort should be made to bring high speed > broadband access to all, including rural areas.

I mean, legally, they are public utilities. From my limited understanding, the utility companies MUST provide for either everyone in an area or no one, for example, amongst other regulations. This is not true for internet access, not in most places.

> Excuse my ignorance, but how does network neutrality stand in the way of > commoditizing the Internet?

If people are able to "pay" for better, faster internet access, how can we regulate it as a public utility for everyone? One might argue that it seems "unfair" (for certain definitions).

This is related to internet billing: Do we bill the downloader? The uploader? How do we measure it? How do we verify the measurement? What if someone MITM injects packets?

We need to make decisions and figure things out in order to get internet to the level of, say, electricity.

<comment><USER14> > If people are able to "pay" for better, faster internet access, how can we > regulate it as a public utility for everyone? One might argue that it seems > "unfair" (for certain definitions).

I fail to see how this has anything to do with network neutrality. You pay for your internet connection, I pay for mine. There's nothing unfair about me having a 100M connection and you having a 1G connection.

Network neutrality only bans preferential treatment of service providers, it has nothing to do with who has what kind of connection.

> This is related to internet billing: Do we bill the downloader? The > uploader? How do we measure it? How do we verify the measurement? What if > someone MITM injects packets?

Internet access billing has fairly established practices. There are no unknowns there. It's either flat rate in retail or 95th percentile in wholesale. Metered billing is an anomaly that can be largely be done away with.

MITM packet injection is not really something you have to worry about. Suffice to say spoofing can be largely prevented.

> We need to make decisions and figure things out in order to get internet to > the level of, say, electricity.

There really isn't much to figure out. You can sell Internet access almost the same way you sell electricity.

<comment><USER16> As regards rural areas (like where my sister lives) not having fast internet, this is why my blog has no graphics, photographs or other doodads: they take too long to download over phone lines.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Interestingly, Japan oil consumption felt by +/\- 18% since 2000 while population remained stable.

[https://en.wikipedia.org/wiki/Demography_of_Japan](https://en.wikipedia.org/wiki/Demography_of_Japan)

[http://www.indexmundi.com/energy.aspx?country=jp&product=oil...](http://www.indexmundi.com/energy.aspx?country=jp&product=oil&graph=consumption)

<comment><USER18> This is mostly true for many developed countries.

For example, in the nr 1 economy in Europe, Germany, the figure dropped since the 80s, and all of this is well before renewables ramped up (which are still tiny). Same with the nr 2, the UK, also dropped, and the nr 3, France. I haven't bothered looking further. All these countries grew in size somewhat btw.

In part it's because of new efficiencies, in part because of shifting industries away from industrial towards services.

</comment></comment><comment><USER19> As I write this comment, this story is on the front page just above the story titled "Misperceiving Bullshit as Profound." I find the juxtaposition amusing. I'm a huge proponent of EVs, but this comparison is meaningless and silly.

</comment><comment><USER20> More than one pump per gas station. Still very impressive!

<comment><USER21> And, as the article hints at, refuelling with gas takes minutes vs. hours for electric. It'll probably take a couple orders of magnitude more electric chargers than gas stations to support the same number of each vehicle type.

<comment><USER22> But on the other hand electric cars can be charged at home …

Depending on how many people have a place with a power outlet (ok, a garage) in close proximity to their car and depending on how many people frequently drive less than their range per day (and less than their maybe underpowered power outlet can charge in one night) that might save on quite some public outlets. But I don't know the numbers.

I know many people where this would apply, though. And those outlets are included in this number, anyway. Which kinda supports my assumption: I think you might be able to get away with actually many fewer public power outlets than gas stations.

<comment><USER3> FYI, to own a car in Japan, you must have a legal verified parking spot that you own. For most people, that probably means land in the same area as your home. So even without a garage, they should still be able to install an outlet on their own property.

edit: There's a culture difference with regards to driving that I explained in another comment just now. Reading some of the other comments further down makes me think that very few people commenting here understand the laws and culture behind driving in Japan.

<comment><USER22> Cool! I obviously didn't know that. So that use case is probably quite common in Japan (if the other factors line up, but I don't see why they wouldn't, frequently).

In the US and Europe having your own, dedicated place to put your car is probably more or less weakly coordinated with owning a car (maybe less in the US, where at least in some places owning a car is more of a requirement?). Just because being able to afford a car is probably weakly coordinated with being able to afford your own spot. But this regulation should make that even more so in Japan.

</comment></comment></comment></comment></comment><comment><USER23> This claim is only true because they included private garage based charging, such as in a home. A pretty big stretch in trying to generate a headline.

<comment><USER24> I think it's reasonable to count those. People use them, maybe even more than public ones. They serve a huge purpose and are an important part of having electric cars in society. They're very much on-par with gas stations for this count, and for the viability of the electric car system, in my opinion. After all, Nissan (referenced in this article) is talking about the viability of the electric car system in society, not just numbers for fun or headlines.

If people had personal gas stations because it took a long time to fuel your car and you had to do it overnight, those should count too, because they'd argue for the viability of the combustion engine. But that's not the case.

<comment><USER25> > _" People use them, maybe even more than public ones"_

I drive a Chevy Volt, which spends about 23 hours per day plugged in to the charger in my driveway. That private spot gets used a lot, but it only services one vehicle. Even a public charging station generally only serves the needs of a couple dozen vehicles per day. Whereas a gas station generally services hundreds, or even thousands, of vehicles. So a spot-to-station comparison isn't really very useful. The more relevant question is "how many vehicles does this infrastructure support, in what usage patterns?"

The answer to that question is, still a lot fewer electric vehicles than gasoline vehicles are supported by the current infrastructure (even in Japan), and the usage patterns are more limited.

We're clearly in a transitional period where electric vehicles are becoming viable, but there are limitations. As I said in a recent thread, _" If I purchase a vehicle, I'm likely to want it to work for every trip I want to take ... If a car sucks for even one of those trips [to distant states, the airport at ~45 miles round-trip, or a long day of errands], I'm going to be hesitant to buy it"_. As electric ranges get longer and public charging stations get faster and more dense, electric vehicles will become more viable for more people, but right now they're still not on par with gasoline vehicles for the population as a whole (not even in a smaller country like Japan.) The progress is exciting, but sometimes it's presented in misleading ways that make it sound a lot closer to "always viable" than it really is.

<comment><USER10> > but right now they're still not on par with gasoline vehicles for the > population as a whole (not even in a smaller country like Japan.)

Completely untrue. The average round trip daily commute in the US is ~45 miles. Even mediocre electric vehicles like the Leaf and the Bolt can do that.

I'm assuming Tesla's Model 3 is what causes EV demand to take off. ~200 mile range + Supercharger access = electric mobility is solved.

<comment><USER25> > _" The average round trip daily commute in the US is ~45 miles."_

You can't just look at an average trip and say "this vehicle can handle it, therefore it's completely viable for the average person", because the average person sometimes takes trips other than their average daily commute. Sometimes they go visit their grandparents or cousins out on the farm. Sometimes they visit their sister who lives two states over. Sometimes they make their ordinary daily commute but then follow it up by driving to a sporting event or a get-together some distance in the opposite direction. If an EV is suitable for your daily commute, but not for your occasional trips, then it's still not on par with a gasoline vehicle.

Even the supercharger network has a long way to go; here's a comment I made about it a month ago: [https://news.ycombinator.com/item?id=11431401](https://news.ycombinator.com/item?id=11431401)

The takeaway is that about 1/4 of the US population lives in metro areas that are well-served by the supercharger network in all directions, and 3/4 lives in areas that have significant gaps for at least one significant direction of travel.

My uncle and my wife's grandpa were EV enthusiasts going back decades. I drive a plug-in electric (with a gas generator, which solves the not-well-covered trip problem) and so do my in-laws. I've been watching carefully. Right now, there are still lots of reasons for lots of people to stay away from pure electric vehicles, and while that list of reasons is getting shorter, it's still a long enough list that for a lot of people it's a non-starter as a primary vehicle.

<comment><USER10> I disagree, but respect your point of view.

</comment></comment></comment></comment></comment></comment><comment><USER26> I just came back from Japan, and saw very few EVs on the road, just one or two Nissan Leafs. By a wide margin the cars you mostly see on the road there are kei-cars, which are small cars with 660cc engines. They are cheap, tax- advantaged, offer good fuel economy, and are surprisingly roomy. Until there is a good EV kei alternative I don't think EVs will really take off in Japan. Hybrids are pretty common though.

I also saw several mobile charging spots at convenience stores though, which is brilliant, and some larger car parks covered with solar panels. Being able to get charging points at convenient locations using the existing grid, and thus doing away with specific trips to the gas station and fuel distribution logistics will be a huge advantage eventually.

<comment><USER27> The statistical evidence backs this up: pure electric vehicle sales in Japan are a tiny fraction of total vehicle sales -- less than 1% -- and sales are not growing significantly.

The headline is linkbaity and meant to play on people's unfounded stereotypes of Japan as some sort of environmentally superior Utopian Tomorrowland.

Only about 30,000 plug-in vehicles are sold per year in Japan[1], out of 4.2 _million_ total passenger vehicles sold.[2]

Growth forecasts for plugins are anemic, with even the most optimistic estimates predicting only 50,000 units sold annually by 2023.[3]

[1] [https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_J...](https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_Japan#Sales_by_model)

[2] [http://www.statista.com/statistics/269889/passenger-car- sale...](http://www.statista.com/statistics/269889/passenger-car-sales-in- japan-since-2007/)

[3] [https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_J...](https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_Japan#Future_trends)

<comment><USER26> I think Japan is at least better than the US environmentally in a number of ways, but a lot of the benefit is squandered away by things like overuse of air conditioning, packaging waste, and industry.

</comment></comment></comment><comment><USER28> I would be more interested in statistics about Norway as 30% of new cars are electric there.

<comment><USER29> I believe there are around 50 - 60 000 EVs in Norway and 6000 public charging stations. The EU is mandating that Norway needs to build 25 000 charging stations by 2020.

Shortage of charging points is becoming a problem as the number of electric cars is growing much faster than the building of charging stations. So while there is good geographic coverage the problem is that so many need to charge at the same time.

Whenever I pass charging stations down town they always seem to be occupied by somebody.

<comment><USER30> How can the EU tell Norway to build charging stations if Norway is not even a member of the EU? Do you have any sources for that?

<comment><USER31> Norway is part of the European Free Trade Association. It has access to the EU market but it means it has to respect certain laws and there is freedom of travel/work.

</comment></comment></comment></comment><comment><USER32> The actual data worth looking will the percentage of electric vehicles to ones that run on conventional fuel.

[1] [https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_J...](https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_Japan) [2] [https://en.wikipedia.org/wiki/Electric_car_use_by_country#Ja...](https://en.wikipedia.org/wiki/Electric_car_use_by_country#Japan)

<comment><USER25> of note: Japan has about 80 million total vehicles (via [https://en.wikipedia.org/wiki/Motor_vehicle#Japan](https://en.wikipedia.org/wiki/Motor_vehicle#Japan) ) -- so while the number of pure electric vehicles is rising, it's still a small percentage overall.

</comment></comment><comment><USER33> Why don't gas stations offer quick charging spots by now I wonder? Why are they not interested in attracting EV owners?

</comment><comment><USER34> Sometimes revolutions happen quietly, very quietly.

(actually, that could be an electric car company slogan)

</comment><comment><USER35> Japan has quietly done it and forgot to tell the world!

</comment><comment><USER36> Cool, lots of cars running on nuclear energy, then!

<comment><USER37> Nope. There's barely any nuclear power here now. Most plants were turned off after Fukushima. In fact I believe only 1 is online at the moment.

[https://en.wikipedia.org/wiki/Nuclear_power_in_Japan](https://en.wikipedia.org/wiki/Nuclear_power_in_Japan)

<comment><USER36> Ah, didn't know that. I guess they are mainly running on electricity from coal/oil/gas power plants, then.

<comment><USER38> Which is a lot more efficient than running off direct-drive petrol engines. There are reasons why e.g. diesel-electric locomotives are a thing.

</comment></comment></comment></comment><comment><USER39> and Tesla has barely THREE charging stations in Tokyo... (2 are in "center" and one on the periphery).

<comment><USER40> The last time I went to a Tesla store, they told me Superchargers aren't supposed to be used in cities, they're supposed to be used mainly for road trips. Putting them between major cities allows them to be free to be used for road trips without making them convenient enough for most people to use them as their usual charging station.</comment></comment>


Masayoshi Son Loses $6B During WeWork and Uber Crash - <AUTHOR> https://www.bloomberg.com/news/articles/2019-11-05/wework-mess-leaves-softbank-s-masayoshi-son-6-billion-poorer <comment><USER2> Taking huge risks and some of them being realized is not problematic.

It's really problematic when it's revealed that Son has failed to enforce basic corporate governance principles to guard his investments. Son has been called 'investor of first resort' but based on his history some assume that there is method to his madness.

It starts to look like his real genius is to separate investors from their money and ride on the top of economic booms hoping for the best. He has taken Saudi money and sucked out Japanese retail bond investors. Not very smart money.</comment>


Effects of Fructose vs Glucose on Appetite and Reward Pathways [pdf] - <AUTHOR> http://www.scribd.com/doc/118673844/jpc120014-63-70 Conclusion:<p>"Glucose but not fructose ingestion reduced the activation of the hypothalamus, insula, and striatum—brain regions that regulate appetite, motivation, and reward processing; glucose ingestion also increased functional connections between the hypothalamicstriatal network and increased satiety.<p>The disparate responses to fructose were associated with reduced systemic levels of the satiety-signaling hormone insulin and were not likely attributable to an inability of fructose to cross the blood-brain barrier into the hypothalamus or to a lack of hypothalamic expression of genes necessary for fructose metabolism." <comment><AUTHOR> Conclusion:

"Glucose but not fructose ingestion reduced the activation of the hypothalamus, insula, and striatum—brain regions that regulate appetite, motivation, and reward processing; glucose ingestion also increased functional connections between the hypothalamicstriatal network and increased satiety.

The disparate responses to fructose were associated with reduced systemic levels of the satiety-signaling hormone insulin and were not likely attributable to an inability of fructose to cross the blood-brain barrier into the hypothalamus or to a lack of hypothalamic expression of genes necessary for fructose metabolism."

<comment><USER2> Can anyone translate?

I'm a native english speaker with a science-y background and I find that tough going!</comment></comment>


Alan Kay and OO Programming - <AUTHOR> https://ovid.github.io/articles/alan-kay-and-oo-programming.html <comment><USER2> >> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it easier to change those decisions), but can also allow you to build systems that you can change while they are still running!

>> Binding can also refer to binding a variable type to data.

As someone who has over 15 years of experience going back and forth between statically typed and dynamically typed programming languages (but who has settled on dynamically typed languages in the last 4 years), this statement resonates very strongly with me. Also, it ties in perfectly with my philosophy of focusing on integration tests instead of unit tests; the idea that you should lock down the features of your system but keep the flexibility to move around the all the internal implementation is critical.

It's a shame to see the new generation of developers moving back to statically typed languages (e.g. TypeScript) instead of actually trying to understand how to use dynamically typed languages properly. The obsession around achieving 100% unit tests coverage is equally shameful.

Many of the people who came up with or promoted the idea of dynamically typed languages had decades of experience working with punchcards, assembly code and statically typed languages; they were onto something. Why does the new generation so easily discard this vast amount of wisdom?

<comment><USER3> I'm a fresh graduate from uni so I'd say that I don't have that much experience. My last years working on the side of studies using Python really made me prefer strongly typed languages like Haskell, Rust, Elm etc. My experience is that the compiler almost always finds my small errors and would- be-bugs which Python exposes at runtime (crashes with e.g. None-type errors).

What would you say the benefits are with dynamic typing?

<comment><USER4> Python _IS_ strongly typed. ie: 1 == '1' is FALSE, and 2 + '2' raises an exception.

<comment><USER5> So forgive jompe for using the wrong term. The point, however, was clear. It wasn't "strong vs weak"; the point clearly was "compile time vs run time". And, well, Python is, from jompe's perspective, on the wrong side of the line, no matter how "strong" Python's type system is.

<comment><USER4> There is nothing to forgive, many people conflate dynamic typing with weak typing, so I thought I would point it out.

Whether or not a specific method of typing is good or bad depends on the project and the developer(s) working on it. But if you're going to use that as a reason to make decisions, then you should understand the difference.

</comment></comment></comment></comment></comment><comment><USER6> I'm not sure I understand why late binding and Alan Kay style messaging is desirable.

If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?

<comment><USER7> In my experience silent failure leads to some of most difficult to debug systems that end up in a not quite right state. Fail as early as possible has always worked better for me, bugs are found much earlier.

<comment><USER8> Things are different in-the-small vs. in-the-large.

You can't statically typecheck the internet. Oh, and no-one said the failure needs to be silent.

<comment><USER9> Totally agree failure should be announced for another object to observe and decide to do something about.

I didn't feel the author got the messaging part. 'You send some data to an object' kind of misses the point.

Going back to Kay's inspiration in cellular function the messaging is more a broadcast, though proximity matters as far as which other cell responds (Internet routing tables are a good approximation but you need something more dynamic to allow objects to be created and destroyed).

</comment></comment></comment></comment><comment><USER10> I have a ton of respect for Alan Kay and think he's a genius. But why does it seem like every time he talks about OO it's always painting an apocalyptic picture like we're in some kind of twilight zone alternate nightmare reality of broken patterns and models? Surely our concept of objects and OOD can't be that bad, but his apparently contrary outlook is just so persistent...

<comment><USER11> > I have a ton of respect for Alan Kay and think he's a genius. But why does > it seem like every time he talks about OO it's always painting an > apocalyptic picture like we're in some kind of twilight zone alternate > nightmare reality of broken patterns and models?

Because we are? Have you seen most OOP code-bases, they are a train wreck!

<comment><USER12> JavaScript is functional and oh boy!

<comment><USER13> What does "functional" mean to you? If "OO" has a hundred different meanings, then "functional" must have at least a thousand. To me, JavaScript is definitely not functional - it lacks a notion of purity, and its meaning is the evaluation of statements, not the construction of expressions.

<comment><USER12> My point was popular languages attract masses of developers and the resulting quality of code is poor on average.

<comment><USER13> That's a good point, but it's not implied by "JavaScript is functional and oh boy!" at all.

</comment></comment></comment></comment></comment></comment><comment><USER14> Language features: it depends on what you need.

I am a huge fan of Lisp (started using professionally in 1982) and to a lessor degree Smalltalk (I wrote a nifty little NLP library for Pharo). That said, sometimes I really like the strict typing of Haskell, which I am using right now to develop a commercial product.

Smalltalk, especially with the increasing good modern Pharo system, is a great platform for some application, especially for getting close to data and flexibility in trying UI ideas.

In any case, Alan Kay has always been an inspiration to me.

</comment><comment><USER15> What is late binding of everything ?

To me it's a bit like doing the opposite of what macros in Lisp do, but to do it during run-time rather than compile-time.

Take Ruby for instance (which is interpreted in its standard implementation). You can define methods at runtime and 'keywords' that allow you to define new methods are methods as well.

As a result you can extend the more "static" part of the language, adding new ways to declare methods and other "quasi-syntactic" sugars because this static part has been moved close to run-time and is executed like any other part of code. There are still a few things you can't do, like building a new way do declare classes or changing the superclass they point to.

Edit: this interpretation is driven by the notion of PHP's Late Static Bindings[1].

[1] [https://php.net/manual/en/language.oop5.late-static- bindings...](https://php.net/manual/en/language.oop5.late-static-bindings.php)

<comment><USER16> Rather than seeing "late binding of everything" as a specific implementation or bits and pieces of a particular implementation, I find it is much more clear to see it as a general self-referential idea. Why then would one _go against it and try to constrain it_ ?

Taken in that light, as the article does a really good job of explaining, late binding of everything is a modeling process (or a process of thinking about things). It means that I should try and keep parts of the structure that I'm building up as flexible as they can be so that they match the model in my mind. One benefit of doing that is that I can later revisit and rework them. Another benefit that is seldom talked about, is that _the object I'm working on no longer constrains my thinking_.

In other words, only specify in detail that which is crystal-clear in my mind model, and get away with fuzzier representations elsewhere. Tools and languages that fall inline with that process, not only empower one to work in this way but make it _ultra-efficient_ by triggering short feedback-loops and allowing the programmer to mesh with the modeled object.

</comment></comment><comment><USER17> Some interesting points:

\- One cell has protein molecules with 5,000 atoms each; 30% of cell is 120 million components that transmit information; About 100GB of state.

\- The internet is the only successful OO program

\- Your program should be able to change its code as it runs

My own interpretation of the "messaging" paradigm is this: you send 100 people a letter with some random symbols in it and say, "I would like a pony." Over time you will get letters back, and eventually you will get a response which is basically what you were looking for. Then you send more letters.

Also I'd mention that based on the bugs in the erlang code I've seen, it should stop being used as some kind of holy savior of the unscaling mess of OO code out there. I don't find it any better than C code.

</comment><comment><USER18> What Alan Key describes reminds me of actor systems like Akka. Each actor is like a "cell" isolated from other "cells". An actor receives messages of arbitrary types ("messaging" and "late binding") and can do what it wants and whenever it wants. Actors can form a hierarchy to handle errors. This again is much like how cell handle injuries.

Interesting is that the Akka community put a lot of effort in implementing statically typed actors. But as far as I know (I'm not quite up to date) there is no final solution to it. It is controversial if it is even the right thing to do.

</comment><comment><USER19> _> , he realized that while software routinely has trouble scaling, cells can easily coordinate and scale by a factor of over a trillion, creating some of the most fantastically complex things in existence, capable of correcting their own errors. By comparison, the most sophisticated computer software programs are slow, tiny, bugfests. Kay's conception of OOP starts with a single question: how can we get our software to match this scalability?_

Here's my pet theory on why Kay's vision for OOP didn't win in the marketplace of ideas: The software industry achieves _" extreme late-binding"_ via _network protocols_ like TCPIP/HTTP instead of a single programming language's "message bus".

Instead of using the "message bus" of Smalltalk or Objective-C's "objc_msgSend()", the world has decided to express the evolution of software via _multiple programming languages and runtimes_ and by the mechanism of _software updates_ instead of depending on a single language ecosystem like Smalltalk to write a metaphoric cell biology system to evolve itself.

The majority of software we write isn't burned onto a printed circuit board and never ever updated again. An extreme example of an algorithm that's forever engraved in hardware is the computer on the Voyager space probe.[0] Instead of launching a computer out to space and never touching it again, we have the luxury of just updating the software.

If anyone remembers the 1980s online services like Prodigy and Compuserve, they would have _scheduled maintenance outages_. E.g. they'd send out a notification that "Prodigy will be down for service from Saturday midnight to Sunday at 4am".

But consider today's massive web properties like Amazon.com, Facebook, Google. They run _virtually 24 /7_ with no scheduled maintenance downtimes. How do they do that even though we know they're constantly deploying new software, microservices, etc -- and -- they're not using an extreme-late-binding programming language like Smalltalk? Because they achieve that dynamism at the http network layer instead of the programming language with devops practices such as _" continuous deployment"_.

E.g. The url can be thought of as a "request message" in Kay's parlance. Here's a url that uses Google Translate to convert Russian text to English:

[https://translate.google.com/?hl=en&tab=wT0#view=home&op=tra...](https://translate.google.com/?hl=en&tab=wT0#view=home&op=translate&sl=auto&tl=en&text=%D1%81%D1%87%D0%B0%D1%81%D1%82%D0%BB%D0%B8%D0%B2%D1%8B%D0%B5%20%D1%81%D0%B5%D0%BC%D1%8C%D0%B8%20%D0%B2%D1%81%D0%B5%20%D0%BF%D0%BE%D1%85%D0%BE%D0%B6%D0%B8)

Before September 2016, the Google's backend of software responding to that url was linear algebra on a corpus of text. After that, they completely switched out the translation engine to be a deep-learning neural network. The http layer allowed Google to transparently change out an entire backend stack without users being aware of it. There was no publicized "maintenance outage" to swap out the entire language translation engine. Presumably in the future, that same url ("message") will _extremely late bind_ to a different and better translation engine ("receiver object").

Today, we also have constant _software auto updates_ on the desktop and smartphone. How does Chrome/Firefox evolve new features even though they're written in static C++ instead of dynamic Smalltalk? Because the browsers _auto-downloads the updates_ and install them.

[0] [https://www.allaboutcircuits.com/uploads/articles/voyager_fd...](https://www.allaboutcircuits.com/uploads/articles/voyager_fds_nasa.jpg)

<comment><USER20> >Instead of using the "message bus" of Smalltalk or Objective-C's "objc_msgSend()", the world has decided to express the evolution of software via multiple programming languages and runtimes and by the mechanism of software updates instead of depending on a single language ecosystem like Smalltalk to write a metaphoric cell biology system to evolve itself.

I find your post very insightful. I'd just like to add that you have that kind of message passing in Elixir and Erlang, and they also support hotswapping code. So the idea didn't completely lose in the marketplace of ideas. It did lose the war for the name OOP though.

I'm not a fan of what we understand as OOP today either, just looking at the GoF book should make you think whether you want to work in the model that makes all this necessary. So I kind of understand Alan Kay. I just think calling Elixir an actor based functional language is just as good to me.

<comment><USER21> The GoF book was written for Smalltalk and C++, so the limitations that compel the invention of design patterns clearly apply to Kay's own language as well.

</comment></comment></comment><comment><USER22> Objective c is better in this respect. It is more about message passing than type enforcement.

<comment><USER23> Ruby even more so. (Both ruby and ObjC were originally heavily influenced by Smalltalk).

</comment></comment><comment><USER24> Great article. The idea that software should learn from billions of years of biological evolution is super interesting.

</comment><comment><USER25> >>In other words, you don't execute code by calling it by name: you send some data (a message) to an object and it figures out which code, if any, to execute in response. In fact, this can improve your isolation because the receiver is free to ignore any messages it doesn't understand. It's a paradigm most are not familiar with, but it's powerful.

A Redux reducer consuming an Action object would possess the same properties, no?

</comment><comment><USER26> The term object-oriented has often been misinterpreted. Alan Kay explained that "[the term object-oriented] was a bad choice because it under-emphasized the more important idea of message sending".

</comment><comment><USER27> What is a modern language that comes close to embodying these ideals?

<comment><USER28> Smalltalk comes to mind. You might argue over whether it counts as modern or not, but working in Smalltalk for two years was something of a revelation to me, at least.

</comment></comment><comment><USER29> Between elegant and 'industry-friendly' languages latter always win. Often shortcomings of the language are accounted for in tools around it.

</comment><comment><USER30> I always wonder what exactly did he mean. I'm not quite familiar with Smalltalk and CLOS though I have tried them. But after work with Erlang for a while made me think I'm slowly getting what he said. I found these ideas are really fascinating.

Try to think about the following pieces:

1\. A bee dies, the hive won't explode. Millions of cells die every minute within you.

In Erlang, usually, processes (object) are mostly organized as a bureaucratic structure, which has supervisors letting other objects doing the actual job. If someone dies or fails, the supervisor could just kill and replace them. This really looks like biological systems or human society. Not in a world that the boss let someone do some work, then the boss and the worker along with a whole world explodes if the worker fails (99% of OOP languages exception handling are not OOPish at all, it's totally imperative instead of modeling the relation between objects).

These correspond to the biological metaphor in the talk from Alan Kay in OP's article.

2\. You can find and talk to someone alive if you know his address, email or phone number.

Java has object reference but it's not transparent to other systems, there is always the 'outside world' concept in this kind of reference or pointer system, similar to ST monad in Haskell. For a normalized database, there are transparent addresses for entity records, but they are dead and cannot talk to anyone until every time you need it, you sort of revive then interact with it for a short period, then you kill it and take its guts back to the database.

In Erlang, you can register any process (object) with an address like {user,42}, any other object can talk to it if they know the address, even from other servers. Just like how URL works mentioned in Alan Kay's talk.

3\. The world is concurrent.

You have approximately a thousand audiences in a room. In order to count them, you let them all stand up. You tell everyone needs to get a number '1' in their mind. Then everyone finds another person, add their '1's, one person sits down, another person remains to stand, takes the former guy's number, then repeat the process. The last person stands has the count.

Usually, you only need to count very few times to get the answer. And this is what computer science is about. The problem is, that's not the way most computer program works. Because for most programs, even if you modeled 1000 people in Java, there's still only one person doing one thing at a time. Everyone runs on a monolithic thread. If you call libraries, you are giving them the most important thing you have -- the thread. And they don't promise they will return it to you.

Contrastly, in Erlang, every process (object) must have its own resource, no one can stop other people from doing things, no one can use up all the resources. The real world is a concurrent world where everyone is an isolated individual who can do things at the same time.

</comment><comment><USER31> [https://lobste.rs/s/8yohqt/alan_kay_oo_programming#c_5xo7on](https://lobste.rs/s/8yohqt/alan_kay_oo_programming#c_5xo7on)

>> He doesn't have random opinions about "objects", he invented the word

> Kay did not invent the term "object".

<comment><USER32> Alan Kay says he did.

"I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea."

Source: [http://lists.squeakfoundation.org/pipermail/squeak- dev/1998-...](http://lists.squeakfoundation.org/pipermail/squeak- dev/1998-October/017019.html)

<comment><USER31> > Alan Kay says he did

How sad if true! I'm reserving the right to think you misunderstood what he was trying to say there.</comment></comment></comment>


Building a Better Button - <AUTHOR> https://medium.com/designed-thought/18a49d066ce5

<comment><USER2> I'm not totally convinced but it could work very well in a large format mobile context.</comment>


Ask HN: Any accessible way to explain trees? - <AUTHOR> I've run into this one over and over. There will be some part of some application where the world will be represented with a tree as the data structure. Think hierarchies of various kinds - org structures, product catalogs, workspace groupings, etc.
The fact it's a tree is really important to the functionality the user wants, even if they don't know how to think in terms of trees in an abstract way ("you can roll up information from child orgs into their parent's reporting").
The language around trees just doesn't resonate and gets lost on people. This includes potential customers, sometimes project management, etc.
Have you ever come across a _really_ good way of describing trees? Or, in-context of requirements/work material, a means of talking about this idea that didn't cause people to lose focus? <comment><USER2> File directories, royal/family trees, animal kingdom trees are good starting point.</comment>


Searchkit 0.9 – React UI Components for Elasticsearch - <AUTHOR> https://blog.searchkit.co/searchkit-0-9-23d78568d219#.v4c27y21q <comment><AUTHOR> Github link! [http://www.github.com/searchkit/searchkit](http://www.github.com/searchkit/searchkit)

</comment><comment><USER2> Although I like the idea behind this, I find it quite difficult to get started in using it. Any good posts or guides for that?

<comment><AUTHOR> Hey!

Have a look at our Getting started documentation: [http://docs.searchkit.co/stable/docs/setup/index.html](http://docs.searchkit.co/stable/docs/setup/index.html)

and heres a searchkit boilerplate project to base off on [https://github.com/searchkit/searchkit- boilerplate](https://github.com/searchkit/searchkit-boilerplate)

If you are still stuck, jump onto our gitter chatroom. The link is on our website www.searchkit.co.</comment></comment>


Smart Playlists now in MoviePile - <AUTHOR> http://moviepileapp.tumblr.com/post/46487322884/early-smart-playlists-build-179-180

<comment><AUTHOR> While this is my app... I really feel like Smart Playlists make the app feel more "alive"...and helpful as far as organizing and making use of Tagmarks.</comment>


Virtualizing React's Virtual DOM - <AUTHOR> https://medium.com/outsystems-engineering/virtualizing-the-virtual-dom-pushing-react-further-d76a16e5f209#.bh3gwyfw1 <comment><USER2> Instead of precisely calculating which items are inside the viewport, couldn't you guesstimate it and start discarding items that are too far back in the list?</comment>


Eventual regulation of system administration? I think so.  - <AUTHOR> http://www.standalone-sysadmin.com/blog/2011/11/eventual-regulation-of-system-administration/

<comment><USER2> _The path of a lot of system administrators from amateur to professional resembles that of a child who is exceptionally gifted at building erector sets being hired to construct a pedestrian bridge. Then, if the bridge doesn't fall, the kid gets to build bridges designed to handle interstate traffic._

This is the key point. It's SO HARD to grow as a sysadmin, because there are very few people who can pass on information. We have pretty much one textbook (TPoSNA: <http://everythingsysadmin.com/> ), and a few organizations like LOPSA and USENIX, but there are almost no Windows or Mac specific sysadmins who join.

There are also places where regulation is already happening, albeit in a top down manner, like HIPPA. I doubt top down "you must do this" regulation would help, but accreditation where people have to know and ought to follow best practices would likely do more good.

</comment><comment><USER3> Did I really just read this? No discussion of what possible regulations might be required, just "sysadmins are untrained. We may need rules". HN bait at its worst.</comment>


Botswana MP proposes lifting elephant hunting ban - <AUTHOR> https://africageographic.com/blog/botswana-mp-proposes-lifting-elephant-hunting-ban/ <comment><USER2> It's about time Botswana did something about their elephant numbers. Chobe is practically overrun with elephants, and until now, the government seemed unwilling to keep the numbers under control.

If they can raise money for conservation by combining their culling activities with trophy hunting I think it is a win for everybody. This can turn a pure cost-centre into a revenue generating activity with the income applied to other desperately underfunded efforts like Rhino conservation.

I support hunting for food, but don't support trophy hunting unless it is part of a culling program or part of removing problem animals.

<comment><USER3> I question whether Botswana needs to kill their elephants, especially as reports have Botswana containing 1/3 of the entire African Elephant population.

>Chobe is practically overrun with elephants

And the proposed law will not fix that, hunting would only be allowed outside preservation areas.

I like the final line of the article:

>Mr Guma therefore said government should swiftly act on how best to resolve the human/wildlife conflict and that the lift on the hunting ban and shooting of elephants in areas not designated as game reserves could be remedial to the crisis.

<comment><USER2> > I question whether Botswana needs to kill their elephants, especially as > reports have Botswana containing 1/3 of the entire African Elephant > population.

Obviously killing elephants (any animal really) in large numbers is a big problem on many levels. Transporting elephants is also difficult and expensive, and more importantly you need someplace to put them. Most of the other big game reserves in Southern Africa also have problems keeping their elephant numbers in check. Where would you take them?

> And the proposed law will not fix that, hunting would only be allowed > outside preservation areas.

I haven't been up there in a couple of years, but the fencing around Chobe is spotty at best, the entire riverfront is unfenced (at least the part you get to see as a visitor), so I don't think there is really a big restriction on the Elephants' freedom of movement. I am guessing this is one of the reasons why they can cause so much damage to the crops of local farmers, they aren't really fenced inside the game reserve properly.

Targeting the elephants outside the park does more to alleviate the farmers' immediate problem, but its the same population of elephants (in the broad sense, not the herd sense) inside and outside the park.

</comment></comment></comment><comment><AUTHOR> You guys should consider donating to the International Anti-Poaching Foundation[0][1] which fights these poachers. The founder, Damien Mander[2], is an Australian ex spec-ops sniper who is using his military experience to train the park rangers since they, unlike the poachers, tend to be poorly equipped and trained as well as understaffed.

There is also the David Sheldrick Wildlife Trust[3][4] which takes care of elephant and rhino orphans (most of them are orphans due to poaching). For $50 a year, you can become a sponsor of a particular animal and they'll send you photos and updates about how your sponsored animal is doing. You can for example sponsor this little fella [5][6].

[0] [http://www.iapf.org/en/](http://www.iapf.org/en/)

[1] [https://en.wikipedia.org/wiki/International_Anti- Poaching_Fo...](https://en.wikipedia.org/wiki/International_Anti- Poaching_Foundation)

[2] [http://en.wikipedia.org/wiki/Damien_Mander](http://en.wikipedia.org/wiki/Damien_Mander)

[3] [http://www.sheldrickwildlifetrust.org](http://www.sheldrickwildlifetrust.org)

[4] [http://en.wikipedia.org/wiki/David_Sheldrick_Wildlife_Trust](http://en.wikipedia.org/wiki/David_Sheldrick_Wildlife_Trust)

[5] [http://www.sheldrickwildlifetrust.org/asp/orphan_profile.asp...](http://www.sheldrickwildlifetrust.org/asp/orphan_profile.asp?N=318)

[6] [http://instagram.com/p/sigT3IAUKb](http://instagram.com/p/sigT3IAUKb)

<comment><USER4> If the ban is lifted, donating to the International Anti-Poaching Foundation wouldn't accomplish much, since none of the elephant hunting would be illegal...

There's also an elephant population problem in Botswana, so as sad is it may be, these measures are necessary.

<comment><AUTHOR> Poaching goes on regardless of legal status. Also they work in other places besides Botswana.

</comment></comment></comment><comment><USER5> Can anyone explain sport/trophy hunting to me? I can't imagine looking through a scope knowing you're about to end an animals life for "fun" without the thought of it's pain, social bonds or right to exist stopping you from pulling the trigger.

<comment><USER6> There's a great Joe Rogan podcast with a bow hunter, and Joe spends a lot of time explaining why trophy hunting can be great.

It funds conservation, which decreases poaching, which is better for literally everyone involved including the animals and the poachers.

I believe it also tends to be very controlled and directed so the effects can be planned.

Elephants can be a huge, dangerous, nuisance (apparently) to farmers who are trying to have enough food to eat. That's just one example.

<comment><AUTHOR> The benefits are greatly exaggerated

[https://www.nationalgeographic.com/magazine/2017/10/trophy-h...](https://www.nationalgeographic.com/magazine/2017/10/trophy- hunting-killing-saving-animals/)

The money doesn't end up where it should and the oversight is minimal.</comment></comment></comment>


Supplements can make you sick - <AUTHOR> http://www.consumerreports.org/vitamins-supplements/supplements-can-make-you-sick/ <comment><AUTHOR> I think this is relevant to HN given the widespread use of various supplements in the community. It is also interesting given popularity of Tim Ferris, Nootrobox, and other supplement enthusiasts.

</comment><comment><USER2> Misleading title. Nothing to do with supplements per-se.

"Contaminated supplements can make you sick", but I guess this is too obvious to attract any reader.

<comment><AUTHOR> Umm, no. That's only the first few paragraphs. The rest is about the side effects of things like green tea extracts, caffeine powder, etc.</comment></comment>


A basic Lisp interpreter in R - <AUTHOR> https://github.com/dirkschumacher/llr <comment><USER2> Ihaka (co-creator of R) may still be working on a new statistical programming language based on Common Lisp.

[https://www.stat.auckland.ac.nz/%7Eihaka/downloads/Compstat-...](https://www.stat.auckland.ac.nz/%7Eihaka/downloads/Compstat-2008.pdf)

<comment><USER3> That was the inspiration behind Incanter[1], but I haven't heard about efforts by R. Ihaka beyond his writings/presentations 2008-2010 or so.

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

</comment></comment><comment><USER4> If you enjoy this sport, there's also Make-a-Lisp (MAL), an ongoing project to write lisp in every programming language:

[https://github.com/kanaka/mal](https://github.com/kanaka/mal)

In particular, here's their R version:

[https://github.com/kanaka/mal/tree/master/r](https://github.com/kanaka/mal/tree/master/r)

<comment><USER5> "Implement a Lisp" seems to be Lisp's version of "rewrite it in Rust."

<comment><USER6> If done for educational purposes then there isn't anything wrong with that.

<comment><USER5> You say that like there's something wrong with rewriting it in Rust.

</comment></comment></comment></comment><comment><USER7> This is brilliant. It kind of reminds me of hy ([https://github.com/hylang/hy](https://github.com/hylang/hy)) in addition to Norvig's lis.py that the author cites as inspiration.

I feel like lots of folks in the R community secretly or not-so-secretly pine for lisp. My own "someday project" is to implement some portion of R in Racket—"Arket". Of course all the native libraries that have been wrapped in R are the tricky bit.

<comment><USER8> > Of course all the native libraries that have been wrapped in R are the > tricky bit.

Everything in R is an SEXP struct. The native code is all shared libraries on Linux and Mac, and mostly DLLs on Windows. There should be almost no problem calling the native libraries if you have an existing R installation.

That doesn't apply if you are talking about a complete reimplementation of R, but that would be a massive project, in which case calling native libraries would be of little relevance.

</comment></comment><comment><USER9> From one of the linked issues, a "Lisp-like R": [https://github.com/chanshunli/jim-emacs-fun-r- lisp](https://github.com/chanshunli/jim-emacs-fun-r-lisp)

</comment><comment><USER10> You can also open a lisp interpreter and open an R session from here. Probably more efficient.

If you want to open a lisp repl inside R you can just open an R session and write:

system("sbcl", intern=FALSE)

That's all... use intern true if you want to save the session to an R object

foo <-system("clisp", intern=TRUE)

<comment><USER11> One of the point's is that you can use R's functions in a LISP-like language.

<comment><USER8> In that case, why not just embed an R interpreter inside Lisp? I've published a slightly modified fork of RInside that lets you embed R inside anything with a C FFI[1]. Tested only on Linux.

[1] [https://bitbucket.org/bachmeil/rinsidec](https://bitbucket.org/bachmeil/rinsidec)

</comment></comment></comment><comment><USER12> R with Lisp syntax. Cool stuff.</comment>


Animation of the AES algorithm - <AUTHOR> http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf <comment><USER2> Shows how, but doesn't explain why, which make it completely pointless.

<comment><USER3> The why would be useful but I would hardly say it is pointless. For example I understand the theories but I'm light on details given I have never implemented an encryption algorithm.

Hmmm weekend project?

<comment><USER4> Writing encryption algorithms as a weekend project should generally be approached in the same way as one might approach writing aircraft control code as a weekend project:

Never use it, never distribute it in a way that someone else might mistakenly think it's a good idea to use it (so posting it on github would probably be a mistake!) and expect your implementation to have bugs you don't realize. (Even if you shove plaintext in and get the right ciphertext out doesn't mean you've found all the bugs, it gets tricky and in some cases different specific algorithmically _correct_ implementations can have not just different performance characteristics, but different runtime security characteristics.)

Otherwise, enjoy.

Most people tend to find weekend projects more fulfilling if they have a way to put them to use. So while I don't mean to go all "this is dark arts that no one should practice uninitiated" on you, I would encourage you to stifle your tendency to find a use for any encryption code you write that isn't peer reviewed. View it as purely an artform; code never to be utilized.

This is the same advice most security researchers give to themselves and others.

<comment><USER5> Rijndael is well known cipher which became AES - <http://en.wikipedia.org/wiki/Advanced_Encryption_Standard>

It is not weekend project in any way.

I think that post you answer meant "weekend project on encryption algorithm animation".

<comment><USER4> I was strictly confining my comments to the implementation the poster was discussing coding up in a weekend.

The Rijndael algorithm itself is of course, very well reviewed and perhaps one of the most solid algorithms publicly available. Which is part of why it was chosen for AES. (Speed being the other factor.)

I think perhaps you misunderstood the conversation.

</comment></comment></comment></comment></comment><comment><USER6> I am more interested in who did the animations. I need such animations to describe our software.

<comment><USER7> Looks like ezabala at adinet dot com dot uy, Enrique Zabala. Universidad ORT, Montevideo, Uruguay

</comment></comment><comment><USER8> On step 4, AddRoundKey, shouldn't e5+17 be fc, not f2? Or is AES using something other than simple 8-bit modular arithmetic? It looks like the author did the arithmetic in his/her head, and accidentally used decimal for the second digit (5 + 7 = 12, mod 10 = 2).

<comment><USER9> The + in a circle means xor, not plus

<comment><USER8> That's what I get for learning programming years before entering college. I forget standard mathematical notation, since I always use programming language operators (like ^) in my head. Further, I only checked the first row to make sure it was actual addition, and obviously 0xa0 + 0x04 == 0xa0 ^ 0x04.

I should've just checked here first (includes an image of the slide in question): [http://stackoverflow.com/questions/839479/what-does-a- circle...](http://stackoverflow.com/questions/839479/what-does-a-circled-plus- mean)</comment></comment></comment>


Ask HN: Independent Consultants, how do you find work? - <AUTHOR> I've been in my field for a while and feel comfortable enough that I want to try and branch out and consult as a side gig.
How do you go about finding clients for work?
Beyond reaching out to colleagues who might need some help, are there any specific tools, sites, or strategies you used to start off? <comment><USER2> There's the usual sites like upwork which have a lot of noise, and dirt cheap rates. Sites like Toptal are better in that regard as they are more exclusive because they have to make you jump through many hoops to get in.

Also just meeting new people and mentioning your work might end up landing you some projects. Focus on people who have their own businesses. They might not have a project themselves, but it's possible they might end up sending a referral in the future.</comment>