Ask HN: What tech stack would you choose for a serious, long-term business app - <AUTHOR> If you were about to start building a very vital brand new application for your company that needs to be maintained long term what tech stack would you choose? Put aside what devs at your company may already be comfortable with and lay out what you think is best.
When I ask tech stack I'm talking the whole dam thing, for example:
DB engine : ie MySQL, Postgres
API layer : ie Node w/joy, Java w/spring, PHP w/laravel, Elixer w/phoenix
Frontend SPA : ie React, Vue (do you use typescript or flow, webpack etc)
Caching : ie Redis, Mongo
PaaS : ie AWS, Google, Azure
Interested to hear your thoughts, and don't want any flame wars stating x is always better than y etc.
Feel free to just specify the stack but better to also back up why you think it is best in a few sentences. <comment><USER2> DB: Postgres

API: Ruby on Rails

Frontend: React, the react_on_rails gem to set up webpack, Flow, Redux, Immutable.js

Background Jobs: Sidekiq and Redis

Caching: Memcached

PaaS: convox (on AWS). See: [https://convox.com](https://convox.com) and [https://github.com/convox/rack](https://github.com/convox/rack) (But you should start with Heroku.)

I recommend the Rails stack. It's not the "hot new thing", but it's very stable, secure, and productive.

<comment><USER3> Definitely agree with memcached. This has been entirely bullet proof for us for years. We have had lots of nodes with billions of hits each running non stop for 3 years without a reboot on CentOS 5. Zero maintenance required. Amazing bit of software.

<comment><USER4> While memcached is great. I feel like its hard to argue for both redis AND memcached. It seems like redundant infrastructure unless you have very specific needs.

<comment><USER2> It's not a good idea to use a single Redis instance for both caching and persisted/transactional data (background jobs). For background jobs, you need real-time persistence with AOF. For caching, you want everything in memory, and you need an LRU cache that evicts any old data. This means you should run two Redis instances with different configurations. But in that case, it can be a good idea to use Memcached, which is recommended by Mike Perham [1].

[1] [http://www.mikeperham.com/2015/09/24/storing-data-with- redis...](http://www.mikeperham.com/2015/09/24/storing-data-with-redis/)

</comment></comment></comment></comment><comment><USER5> Answer for your given question: Java + Oracle. They'll both be supported by legions of enterprise devs until shortly before the heat death of the universe.

Real answer: it depends. You've told us nothing about your application's business requirements, operating environment, or staffing availability.

I'd also caution on the idea "put aside what your devs are already familiar with" \- different tech can give you _different_ velocities, but either you accept a much lower velocity for a long initial period while your team spins up OR you accept a significant recruiting cost to hire new devs & teach them enough about the business to make good decisions.

<comment><USER6> I'd like to second the important of staffing. If we were in a perfect universe we could use domain oriented languages for every project because devs would be familiar and competent with them. Obviously that is not the case.

<comment><USER7> I know it's kind of cliché and in my last project it also wasn't soo bad, but Java is not something I associate with lean and nimble. I know, OP didn't ask for that - but it sounds like the inception phase of a product, and I can't imagine working any other way than "release early, release often". Long-time support viable? Very probable.

</comment></comment></comment><comment><USER8> 1\. Tech stack has to be decided based on functional requirements (real-time chat, less-write but read-intensive etc) and non-functional requirements (concurrent connections to support, regulatory compliance requirements etc).

2\. Any serious business system (not just one app) will have multiple tech stack.

3\. In the long term tech stack has to change depending on the changing business needs.

Assuming a whole lot about above 3 points, choice could be postgres, python, react, aws. Purely because they are battle tested. Any discussions about their merits are moot without knowing requirements.

</comment><comment><USER9> The goal would be 4 CentOS servers (probably VMs in AWS/Azure) Server 1 - Nginx load balancer Server 2,3 - ServiceStack (default setup; minimal plugins) with C# on .Net Core Server 4 - centralized file/data storage. Postgres for SQL, Redis for Cache (possible Message Queue as well) but would start with 2 servers (one for .Net Core/Service Stack and one for Postgres)

This setup keeps the OSes standard across layers with the possibility to move pieces to Saas (eg. Redis -> Azure Cache/RedisLabs, ServiceStack -> anything supporting .Net Web Apps) if there is a cost/support benefit. IMO these tools have simple installs with common/sane defaults but are well documented for when business features become more complicated.

ServiceStack is mostly C# code with minimal coupling to the framework. It also offers many Plugins/Features for common web scenarios (auth, validation, etc). Basically ServiceStack is great at handling 'Http Request In' and 'Http Response Out'. Everything in-between should be straight C#/.Net.

Redis makes a great cache but can do messaging and pub/sub. ServiceStack offers libraries for Redis but others are available. It doesn't try to do too much so if a more feature rich Cache or Queue is required it will likely support the Redis use cases (and more).

Postgres is a great db engine but can also be a great document store. ServiceStack offers Ormlite support for db, there is raw SQL support via Npgsql or Marten for the full 'kitchen sink' use of Postgres...and I guess even Entity Framework.

I would start with HTML (ServiceStack/C# DTO -> Razor Format Plugin -> HTML) with Bootstrap and jQuery and add in API Support (ie. JSON) with Vuejs frontend if single page application interactivity made more sense.

When starting an assumed 'vital long-term' project I want my tools to have simple/clear boundaries so I can add/remove when necessary (well, more likely forced to) without losing my investment or doing any heavy 'dependency lifting'.

</comment><comment><USER10> Db Engine - AWS Aurora (Mysql or Postgres no preference). No lock in since you can just move to a Standard DB later. But little maintenance since you don't have to maintain your own servers.

API layer - I'm biased toward statically typed languages so either Node with Typescript, C# .Net Core with Web API, or Java. I don't trust Oracle's direction with Java and Node just seems to be architected badly but that's what the cool kids want to use. I prefer c# but again the cool kids have anti MS bias.

Front End - I'm no front end guru but since I'm always concerned with my marketability, React and Angular seem to be the most marketable. You can't go wrong either way.

Caching - It depends on your use case, but either Redis or Memcache would be good - especially since they are both supported by AWS ElastiCache. No server maintenance and still no lock in.

PaaS - AWS is more mature and no one ever got fired for choosing AWS.

Even though I've done my own dev ops, I avoid it like the plaque. In 2018, I would go serverless as much as possible. That means a combination of AWS Lambda for small tasks and AWS Fargate for serverless docker. But write your Lambda functions in a way that doesn't tie you tightly to AWS.

</comment><comment><USER3> As we're talking business and long lifetime...

First point: nothing Microsoft. Done that show for 20 years and been through all the marketoid schizophrenia promoted rewrites for no business value. Now the new "start again" is .Net core and a big chunk of stuff just isn't portable and never will be. Plus the price gouging, licensing hell etc when you have to scale up. Entire ecosystem is a wasteland of unmaintained crap and automation prospects are terrible. Forget it at this point. I'm done.

At this point, I'd pick Java + Spring + Postgres + CentOS. Does most of the stuff you need out of the box, good support available, long product lifespan, well maintained, possible to automate everything. No SPA, just old fashioned dynamic pages with light weight in house JS framework that does partial page replacement, simple validation etc via DOM. Not even jQuery which has been nothing but hell to upgrade so I'm loathed to pick anything more complicated.

PaaS: none. Either in house or old fashioned colo, with HP hardware. If you have to go PaaS, then AWS which seems the most glacial in deprecation so far.

Edit: also desperately avoid any non portable abstractions and vendor specific features. They will ruin you. For example when someone suggests a database engine, hide it behind hibernate and only use the hibernate API!

Edit 2: it is important to assign an exit cost for every decision as well. What's true now is not going to be in a decade.

<comment><USER11> For me at least, I'd definitely go .Net Core. And I'd not have issues using MySQL either. True, there are fads and fashions that come and go, but over the last 15 years I've not had an issue building and maintaining applications of all varieties built on MS technology. Plus, given the current owner of Java, I'd stay well clear of it. Already moved anything that was MySql over to MariaDB.

<comment><USER3> I couldn't possibly consider .Net core on a number of reasons I didn't discuss above. Opt out telemetry, constant direction changes, who is in charge of the project and the general abusive nature of the company running the show towards its customers and end users over the last decade. The list is endless.

I have actually tried to get things fixed on MSFT open source projects as well and even when you get up to Scott Hanselman poking it on github, nothing tends to happen. On top of that many crippling bugs remain unresolved for so far 9 years. We have unreliable tooling, portability problems, all sorts.

On a larger team and product, it's a non trivial time and cost sink.

<comment><USER11> What was the bug that remained open for 9 years? Was it part of the .net framework or a Windows SDK issue?

What sort of projects did you have the most trouble with? Where were your pain points?

<comment><USER3> Sorry was 8 years ... ClickOnce refused to launch on over 2000 machines when they removed download prompting from IE9. This sits between the .net framework and the IE team, neither of which would take responsibility for fixing. Eventually we got a registry fix out of them from bottom line support which turned download prompting back on which was removed from the IE UI but still left in there. The registry fix we had to deploy to hundreds of clients and had a massive support cost. This is still broken in IE11. It was reported on an IE9 beta.

Pain points: large project performance, high concurrency projects, IDE reliability, cost, odd time sinks, bugs in the framework, lack of automation possibility for a vast number of project types (try building VSTO applications on a CI server), deprecations (WWF/WCF changes, AppFabric, Velocity etc) all sorts.

<comment><USER11> Thank you for this response. I'll not counter each point as that will get us nowhere and serve no purpose. I'm just very interested in how two people can have such polar views on the same technology.

<comment><USER3> I think it's a matter of luck and/or scale.

On tiny projects it seems fine but we're huuuuge.

<comment><USER11> I'm not familiar with the size of your code estate so I can't compare. I've certainly worked on some 'big' projects with .Net. In terms of users and application structure.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> You should pick your technical stack depending on what the requirements are. Picking the stack first means you're forever going to be trying to shoehorn the requirements around it, which is a pretty terrible way to design a long term solution.

And then you need to look around yourself at the resources you have now and what they may be 5 years from now. There's no use writing something up in a little used language _hoping_ you'll be able to hire for it later and adding risk by writing something in a language or technology only _you_ know in your company is creating an unnecessary bus factor of 1.

</comment><comment><USER13> We're developing "boring" business applications intended for long (~10y) use:

\- Kubernetes: provides a good abstraction for running multiple apps and services in a cloud, without vendor lock-in.

\- Postgres: proven reliability, best (free) relational db with lots of functionality

\- Clojure: expressive language with huge ecosystem of libraries (since all JVM packages are available)

\- ClojureScript: also a huge ecosystem (JS interop). Because it is Clojure's sister language, we reduce training need an mental ovehead. It also enables code reuse between server and client in some situations (using .cljc files and reader conditionals).

\- React + Reagent + Carry framework: sane view rendering and state management

\- API format: RPC-style HTTPS requests, with payloads in Transit format (so that custom types can seamlessly travel over the wire between CLJ and CLJS)

\- Our own `devops` automation software which lets us deploy K8S clusters and apps inside of it. It also provides abstractions around AWS services like S3, which should allow us to move to Google Cloud ifneedbe. We also wrote it in ClojureScript and run it using Lumo.

\- Minikube + some standin apps like Minio (to run an S3-compatible service in a local container). This enables us to develop and test all of our apps locally without deviating much from our prod stack. We also support a `hybrid` mode where you can run your app locally (using a REPL) but let it connect to other services which all run in AWS. This further ensures similarity with prod env.

I'm aware some components of our stack might turn out to be wrong choices, so we try to limit blast radius by trying to prevent leaky abstractions where possible. (e.g. our apps are not aware of K8S in any way, and could just as well run on a non-virtual machine, with all related services like DB also running as a local daemon).

Our biggest gamble is Clojure(Script), but because of its Java(Script)-interop, the greatest risk there is language stagnation.

<comment><USER14> I think the gRPC team/community has been fast at work on a Golang/Node/Java/Haskell + Docker RPC tool; maybe you'll find some insights at their 'grpc-ecosystem/grpc-gateway' or 'grpc/grpc-web' GitHub repo home pages -- for your API format. It might tie back nice and conveniently to Minikube and K8S -- if gRPC is compatible with Clojure (essentially Java?).

</comment></comment><comment><USER15> LAMP (Linux, Apache, MySQL, PHP).

Boring stack. Easy to get developers on board.

NO frontend framework. Just html5.

NO compicated stuff to start with (SPA, microservices).

Just PHP for processing and a simple template for quick hacking.

And that will keep me 100% focused on just one thing: getting s __t done.

<comment><USER16> VueJS is getting pretty popular in that stack, it can operate in SPA mode like react, but also has first-class documentation for not being the dominant "framework" on your front-end (e.g. if your site's front-end is mostly boring but one or 2 pages need something fancy that doesn't already exist as a jQuery plugin).

</comment></comment><comment><USER17> Your first mistake is that you limit yourself to what's "in", rather than what gets the job done "properly".

For serious long term business apps you want to use multiple technologies that all integrate with each other, where each are used for the tasks they suit best.

</comment><comment><USER18> > Put aside what devs at your company may already be comfortable with

At your peril. Sorry, but it's true.

Any time there is something even slightly amiss it's going to be "Uh oh - looks like Mongo is giving us trouble again."

No matter what the real problem is a slam-dunk scapegoat. And your name is going to be forever attached to it.

Also consider how you're going to deploy & maintain the stack itself. Do you have an ops team that's familiar with deploying war files into a servlet container? Well now on the critical path to this thing going live is them learning how to maintain a new app server, language and deployment process?

That said, at the end of the day - all the tools, frameworks, and languages you mentioned are just fine, with some slight nuance:

DB: MySQL is fine, Postgres has some nice additional features if you need them: GIS, great scripting support, etc

API/App: Stick with the big ones (Elixir? C'mon...). Slight edge to Node because JSON de/serialization is automagic. Slight ding to PHP because... PHP.

Frontend: Who cares? It's going to be outdated in 6 weeks anyway.

Caching: Which ever one you don't have to maintain or think about. Did you choose AWS? Great. Elasticache supports Redis and Memcached.

PaaS: Whichever one supports all the features that you need.

</comment><comment><USER19> > very vital brand new application for your company that needs to be > maintained long term

Long term maintenance is easier if the tools are relatively stable. I think that argues against most (all?) Javascript frontends. Eg, if you started this 3 years ago, your current JS devs would want to throw away your entire JS framework and tooling stack. Odds are if you do it today, they'll want to do the same in < 3 years.

For minimum maintenance issues, I'd pick PostgreSQL for db (data integrity FTW), Redis for caching, and do a server-rendered app.

Of the server-side frameworks I know, Elixir Phoenix is my favorite, but Rails is older and arguably changing less. Probably some Java framework is even more crufty / stable?

Of course, there are other concerns besides stability that might argue for different choices - eg, using Elixir Phoenix means that a lot of your caching would be unnecessary, because the dynamic parts of view rendering are "cached" in compiled functions and the responses are very quick without further caching. And you'd get richer experiences with an SPA, in exchange for a lot more work. But you highlighted maintenance.

</comment><comment><USER20> General answer since this is a general question.

DB engine: Postgres, something more exotic (dgraph, cassandra etc) depending on use case.

API layer: Microservices with grpc, write services in languages which are/will be good for each service's use case. Allows for a relatively easy longterm upgrade path, service rewrites in new languages when staffing or needs require.

Frontend: React, because a) it's great and b) you will worst case be able to reuse a lot of techniques if you decide to use React Native, best case a lot of code. Structure the frontend with lerna and you can avoid the churn of JS build tooling for more stable parts of your application.

Caching: Redis or Memcache

PaaS: I like GCP more but they're pretty much the same dish plated by different chefs.

</comment><comment><USER21> Answering this before reading so I'm not impacted by others. SQL Server, ASP.NET Core, As little JavaScript as possible, No caching initially, Dedicated servers, IIS.

</comment><comment><USER22> > very vital [...] maintained long term

These scream to me two requirements: Stable technology that lots of people understand.

Either DB engine would fill the bill; I would use MySQL because that's what I know. I can make it dance to my tune and can work around its issues.

A typed language like Java or Go will work better in the long term with changing teams. Both are easy to hire for, and the type systems help minimize the complexity of working on an old code base.

The very first question I'd ask of the frontend is "how much does it really need to be an SPA?" An SPA increases the complexity while simultaneously lowering compatibility across devices. If it doesn't have to be a SPA, don't make it an SPA just because it's "in" now. For technology choices, I'd defer to my frontend brethren.

Caching: Memcache or Redis. Both are bulletproof.

I'd likely host it on AWS, with one big caveat: limit your integration with them. If your application can be easily lifted out of AWS and into GCE/Azure/DO/..., you can negotiate some really good prices out of them.

</comment><comment><USER23> Postgres, PHP w/ Slim Framework, Python w/ Django, React, Redis, AWS.

This is a combination of things I'm most familiar with and things I'd build shit in if not for the fact that other devs at my company aren't familiar with it. i.e. We use MySQL everywhere, so I can't just spin up a new project using Postgres for the sake of consistency.

</comment><comment><USER24> For the API layer: If you're sure that the app is going to be for the long- term, and you know what you're going to build (rather than a prototype), choose a SOLID framework.

Having been burned by others, my choice is Symfony. It has set EOL's for each release [1], a strict backwards-compatibility policy [2], is well tested, and has good documentation.

You haven't defined long-term, but I maintain software I wrote over a decade ago, and learned the hard way how important these features are. More than the tech itself.

For everything else: Choose proven technology. Choose databases that aren't reliant on VC funding. Avoid the hype train.

1\. [https://symfony.com/roadmap#checker](https://symfony.com/roadmap#checker)

2\. [http://symfony.com/doc/current/contributing/code/bc.html](http://symfony.com/doc/current/contributing/code/bc.html)

</comment><comment><USER25> Your technical stack should not be frozen. During years, it will probably evolve, either to use some promising features of new technologies, or to still be able to hire. For instance, hiring some Cobol developers is really hard (and then expensive) these days.

More important than technologies is testing. If your whole app is well tested (with both unit and E2E tests), you won't be reluctant to upgrade some part of your system because it doesn't answer your needs. Moreover, it would bring a lot of reliability and would be self-documented. That's the biggest point IMO.

For nowadays mood, we are really glad using React, Node, GraphQL and PostGreSQL for all our apps.

Note: we wrote a blog post about one of our long running customer story, which may interest you: [https://marmelab.com/blog/2018/03/28/1859.html](https://marmelab.com/blog/2018/03/28/1859.html)

</comment><comment><USER26> Node is fine for the frontend -- I'd go with React and React Native personally -- but between NPM issues and a general cowboyishness, I wouldn't go near it on the server-side.

Backend/API layer would be one or more of Ruby, Python, or Java, depending on what my team felt comfortable with. Large, mature communities, healthy ecosystems, overall decent tooling, good support for testing and deployment automation.

Nothing Microsoft. Not going down that road again if I can help it.

AWS hands-down. Google tends to have this pathological distaste towards providing support for their customers, and I don't trust them to not just shutter any of their non-core products randomly one day.

I am _very_ sold on GraphQL or Protobufs as the interchange format over REST.

Databases, hard to go wrong with PostgreSQL. Redis and Memcache for caching.

</comment><comment><USER27> These components form the backbone of the analytics app we are working on.

"DB engine" / Long term state storage: Kafka w/ RocksDB*

API layer: Node/GraphQL

Frontend: React

Caching / Short term state storage: Redis (if/when needed)

PaaS: Something like local Kubernetes w/ possibly some Istio and OSS services such as Spark when needed

*) We are currently building Microservices using local state storage in RocksDB which really (ahum) rocks. We plan to offload serious queries and data slicing to Elasticsearch.

Our current reactive microservice infrastructure is homegrown (due to it being written using .NET Core (and a sprinkle of Reactive Extensions) but if you are able to use Java or Scala you can (in some ways) get a even better version of our microservice infrastructure using Kafka Streams (the KTable and KStream primitives look really nice).

</comment><comment><USER28> Postgres / Django / Vue / Redis / AWS

</comment><comment><USER29> Is your business just starting, or already have some customers? How much funding you have, and what are the skillsets of your staff have?

A safe place to start would be Linux + Postgres + Java Spring or PHP Laravel.

My experience is the market has more Java or PHP engineers (compared to say, Elixir).

<comment><USER30> > the market has more Java or PHP engineers

That's a quantity over quality argument. Assuming there isn't an _extreme_ shortage, I'd opt for a language and/or framework that tends to attract higher quality candidates. Personally, Ruby/Rails feels like it hits the sweet spot there.

</comment></comment><comment><USER31> I think a crucial part of the equation is the context. I'll give my answer with that in mind:

 __DB engine: __

Postgres or otherwise MySQL, unless I 'm planning to do something specific that clearly warrants the use of something else. Too often I've regretted using something more 'exotic' for no really good reason.

 __API layer: __

If this is something I 'll mostly be building myself, definitely Phoenix/Elixir, unless the Rails/Ruby or Django/Python ecosystem has something that I 'need'. If hiring 'cheap' bodies is at all a concern, I'd go for Django/Python or Rails/Ruby. But at this point I'd rather hire that one developer (remote or nearby) who is itching to use Phoenix/Elixir over five of the alternative. And I think any decent Python/Ruby programmer could pick up what I started with pretty quickly.

 __Frontend SPA: __

Just myself: React. If I need to work with others, possibly Vue, but most likely React still. I would probably start out with TypeScript right away, and go for the most 'vanilla' possible everything else (Webpack, Redux, React- Router, Babel, bits of Lodash perhaps).

That said, while last year I would never consider this, I'd probably go for a 'good old' server-side templating approach (w/Phoenix) with some React/Vue components sprinkled in. Even with the best of devs and the best of tools, front-end just strikes me as still too fiddly, too labor-intensive, and too expensive (front-enders often cost more than back-enders, or am I wrong with that impression?) to be worth the effort. Obviously this depends entirely on what's being built though.

 __Caching: __

With Phoenix, possibly none at first. Otherwise I guess something on the nginx side? Not sure if I can see this mattering too much until later in the process.

 __PaaS: __

No. unless there 's a good justification for it. I still lean towards using a VPS or something like that, at least until things get out of hand.

</comment><comment><USER32> No hype, just use simple, proven technologies. No MongoDB, no React, ideally no SPA at all, just plain HTML and tiny bits of Javascript when/if needed.

My personal pick would be a Django app with Postgres as the DB, Django REST framework for the API endpoints (if needed), Redis for caching, and that's pretty much it. Platform is irrelevant as it might change in the long term, so I'll pick whatever is easiest/cheapest at the time and be done with it; the platform can always be swapped out later if needed.

</comment><comment><USER33> Appengine flex, Google Pub/sub, postgres, Java (doors open for kotlin in the future), lombok, Dropwizard, typescript, react, redux, redux-thunk,css- modules, hostedgraphite, sentry.io, circleci.com.

No ops team. Maybe replace Java/Dropwizard with more Typescript and express if the same people will do Frontend and backend.

That's my dream stack. I've used all of this at some point in my career and I really believe their drawbacks are very worth it.

</comment><comment><USER34> I'm not sure about the stack (depends on what you are comfortable with, your requirements...) but:

1\. use something that has been around a long time and is well supported/known

2\. you probably don't need stuff like cassandra or other "big data" data stores (just yet). PostgreSQL/MySQL is plenty fine to start with (and easier to manage/think about).

3\. please use only a single cloud provider.

</comment><comment><USER35> My ideal business app layout (I assume we are talking enterprise, here) would be:

DB: A hybrid of Postgres & MongoDB

API: Hand rolled w/ SparkJava

Front End: intercooler.js (SPAs blow out your complexity budget, which should be spent on business logic)

Caching: Redis

PaaS: the system should be designed to deploy on anything, including internal servers

For a SaaS app, I would look at rails due to the ecosystem and stability, but otherwise it would remain the same.

</comment><comment><USER36> We're 99% Python but for an internal app I would probably go with Postgres, Memcached and Phoenix/Elixir as that's probably where we want to end up in a few years time. For the front end I'd go with HTML and vanilla JS. Front end dev has gotten so mad that picking any framework at this point could turn out to be a bad decision.

<comment><USER31> I agree 100%, but I'm curious how you feel about the state of Phoenix/Elixir when it comes to popularity.

I'm perhaps too inexperienced/young to know how these things tend to shake out.

That said, my impression is that it has enough of a foothold, and with Erlang enough of a solid base, that I wouldn't end up in a situation, say, 10 years from now where the whole ecosystem is a ghost town and I need to move to some other language/framework. And based on my research it's even quite possible that Elixir might end up becoming a formidable player.

But I don't feel certain enough about this to recommend Elixir to a new startup, for example. I'd love to hear other people's thoughts on the matter.

<comment><USER36> I'm old enough to wait until a technology has somewhat proven itself before jumping on it for client work, personal / internal projects are the perfect place to try this sort of thing out though and get a feel for whether you think it can succeed. I've had a pretty minimal play with Phoenix and I liked what I saw in terms of developer productivity and application performance, things looked a bit less certain when it came to CI and deployment though. This was a while back mind, and these areas may have improved a lot since then.

</comment></comment></comment><comment><USER37> For our SAAS we're running:

\- DB Engine: MariaDB on RDS (multiple instances) + Redis for specific use cases. \- API layer: Symfony (PHP) \- Frontend : React \- Caching: Redis \- Ops: Rancher Orchestration on EC2, and a bunch of AWS features like S3, ALB, ...

We had some hiccups here and there, but I'd say we are happy with the stability of it.

</comment><comment><USER38> A No hassle, No worries plan is to use AWS. It's going to scale, and not on you for everything (deploying, packaging). Zero provisioning, and pay as you use. You'll get up and running very fast with low costs, high reliability.

DB: dynamodb

API: API Gateway and AWS Lambda

Frontend: angular 2+, or React

Cache: AWS Elasticache

Blob Storage: S3

</comment><comment><USER39> The stack should be chosen based on the requirements, not just "needs to be a long term application".

Honestly I echo the Java suggestion plus a rdbms. You have a big talent pool, it's well supported and "enterprise stable", and it's multiplatform.

</comment><comment><USER40> Tech or nontech business? Engineering driven org or not? Size of org? Structure of existing team? Relationship of this team to other teams? Overall structure of org? Hiring strategy? Where in culture spectrum does your business require you to be?

</comment><comment><USER41> The investment in the stack should be based on team's skills and strengths. If they are good in Ruby/Rails, then choose that or if they good with JVM based tech, then choose Spring or Play.

</comment><comment><USER7> [https://www.google.de/search?q=choose+boring+technology](https://www.google.de/search?q=choose+boring+technology) :)

</comment><comment><USER42> Ruby with rails or php with laravel, the js stacks are too new and too hip for a long term application, go with a mature stack that doesn't change with the wind

</comment><comment><USER43> bballer start with requirements and _then_ evaluate tools/stacks based on that. Your requirements will help guide your research of what's out there and is best for the job.

All technical disciplines use this approach including ours.

While it _seems_ helpful and fun to see what other people are using, you'll come to find that it's just a salad of product names and marketing gibberish. ;)

Trust your process.

</comment><comment> lambda-powrz Database: Postgres

API layer: PyPy (Flask) w/ Golang (Swagger)

Frontend SPA: Plain HTML/JS with some CSS and webpack for ES6 suport

Caching: Memoization

PaaS: My own home server running w/ Docker

</comment><comment><USER44> DB: Postgres

API: Postgraphql (generate graphql from postgres schema and stored procedures automatically)

Frontend SPA: nextjs framework with reactjs

Cache: Depends on the usage e.g. Redis

PaaS: Heroku

</comment><comment><USER45> I own a dev shops and I also write apps for clients big and small (think big 500 to 5 person startups) for a living.

I used to advocate Rails a lot, but over just the last year, I realized nothing out there can replace my current stack (Phoenix/Elixir/Vue) then yet and I think it's still true today. And, that's a good thing after playing with tons of frameworks out there.

So far, I've tried the following - Express (Node), Play/Scala, Paython/Django/Flask, Ruby on Rails, Phoenix/Elixir.

My pick would be the following (and I'll explain my reasoning):

        DB: Postgres (Google Cloud)
        API: Phoenix/Elixir
        Frontend: Vue + Brunch
        Caching: We don't use caching (haven't had to, will explain a bit)
        Paas: AppEngine (Google Cloud)

I wrote an app for a startup backed by a large VC firm last year and we chose Phoenix/Elixir for it. With Elixir, we were able to find code errors early on, we had the freedom of organizing code in Rails style (think concerns), while not having to fight with opinionated OO.

Elixir is drastically different in the sense the piping makes you think way more differently than working with other languages such as Ruby/Python. An example, this is production code from our E-commerce platform:

          def process_order(user, token) do
            user
            |> mark_order_type()
            |> collect_payment(user, token)
            |> fulfill_order(user)
            |> verify_order()
            |> update_order_status()
            |> clear_cart(user)
            |> email_order_confirmation()
          end

The code is more elegant and really beautiful to write and maintain. As a nice bonus, about last year, we had so built so many drop in libraries that we'd just throw in into new projects and we were good to go since they would just "work".

There was one startup that abandoned their project midway after paying a lot of money, but as a courtesy, I told them I'll keep it online as long as I can, but promising only minor/security fixes to their web app. You'd be surprised how little effort went into maintaining their app. Once it was all setup, it just worked without any hiccups, (yeah, we do our regular checks).

I have fallen in love with Phoenix/Elixir ever since.

Why Vue? Because, it's fast, has a very low learning curve and doesn't involve JSX (Mildly related: [https://twitter.com/thomasfuchs/status/810885087214637057](https://twitter.com/thomasfuchs/status/810885087214637057))

Why Google cloud? Before Google cloud, we were on Elastic beanstalk. There was this issue of dockerized setups where instances would randomly shut down and also updating them would take forever. The only solution was to delete and re- create the instances. This issue persisted as early as Jan 2018, I'm not sure about now. The sole purpose, I repeat, the only reason why you wan't to go the Paas route is because you don't want to do DevOps. And ElasticBeanstalk got us to a point where we were almost doing DevOps. I don't blame Amazon, since Phoenix/Elixir is still relatively new, but unfortunately didn't work well for us.

Between AWS and Google Cloud, AWS has a lot more breadth in terms of the services offered - My favorite is their image processing service. Their (AWS's) official SDKs are also usually more stable. But, I prefer to write my own as most of the time Elixir isn't supported anyway.

Recently Google enabled first class support for Elixir on AppEngine, so it makes it all the more attractive. They also offer a $3000 in credits if you're a startup. I don't have the links, but I know the program is still live as I got one very recently.

Caching: We don't use caching for our use-case. We divide our app into high- load parts and low-load parts. The high load parts are usually the static ones, such as your home page, about us page and so forth. We use Jekyll to push up static sites. For some of them, we use Netlify. But, for the rest, we use S3/Cloud storage. As scary as that sounds, for most of my use cases, I think caching is pretty much overkill for my clients since they don't have their response times as bottlenecks yet (I've only had 6-7 clients who've faced such issues in the last 2 years).

Having said all this, I would also factor in the learning curve to develop such an application. IF this is your first time, I'd rather prefer you stick to something you know already and are familiar with. If this is a mission critical project, I wouldn't gamble with a new stack. So, use my advice with caution :)

<comment><USER31> I'll add that I love the 'with' keyword when piping doesn't cut it. Other than that I've also found that until about a year ago I would've recommended Rails or Django, and now I'm all for Phoenix/Elixir to a fault (as in, I'd even consider using Python packages _from_ Elixir over going for Python because of those packages. Or cut out the middle-man and get a C guy to join the team).

</comment></comment><comment><USER46> Postgres + Go + Vue.js + Redis + AWS

Go with or without any framework (like Buffalo)

Vuejs with Vuex

</comment><comment><USER47> Definitely the most serious, serious tech stack available.

</comment><comment><USER48> First off. As someone else pointed out it depends on the application.

Heavily data dependent / ETL applications have different requirements than CRUD applications. There is not a one size fits all stack, you need to consider the user cases.

For example:

\- We use DynamoDb and ElasticSearch on the back-end because our case is very key-value oriented but also needs faceted search in some use cases.

\- We use Node.js for our user-facing REST API because it was fast to develop and quick to iterate on but we use GoLang for our internal gRPC APIs and front-end because in our case those are the hot paths and where the performance differences between node and Go make a difference.

For an activity feed API (hundreds of thousands of activities a day) I've used Redis with huge success.

The point being is if your app is truly enterprise you'll probably have more than one microservice, and you should pick the right stack for each microservice.

In absence of a hard business requirement that is significantly different between languages choose the framework your team can develop the fastest in and get to market fastest (like our hot path example).

My personal go to is...

Backend: Postgres, Redis, Elasticsearch, DynamoDb

Front-end server and APIs: Node.js with express (no framework), focusing on as few lines of code per microservice as possible

OS: Definitely Linux

Cloud Provider: AWS

Cache: Cache close to the app when possible, if you don't need cache to be synchronized across machines there is no need for a central cache. With that said, I personally love Redis

On the cloud platform note, I'm an AWS guy but they all have their benefits. I try to use as many AWS services as possible to decrease dev time / costs but write the code in such a way where it is abstracted so getting away from vendor lock-in would be possible (painful but at least possible).

All the cloud providers have a service catalog that can shorten your development time if you take the time to learn them use them right. I happen to like AWS value added services best.

With all that said:

\- The most important things you should worry about is getting to market and solving the customer's use case. The stack is not important in 90%+ of cases. If you structure as microservices you can always replace individual services cheaply on a case by case basis once you have customers.

\- Second, "When I ask tech stack I'm talking the whole dam thing" is very unprofessional and I almost didn't answer because of that. I suggest perhaps an attitude adjustment when asking the community for free consulting advice.

</comment><comment><USER49> Consider not doing an SPA. A classical web-app will get you to market sooner with fewer bugs. Here are some big issues with SPAs:

\- Unsubmitted form input is not automatically saved in history by the browser, so you must write code to cache it and restore it again if the user leaves the page. A classical web app can identify all the form elements before rendering, so this functionality is free with a non-SPA.

\- If you use the browser History API to allow navigation within your SPA, you'll have to write code to cancel async requests upon navigation. With a classical web app, the browser will cancel them all for you and provide a handy UI for the user to do it themselves.

\- If you have lots of views within your SPA, it's going to get big and then you'll have to structure your project for code-splitting.

These are the top three issues that I've had with building my SPA and I've spent way more time putting together all the infrastructure instead of building user-facing views and logic because I won't ship a broken app. At this point, I might as well pivot my app to be a developer tool for building SPAs! (No kidding - I'm actually considering throwing away months of work to start over with a classical web app after all this.)</comment>


Suggest HN: make a separate community just for Bitcoin articles - <AUTHOR>

I feel like HN is being taken over by news about Bitcoin. I find Bitcoin fascinating and interesting, but far too many articles are posted about it here. It's just a lot of pro/con churn and very little real news.<p>Bitcoin will take some time to evolve. Don't miss the forest for the trees; don't miss the trees for the bark. <comment><USER2> I find it amusing—and just a little ironic—that the only truly "HN-material" Bitcoin article I've seen ([https://news.ycombinator.com/item?id=6862727](https://news.ycombinator.com/item?id=6862727)) was posted just today.

Look at the discussion that that article triggered. It's HN at its best, discussing Bitcoin in the same manner we would discuss, say, Nginx. From now on, if anyone needs an article to point to to explain the difference between "discussing a politicized technology" and "discussing _the politics of_ a technology," this one should do.

Now we just have to manage a purely-technical discussion of Tor...

</comment><comment><USER3> Suggest HN: make a separate community just for javascript & web crapps.

And for articles about big tech corps (Google, MS, Apple, etc.) doing this and that, repeated in all mainstream tech media.

Same for politics.

</comment><comment><USER4> Suggest HN: make a separate community just for:

X program in X amount of lines Why I like this programming language Patent trolls

</comment><comment><USER5> As a real bitcoin supporter I agree. It's too much for the casual HN reader and the die hard bitcoin users have usually heard the news through other channels.

</comment><comment><USER6> During the last weeks I've been working in a concept like this, so if someone is interested feel free to sign up to the "The Currency" mailing list in [http://thecurrency.io/](http://thecurrency.io/) or send me an e-mail to firstname.lastname@example.com. I count to have some news in the next weeks.

I also appreciate to have some feedback about the landing page: brand, value proposition, etc.

</comment><comment><USER7> There's a large community over at [http://reddit.com/r/bitcoin](http://reddit.com/r/bitcoin). Most of the Bitcoin posts we see here could likely be relegated to a more specific venue like that. I do like seeing interesting Bitcoin posts here from time to time, but it does seem like everyday there's a slew of new Bitcoin posts.

<comment><USER8> /r/bitcoinmarkets is better

<comment><USER7> I haven't been there before. What makes it better? (/r/bitcoin could definitely use a lot of improvement, of course, so an improved sub would be interesting to me.)

<comment><USER9> Also check /r/BitcoinSerious. The sidebar of each subreddit should describe what makes it different from /r/bitcoin.

</comment></comment></comment></comment><comment><USER10> Yes, I am sick of Bitcoin posts, please get away!

</comment><comment><USER11> Yay! Subhns! I suggest news.ycombinator.com/hn/bitcoin

But yes. I agree. The amount of Bitcoin related posts is too damn high.

Edit: Link.

</comment><comment><USER12> Flagging them is probably plenty effective.

</comment><comment><USER13> I'm sick of posts suggesting to resolve the Bitcoin posts issue more than of the posts itself.

</comment><comment><USER14> Already built: [https://news.ycombinator.com/item?id=6867232](https://news.ycombinator.com/item?id=6867232)

</comment><comment><USER15> Agreed ! And the best way to earn bitcoins in the future : make your startup successful !

</comment><comment><USER16> Agreed!

<comment><USER16> Wow, someone down voted me and took away that 1 karma I had, just because I agreed with this topic.

</comment></comment><comment><USER17> God forbid anybody could be interested in other things than you are.

Btw your submission singlehandedly increased the amount of Bitcoin articles on the HN front page by 33%.</comment>


Rust Traits on Generics - <AUTHOR> https://mr-byte.github.io/blog/blog/2015/06/27/traits-on-generics/

<comment><AUTHOR> This is something Rust really got right. It's so powerful, I sometimes find myself tempted towards Rust even when garbage collection and a higher level language would be fine.

Does any GC'd "friendlier" language get traits right like this, outside of Haskell and it's family?

<comment><AUTHOR> Scala is the only one I can think of 24 hours later. Not many languages outside of Haskell have tried to do typeclasses. But there's no reason languages like Python couldn't implement them.</comment></comment>


Covert Communication in Mobile Applications [pdf] - <AUTHOR> https://people.csail.mit.edu/mjulia/publications/Covert_Communication_in_Mobile_Applications_2015.pdf <comment><USER2> Url changed from [http://www.theregister.co.uk/2015/11/23/mit_covert_apps/](http://www.theregister.co.uk/2015/11/23/mit_covert_apps/), which points to this.</comment>


How the Sears Catalog Undermined White Supremacy in the Jim Crow South - <AUTHOR> https://kottke.org/18/10/how-the-sears-catalog-undermined-white-supremacy-in-the-jim-crow-south <comment><USER2> Thought experiment: If Sears had had access to modern e-commerce targeting algorithms a century ago, is it possible that some of the progressive effects of the catalog might never have been realized? Imagine algorithms identifying poor and black customers and promoting products that were already popular for those demographics, making it harder to discover other locally-unavailable products like musical instruments.

<comment><USER3> I think that's already happened.

[https://www.bloomberg.com/graphics/2016-amazon-same- day/](https://www.bloomberg.com/graphics/2016-amazon-same-day/)

[https://www.reuters.com/article/us-amazon-com-jobs- automatio...](https://www.reuters.com/article/us-amazon-com-jobs-automation- insight/amazon-scraps-secret-ai-recruiting-tool-that-showed-bias-against- women-idUSKCN1MK08G)

<comment><USER4> In both of the articles you mention the biased effects were quickly remediated.

</comment></comment></comment><comment><USER5> Reading that Twitter thread got me interested in (at some later time) digging into the minutiae of how the catalogs were designed, produced, and distributed over the years. Once again, the Internet Archive does not disappoint, with what looks like a decent collection of scanned catalogs: [https://archive.org/search.php?query=creator%3A%22Sears%2C+R...](https://archive.org/search.php?query=creator%3A%22Sears%2C+Roebuck+and+Company%22)

edit: Googling for "the history of sears" brings up a site named Sears Archives. I can't tell if it is official or not, but it does seem to be very comprehensive: [http://www.searsarchives.com/](http://www.searsarchives.com/)

</comment><comment><USER6> I keep reading stories about Sears in how it compares to Amazon, but what I wonder and have never seen discussed is whether Sears was a local American phenomenon, or if there were other companies like it globally around the same time?

<comment><USER7> Good question! Turns out Wikipedia has some examples: [https://en.wikipedia.org/wiki/Mail_order](https://en.wikipedia.org/wiki/Mail_order)

</comment></comment><comment><USER8> > The bourgeoisie cannot exist without constantly revolutionising the > instruments of production, and thereby the relations of production, and with > them the whole relations of society. Conservation of the old modes of > production in unaltered form, was, on the contrary, the first condition of > existence for all earlier industrial classes. Constant revolutionising of > production, uninterrupted disturbance of all social conditions, everlasting > uncertainty and agitation distinguish the bourgeois epoch from all earlier > ones. All fixed, fast-frozen relations, with their train of ancient and > venerable prejudices and opinions, are swept away, all new-formed ones > become antiquated before they can ossify. All that is solid melts into air, > all that is holy is profaned, and man is at last compelled to face with > sober senses his real conditions of life, and his relations with his kind. > > > The need of a constantly expanding market for its products chases the > bourgeoisie over the entire surface of the globe. It must nestle everywhere, > settle everywhere, establish connexions everywhere.</comment>


Notorious Kindle Unlimited abuser has been booted from the bookstore - <AUTHOR> https://techcrunch.com/2018/06/11/notorious-kindle-unlimited-abuser-has-been-booted-from-the-bookstore/ <comment><USER2> How much would it cost Amazon to assess the value of each book uploaded to Kindle? Some AI process could be trained on "real" vs "scam" books and attach a score, then humans could review the worst scores and then maybe investigate the authors who post a majority of bad books.

Even after the fact, once a book is generating profits in the Kindle store, one can think of many automated controls:

1\. It shouldn't matter that the old Kindles can't tell the pages you've read (just the max page you reached), if the new ones can, because then, based on the data from the newer Kindles, one can detect books where people only read the first and last page (and then maybe investigate those books manually)

2\. Even if no Kindle device was able to tell the pages you've read, if it's possible to measure the speed at which a reader reached the last page (date book first opened - date last page read), then by comparing to similar books of similar size it should not be difficult to identify outliers

3\. Etc.

My point is, for some reason Amazon doesn't want to police itself, neither in the Kindle store nor in the general store (third-party sellers), which is bad for its brand.

This is puzzling because it's irrational, and one would think Jeff Bezos is more of the hyper-rational type...

So a piece of the puzzle is missing, but I can't see it.

<comment><USER3> One explanation could be that he has simply not gotten around to thinking about the problem yet.

<comment><USER4> Or he's fallen into the trap that popularity (and popularity=revenue) is an adequate signal for quality, if third-party sellers are bringing in adequate sales loads then there's nothing to fix.

</comment></comment></comment><comment><USER5> The sucky thing about this is that the way Amazon pays out Kindle Unlimited reads is through a pool they create each month. They essentially take the size of the pool (say, $20 million) and divide by the total pages read and pay out to each author depending on how many page reads they had.

In other words, scammers like this are taking money directly from authors producing legitimate work.

</comment><comment><USER6> Love the totally genuine comment there from "Diamond Girl" too...

> No real content??? As if. I LOVE Chance's books, they're amazing!!! LOL to > theFivierrr idea, his books are proper legit. You write slander or libel or > whatever it's called. You should be ashamed of your bad journalism, ever > fact checked anything?!

<comment><USER7> I'm pretty sure that is the author.

<comment><USER8> Pretty sure the author bought some reviews on Fiverr as well.

</comment></comment></comment><comment><USER9> If you have an insufficiently moderated platform where users can upload content, and you offer money to content uploaders based on some measurement, you will get largely crap, but optimized for that measurement.

</comment><comment><USER10> Any bets on if the drawing for the jewelery ever happened? That could lead to actual criminal prosecution I think if he wasn't very careful with the wording.

</comment><comment><USER11> There's those multiple-choice adventure books where you have to either go to page 43 or 26 depending on how you want to continue the story. That might be a legitimate way to abuse the system and give the jewellery to your SO :)

</comment><comment><USER12> > Thanks to a flaw in the Kindle platform, namely that the platform knows your > location in a book but not how many pages you have actually read, the > scammers can get paid for a user having "read" a book in Kindle Unlimited by > getting the user to jump to the last page.

Seems an obvious thing that would have been taken advantage of. Is there a rational behind why they didn't want to track something like time per page or time spent within one book? People don't like tracking I guess but statistics like those can be interesting to readers as well.

<comment><USER13> YouTube does this. A "view" is only registered if the viewer has seen a certain minimum amount of the video.

</comment></comment><comment><USER14> Smart stuff from the guy who worked out the scam, though.

<comment><USER15> He's not wrong, he's just an asshole.

</comment></comment><comment><USER16> Not to mention that some people were using this scheme to launder money, though typically with sky high book prices.

</comment><comment><USER17> Lol. The comments section in the article is pretty heated.

</comment><comment><USER18> I'm sorry for the out-of-topic rant:

I got the "we care about your prinvacy" note, in spanish.

What do I have to do to convince the internet that I don't speak fucking spanish? Yes my ip is in spain because I live here.

Is it really so hard for developers in 2018 to realize that IP does not mean language preference?

<edit> And also, stop spoiling spaniards with providing everything translated, this country needs to learn some english

<comment><USER19> Latin american here,

I like to read things in Spanish.

pd: give you a break, go to a walk, talk to nice people.

<comment><USER20> > I like to read things in Spanish.

Cool but kind of irrelevant here. The point is that the website is ignoring the preferred locale requested by the browser and relying on IP geolocation for language. It can be infuriating for persons who do not understand the particular language, and cannot read the content even when they have specified their preference clearly.

<comment><USER19> My point is that is entitlement.

I browse the site and it defaults to English, and my browser is set to en_US as locale.

<comment><USER18> How is it entitlement?

This is an american company, so default language is in english. Which I went to the trouble of learning in order to "join the rest of the world", out of my tiny homecountry.

They have their content available in spanish as well, which is great, but I don't speak it (I do actually but I am so sick of it being forced on me)

All I want is the courtesy of letting me choose the language that I want them to talk to me with.

Imagine if someone irl would only speak to you in spanish cause you're latino- looking</comment></comment></comment></comment></comment>


Guitars for the rest of us - <AUTHOR> http://www.wired.com/2016/04/even-n00bs-can-rock-magic-instruments-new-guitar/ <comment><USER2> The intro to this piece struck a chord with me (pun intended).

My mother recently gifted me her old Martin classical guitar that my grandfather handed down to her. I've been having a musical itch I needed to scratch after going over a decade without really playing an instrument after I had been section leader of the clarinets in HS band class and taken piano for a year or so.

I'm now learning guitar with the help of JustinGuitar.com (seriously amazing totally free site) and a guitar-obsessed co-worker who has been super helpful.

The most jarring experience to me about learning this has been the fact that I physically cannot play certain notes yet, and changing notes is extremely physically challenging. Not just in a muscle memory sense--but literally the process of getting my fingers to move in these incredibly unnatural ways and distances.

I remember back in the day what it felt like to be proficient with the clarinet and not have to think about how to play a note or change keys. Building that muscle memory up again is incredibly humbling, and frustrating as hell.

That said, there's something immensely satisfying the first time you struggle your way through a basic song (in this case Bob Marley's "Three Little Birds" with three chords) and all of a sudden, you can gradually make out the actual song in the midst of all the incorrect fingering and delays in chord changes.

I hope I have the mental fortitude to persevere as I love the sound of guitar and the idea of playing one. I expected a learning curve with memorizing notes and finger positions and such, but christ did I not envision it being anywhere near this difficult to physically play. When I see a talented musician playing I now have massive newfound respect when I see them whipping through chord changes during 16th notes for example.

Not much more to add here, but seeing things like this that dumb down the experience are disappointing. Sure it might be a way to help people have early success, but I'd guess those people are a lot less likely to jump to the real thing if they seek out the easy road like that.</comment>


Paris Mayor: It's Time for a '15-Minute City' - <AUTHOR> https://www.citylab.com/environment/2020/02/paris-election-anne-hidalgo-city-planning-walks-stores-parks/606325/ <comment> pi-err I live in Paris and whatever you think of the current mayor, this is pure marketing babble for the elections next month.

Paris has always had this very dense city core where 99% of daily life is 5-10' away. It's a great concept for dense metropoles, but it only works because the city is so small: 100 square kilometers in an ocean of much lesser density. 80% of "Greater Parisians" live outside Paris itself.

Unfortunately there is no actual representations for 80% of those "outside Parisians" since they are split between hundreds of small cities with individual political dynamics. Pure game theory as local governance.

<comment><USER3> What is considered to be Paris (100km2) is a lot smaller than what people consider to be London (1500km2) or NYC (800km2 of land).

Yes. If you're rich enough and can afford to live in Paris everything is about 15mins away.

If you leave "outside" then be ready for commutes that get proportionally cheaper as travel distance increase. A commute time of one hour or less is considered good. It's not rare for people to commute for 2 hours or more, for each trip.

The problem is that the mayor of Paris is elected to represent the wishes of the privileged few that live in the center and cares little about commuters.

The anti-car attitude of the current Mayor (Mrs Hidalgo) reflects this. And if you look carefully at the data it looks like air pollution has reduced in areas where cars were removed but has increased elsewhere. It's hardly a win for air pollution, but if you live in Paris the river side is now for pedestrians and not cars. So yeah. Real nice, if you can afford to live there.

<comment><USER4> > And if you look carefully at the data it looks like air pollution has > reduced in areas where cars were removed but has increased elsewhere.

Are you trying to imply some sort of causation here? Because I can't see how decreasing car use in the city centre would increase usage outside it.

> It's hardly a win for air pollution

Decreasing the use of (internal combustion) cars in city centres is a huge win for air pollution as that is generally where traffic is most concentrated and thus air pollution levels are highest.

<comment><USER3> Car use in Paris has just shifted around. For it to disappear people would need credible alternatives. Remember most Parisians don't have a cars and have fantastic public transport. It's workers and commuters from far away that need vehicles.

Basically the river side used to be like a highway where you could travel from West to East and vice versa. This is essentially gone now. But all the traffic has moved more inland. So the pollution has reduced near the river, but increases on the East/West boulevards. It's possible that traffic overall may have decreased, but the boulevards are full of intersection and traffic lights, whereas the river side highway was basically devoid of them. So overall for pollution, it's really hard to see a win.

<comment><USER4> Paris' greatest asset is its river, the Seine. Devoting a section of one of its two banks to a car highway is simply insane. If the city wants good uninterrupted travel East-West to replace that riverside highway it should build a tunnel.

<comment><USER3> It's obviously great if you live in Paris, especially when the weather is good. I have hanged out there many times in the summer even though I don't live in Paris anymore.

But if you're one of these commuters who has to drive, and use that specific east/west route, then it's an every day annoyance. You're reminded at every traffic light that your commute has increased by X minutes.

I think the solution is obviously to improve the public transport situation especially for far-away suburbs. But it's hard. It costs a lot, there are political animosities at play, and fundamentally Paris citizens do not really suffer from car commute issues since they don't need cars.

</comment></comment></comment></comment></comment></comment><comment><USER5> That's essentially the concept of many cities in Europe. I live in Berlin for example and I have almost everything I need within 10 minutes of walking or 5 minutes of cycling: Supermarkets, pharmacies, doctors, restaurants, electronics stores, schools, kindergardens, ... The downside is that you tend to become used to your small microcosm ("Kiez" we call it) and rarely leave it. I can't recall for example when I went to East Berlin the last time, as distances can still be large and it can take one hour in public transit to go from East to West, depending of course where you want to go.

I also lived in Paris for more than 3 years and it also has great walkability, more so than Berlin even because the city center is much more compact (you can cross it by bike from North to south in 30-40 minutes I'd say). The metro is also super efficient, you can get everywhere "intra muros" in 30-40 minutes.

If you live outside of the center of Paris (which I also did for a while) it's less ideal though, as the public transportation quickly becomes much more sparse and you will need a car to get around easily. As most people in the Paris region actually live in those areas I'd say there's still much work to be done there.

<comment><USER6> > _The metro is also super efficient, you can get everywhere "intra muros" in > 30-40 minutes._

Yes. Both times I was there visiting, we didn't bother with even the buses. The Metro was usually a short walk, and a short wait.

<comment><USER7> The metro is like elementary school. You're a professional when you can hack the metro and buses and get anywhere in <30min. While m pretty god with the former my spouse, who prefers the buses, can get to any part of the city with the least amount of walking.

</comment></comment></comment><comment><USER8> > In Paris, this isn't necessarily such a tall order. The mayor oversees only > the 2.2 million residents of the city's heavily populated historic core, > which already enjoys some of the use-mixing that the 15-minute-city concept > encourages, thanks to its pre-industrial roots.

This is the main problem of Paris and of Hidalgo. For most practical purposes Paris is a 10 million inhabitants city, yet only 2 get to vote for the 'real' mayor, those who live outside the historic center are fragmented into a bunch of smaller counties and are also generally poorer than 'real' Parisians.

When Hidalgo banned cars on the quays, Parisians were very happy, while commuters from other counties had to add some time to their commute and were furious.

Look at this [0] plot, see how the green line stopped tracking the blue one? That's your problem...

[0] [https://upload.wikimedia.org/wikipedia/commons/6/66/Croissan...](https://upload.wikimedia.org/wikipedia/commons/6/66/Croissance_population_Paris.PNG)

<comment><USER9> From the article : "In her re-election campaign, Mayor Anne Hidalgo says that every Paris resident should be able to meet their essential needs within a short walk or bike ride."

"Paris" is defined as Paris intra-muros + the Boulogne and Vincenne parks, which are limited in space and was saturated long time ago. You are a "Paris resident" if you live inside of the City of Paris (the green line of the plot).

The chart is showing "Aire urbaine" and "Unité urbaine" which are another way to draw geographical limits and are only used for statistical purposes, and they include the "Region of Paris", or "Ile de France". Obviously, the region is expanding like any other capital's region in the world, so that plot exactly shows nothing.

The sentence "For most practical purposes Paris is a 10 million inhabitants city" is fake news. People living inside of the City of Paris are asking to be able to use bikes or other transport means, but all the cars coming from _outside_ of Paris everyday are making it difficult.

Stop confusing the Region of Paris and the City of Paris. People living inside the City of Paris (the Parisians) have right to elect a mayor who will defend them. If you live in one of the adjacent cities, go elect a mayor that will locally improve your quality of life, but (real) Parisians are sick of the traffic inside their city and no other city has right to decide for them.

<comment><USER10> The point of democracy and electing mayors is to empower people to change their destiny. The chart shows that there population of the larger Paris area is increasing, as you yourself confirm:

> the region is expanding like any other capital's region in the world

Why are new people coming there though? Are they coming to tie their lives to the City of Paris, but they must settle for the larger region because of the saturation? Or are they coming to join the Region of Paris because of its merits excluding the City?

If it's for the former, then they deserve some democratic influence on the place that brought them there, and the chart shows that the division into City of Paris and the rest denies the newcomers that influence.

<comment><USER9> It's only my own opinion, but I believe there is too much centralization of national, international and diplomatic institutions inside the City of Paris. I am _for_ more decentralization of businesses and powers across the Region of Paris and across other cities of France. House pricing clearly shows that the City of Paris is a gravity center in terms of everything, which leads to many of the current traffic and pollution issues imo. Maybe a decentralization of France's institutions, powers, businesses etc could help it?

Edit : Idea : at each new presidential term, move all institutions and the french "white house" to Lyon or Marseilles, second biggest city of France. At the next presidential term, move everything again to Paris.

<comment><USER3> Or Toulouse ranked 4. That may force the government to invest for some infrastructure. I don't think we'll ever a TGV there.

<comment><USER11> Oh, come on, it's only about 10 years away [1]. Granted, it's been 10 years away for about a decade, now.

But that leaves the question of whether Toulouse will get a TGV before nuclear fusion is invented, Thomas Pesquet walks on Mars, or anyone actually start _working_ on an Hyperloop instead of faking it [2].)

[1] [https://actu.fr/occitanie/toulouse_31555/pourquoi-projet- lgv...](https://actu.fr/occitanie/toulouse_31555/pourquoi-projet-lgv-entre- bordeaux-toulouse-est-nouveau-sur-rails_25069934.html)

[2] [https://actu.fr/occitanie/toulouse_31555/hyperloop-piste- ess...](https://actu.fr/occitanie/toulouse_31555/hyperloop-piste-essai- assemblee-tests-capsule-bientot-commencer- toulouse_21721100.html?utm_source=actu.fr&utm_medium=alireaussi)

</comment></comment></comment></comment></comment></comment><comment><USER12> In contrast, I've always considered Los Angeles to be a "45 Minute City", but by car. Everything you need is a 45 minute drive from wherever you are now.

The beach is 45 minutes away. It's 45 minutes to work. Your friends are each about 45 minutes away, in different directions, and the downtown bar you meet at on Friday night is 45 minutes away. You can even get out into the mountains on angel crest highway in about 45 minutes.

But unless you want a CVS pharmacy or a Starbucks, nothing is close by. Ever.

<comment><USER13> And then there's NYC - The $20 City. Any time you step outside of your apartment, you'll inevitably spend $20 on something.

<comment><USER14> And Manchester (UK) the 10mm city. Every time you step outside you will absorb at least 10mm of water.

<comment><USER15> Stockholm is the "next island" city. You live on one island and everything else is one another island.

</comment></comment></comment></comment><comment><USER13> _Paris needs to go one step further and remodel itself so that residents can have all their needs met—be they for work, shopping, health, or culture—within 15 minutes of their own doorstep._

As someone that has spent a lot of time living in Paris, this is already pretty much true, at least within the Périphérique. The main issue in my experience is the lack of green space; there are surprisingly few parks in Paris.

<comment><USER16> Because Paris is really small and the large parks are just outside Paris : Bois de Vincennes & Bois de Boulogne are each at least twice the size of Central Park I hope you didn't miss Parc de Buttes Chaumont, Parc Montsouris & my favourite : Cimetière du Père Lachaise (yes, a cemetery ... I recommend going at spring and enjoy how green it is)

<comment><USER13> Yes yes, I have been to all of those and lived right next to Buttes-Chaumont. But the city in general always felt like it lacked green space. Especially if you make a large circle around Opéra - for 2-3km you really don't have anything that isn't small or full of people.

That said - Buttes-Chaumont and Le Jardin du Palais Royale are some of my favorite urban parks in the world.

<comment><USER17> Les Tuileries are less than 1km from the Opera. Parc Monceau is 2km away.

<comment><USER18> I was there 4 days ago. It is far from green. Sure, it's an open space without buildings and has a few trees. It is _not_ , however, a green space.

</comment></comment></comment></comment></comment><comment><USER19> I am curious if the pickpockets still run rampant all over the tourist areas and subway. Few years back in 3 days:

1\. Dad ran into undercover cop who on subway who told him to watch his stuff better :o

2\. Got his phone stolen next day on subway, I guess cop was right

3\. I witnessed the typical distract, grab and run.. good thing someone threw trip and got the runner to drop his prize

4\. Had to deal with 3-4 typical: "please sign this petition while my partner tries to come up from behind and snatch your crap thing". The East European scowl and choice mat solved it

<comment><USER20> Put the valuable stuff into your trousers front pockets. I'm doing this for years, it works better than having anything in my back pockets. Though being 193cm tall might deter perps from trying something funny.

<comment><USER21> Perhaps insist on better law enforcement than blaming the victim. Pick- pocketing, by many accounts, is rampant in Paris and is just a sign of how lax policing is. Its not something to be even modestly indifferent about.

<comment><USER22> Giving hints is hardly victim blaming.

</comment></comment></comment></comment><comment><USER23> I lived in Japan for a few years and I felt like they've nailed this concept.

Everyone I knew across different parts of Tokyo lived within a 10 min walk of a supermarket, school, nursery, doctor, train station etc. It worked really well.

<comment><USER24> 10 minute walk away from a supermarket only gets you so far when you spend an hour in one direction commuting since you probably go to work more often than you go grocery shopping.

<comment><USER25> Interestingly, daily grocery shopping is not uncommon in Japan. Probably down to supermarkets being close and kitchens being small.

</comment></comment></comment><comment> d--b It's all an election stunt to try and justify that her war on cars won't affect Parisians. Ie. If you have everything you need in a 15min walk, you shouldn't suffer that the traffic is reduced.

But the things you occasionally need are getting harder to get. Plumbers, electricians don't want to come to the city anymore. They will facture in the awful traffic and the fines they get for the lack of parking space. Basically no one will come to your apartment for less than 500€. There potentially are business opportunities there.

<comment><USER26> Does Paris not issue parking permits to craftsmen? German cities offer special parking permits to businesses that need to have unwieldy or heavy gear with them at their customer's place. The yearly fee is in the low hundreds (maybe 250€ even in the larger cities) and usually includes free parking and that even in places where most people normally would not be allowed to park at all, e.g. on Anwohnerparkplätzen (residential parking spaces where one would normally need a permit only available to people living in that street). It might even allow to enter pedestrian areas in some cities.

<comment><USER27> > Does Paris not issue parking permits to craftsmen?

No

<comment><USER28> Yes, Paris has similar permits. Not free, though.

But the issue is not that but lack of parking space. A permit only allows them to park in actual parking spaces. Most of the time there aren't any available...

</comment></comment></comment></comment><comment><USER29> This seems possible in many major metropolitan areas, with the significant caveat that in order to live it most would need their wealth to be unlinked from their earned income.

Zone 1 and most parts of Zone 2 London close to stations are like this.

I've just looked it up out of interest and it makes me feel fairly privileged!

My flat has supermarkets, restaurants, a pharmacy, a bookshop, banks, a library, museums, one of the biggest parks in London, a hospital, schools, multiple tube stations, a GP, a dentist, etc etc within 15 minutes walk (actually I think 10 minutes).

But not everyone (in fact, barely anyone) can afford to live in those areas. Even if they could afford it in the sense of having the income to spend a ton of people choose to live further out and have such things as freehold homes, gardens, etc.

<comment><USER30> Yeah I think you nailed it with the idea of people wanting to live further out to get more space.

Dense urban living is fun when you are energetic (and probably young and probably single and probably with lots of like-minded friends) and you spend 95% of your time working and socializing, and you basically just use your home as somewhere to sleep and get washed in between the office and the bars/restaurants/gyms/etc

However, this is not the same for everyone. I _dream_ of the day when I can live in a house with its own garden and where I am not physically sharing walls with other people's homes. At least in London you won't get that anywhere near your work unless you are absurdly wealthy.

</comment></comment><comment><USER31> I live in Milan, 3/4 distance from the very center, and it's basically like that. I've got 4 supermarkets in 10 minutes walking range, metro station at 3 minutes, some healthcare within 5 minutes (but no ER), countless shops. Cinema and theaters at 30 minutes by metro. I'm self employed and working mostly from home so it's a very good experience.

I didn't enjoy it as much when I wasn't self employed. I've been working on the other side of the city for many years, about 1 hour either by car or by public transport. Where one works makes all the difference but (this is a tangent) also how one works. I've been working at 10 minutes from my home for a couple of years and it didn't feel much different. I was confined in my office all the day long. It's the normal experience for most of us but it would feel like living in a prison now.

</comment><comment><USER32> It's quite refreshing to ensure that there's a push for this for the most part on HN, which is a rather affluent community. I'm not sure about the state of housing here too, but I am willing to wager that we live, for the most part, in a high density area.

Working to have all of our expectations for a good life walkable, scootable, or bikeable is the way we should be designing our cities.

</comment><comment><USER33> I am interested in what the tipping point of density is - it is something I think Strong Towns idea has right but there are several factors (actual physical density of homes is key, but planning laws / zones matters, as does disposable income and actual physical built stock).

I would also ask if new cities (China, India) what their planning / zoning priorities are?

</comment><comment><USER34> I had traveled to Paris a number of times and decided to take a drive across parts of France. Armed with a classic Michelin guide book, I rented a car at one of the train stations in central Paris. My plan was to simply drive and stop every evening around 5:30pm using the guide book to find a place to stay.

I was quite surprised that I ended up still in greater Paris on the first evening. Between stopping to eat, taking photos, and navigating (pre-GPS), I was still in Paris the first night. Paris is a huge, and lovely, city.

As an aside, it was a great trip. I simply drove south for around 8 days and picked a different route to drive north back to Paris to fly home. I stumbled across so many interesting places, the prehistoric caves of the Dordogne, the dramatic village of Rocamadour located on a cliff, and many other memorable places.

</comment><comment><USER35> The center of Paris is something like 13-14k€/square meter... The truth is Parisians with average revenues (for Parisians, not for French people) more and more live close to the suburbs (13th, 15th, 18th, 19th, 20th districts) around Paris and the center is full of company's head office, shops and restaurants. So the picture displayed in the article should figure inhabitations on the outside skirts and accommodations in the center.

At the national level, Parisians are an average really rich population and living inside Paris will continue to grow more and more difficult because living in Paris is nowadays a luxury. And nothing will change this situation in a close future.

</comment><comment><USER36> Now find a way for people to actually afford living in Paris, so they can reach things within 15 minutes, a lot of people live outside Paris and work inside Paris, resulting commute times of 2 to 4 hours a day.

</comment><comment><USER37> I wonder how many more jobs are needed to make this possible. You'd need more of everything, plus longer/staggered open hours (who decides what hours make the most sense, for which districts?).

On the plus side, you'd have more convenience and less need for vehicle transit. On the potentially negative side, how many of these jobs would realistically pay a living wage?

<comment><USER38> She's just a politician trying to get reelected, don't expect too much out of this.

<comment><USER3> Most of Paris is basically like that already, and was before she was even mayor. Promising to the happy few who can live in Paris at 15mins while commuters from outside need >= 1hr. Turns out commuters don't vote.

</comment></comment></comment><comment><USER39> They should first figure out how to make average worker spend less than one 55 minutes commuting by public transit each way.

[https://www.thelocal.fr/20160418/parisians-spend-23-days- a-y...](https://www.thelocal.fr/20160418/parisians-spend-23-days-a-year-on- public-transport)

<comment><USER40> That's pretty much exactly what they're trying to do.

<comment><USER41> And that's not feasible. You can't just reduce the average commuting time to work by 40 minutes magically

<comment><USER42> The city / region has been working on that by decentralizing major government and business institutions. By pushing them out of the core in to neighboring suburbs it allows those employees a real chance at living near work in more than 15m2.

At the end of the day the only real solution to commutes / crowding is going to be spreading the load out on more communes and cities.

</comment></comment></comment></comment><comment><USER43> At the same time, there is a 30m2 (323 sqft) Parisian apartment for sale for e1.2mm (USD 1.3mm). Not sure these things are quite compatible...

<comment><USER44> At 1% interests rate, that's e12.000 a year, e1000 a month. Not bad.

<comment><USER45> Is it 1% interest rate over there?

<comment><USER46> Yes, in Eurozone countries, 10 year fixed mortgage are typically 0.99%.

It's amazingly cheap. Down from 3.5% ten years ago.

The downside of low rates is house prices correspondingly very high.

<comment><USER47> Except here in Ireland, unfortunately; absolute lowest mortgage available is 2.3%.

Repossession is especially difficult here, which raises the risk for the lender, and the banks unwisely gave out ECB trackers (as opposed to the EURIBOR trackers more common elsewhere) back in the day; some of these can be as low as 0.5%, so everyone else has to pay for that legacy.

</comment></comment></comment></comment></comment><comment><USER48> This is utterly, completely dependent on the demographics of the neighborhood, which is way more harder to change than zoning.

</comment><comment><USER49> This is essentially Copenhagen but at 5-7x (?) scale. Very cool.

</comment><comment><USER50> More convenience stores will be needed. Ones with longer hours.

<comment><USER51> Do Parisian convenience stores close at night? Chinese urban convenience stores don't; even here in the American suburbs CVS is open 24 hours, and so is Safeway.

<comment><USER52> >"even here in America"

Not to derail the conversation, byt why the 'even'? 24h-stores seem like an inherently american concept to me (I'm german, so France is right around the corner)

<comment><USER53> When it comes to opening times of stores, us Germans are way behind everybody else...

<comment><USER54> I wouldn't say "behind" in that context. I do appreciate the convenience of 24h stores, but I don't see them as a progress for workers rights.

<comment><USER55> If the owner of a store wants to open it for 24 hours and he or employees are willing to work, how is that bad for workers rights? What's bad for workers rights are people that would like the freedom to work a late shift or early shift but can't because some do-gooder is trying to "protect" grown adults from making their own decisions.

<comment><USER54> > If the owner of a store wants to open it for 24 hours and he or employees > are willing to work, how is that bad for workers rights?

That would be fine, but what is going to happen is that many workers will have to work night shifts unwillingly. It's bad for their physical and mental health.

Suppose you have a town with two stores. First store is willing to open 24 hours. Second store may have to do the same to compensate the loss of customers, and the workers there may have to work night shift even if they don't want to (I actually witnessed it first hand in my neighbourhood).

This is called a negative externality, and it is a well-known defect of free market. Even though you would think that opening a store 24h only impacts you and your customers, it negatively impacts other people.

This is a subjective opinion, but I would argue that the convenience of having 24h stores isn't worth the cost for the workers. Unfortunately, I think that I'm in the minority and that eventually we'll cross that line in Europe too, and it'll be hard to go back.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> With Hidalgo, Paris is becoming more and more an "Elysium" movie city-model: only a few decide Parisian of what will piss off everybody else. Remember the end of the movie ? ;-)

Btw... Elysium and Elysée - the Palace of the French President... in Paris - have the same root. If it can help to understand...

<comment><USER56> I would be happy to know why some people downvoted my comment, just to understand.

I live 100m from Paris, in the suburb, so I'm a bit concerned (and knowledgable) about this subject. And the current - and maybe next - <USER2> mayor is only working for her own electorate (logical).

Problem is: Paris is a central city/region. You can't just "live around it". So basically when Hidalgo close the "quais de seine", it's fine for people living in Paris or tourists but it's a PITA for people from one suburb to the other one. When Hidalgo wants to shutdown the "periphique", it won't matter to parisians and tourists in Paris, but will make a really big difference for people working and living outside Paris for whom crossing Paris is the shortest way.

BTW, 90min from work to home is not really unusual in Paris suburb, and I would be the happiest man on earth if I could had just 30 min between work and home.

Moreover, Paris is becoming more and more a car-adverse city (nowhere to park, except for a lot of money) but public transportation are far from compensating this (for example: still no public transportation all night long... except one saturday night every month on a few lines... as an experiment).

So: no cars, not enough public transportations, and a central town (by design and history).

</comment></comment><comment><USER57> Cities are terrible places to live. To prove my point, can you walk to a natural area (beach, forest, mountain, etc) within 15 minutes? Of course not, other than maybe a tiny manicured park full of people. That "green area" pictured in the diagram will be the only green area, it will be a flat park of some sort, and it will be your only choice of place to visit. It will be more like a museum for trees than any kind of natural habitat.

That doesn't meet anybodies "needs". This is all just dressing up ways to reduce the costs of humans. Governments are just a collection of large companies (their controllers), who run the world the same as if it is a business. The citizens of the city are a cost, and these are marketing campaigns to get them to accept cost reduction measures.

Also, as I am getting downvoted, I may as well point out that Paris itself is an especially terrible place to live. In fact, I don't know many parisians that live there, and I have never met anybody that likes it. HN obsession with density and walking is hilarious.

<comment><USER47> I mean, it's all down to personal preference, really. I'd hate to live somewhere where I couldn't walk or get around by rapid public transport. Car oriented suburbs (or, worse, rural areas) are my idea of hell. And if I want to go to a mountain or a beach (which is something I want to do way less than, say, going to work or the supermarket or going for a drink with friends, all of which are walking distance) I can get on a train.

Mind you, this is a city of 1.5 million people; mega cities like Paris have their own challenges.</comment></comment>


Profiling Native Python Extensions - <AUTHOR> https://www.benfrederickson.com/profiling-native-python-extensions-with-py-spy/ <comment><USER2> Author here. It's worth noting that since I wrote this post, py-spy has gained the ability to profile multiprocess python applications - and can also now show local variables in the dump command.</comment>


Budget Home Arcade Machine - <AUTHOR> http://jsante.net/home-arcade-project <comment><USER2> I've built pretty much the same thing using a RPi3, a USB adapter with two SNES controllers, and a wooden cabinet with two arcade sticks + lots of buttons + another USB interface, with the RetroPie ([https://retropie.org.uk/](https://retropie.org.uk/)) OS distribution.

It won't play any games newer than say, PS1 (due to CPU limitations and the storage I have available) - but I've got every NES / SNES / Atari2600/5200/7200 / Intellivision / Gameboy / GBA game/ROM ever released, and an older MAME ROM set, all on a 16G SD card with about 9G free.

It will also do some DOSBox stuff and lots of other 8bit platforms that I don't have any ROMs installed for.

RPi: $35ish

SNES controllers: $15 off ebay

SNES USB adapter: $12 off amazon

2-player MAME joysticks/buttons parts kit w/XinMo USB encoder: $55ish off eBay

The most expensive part of the whole thing was the 2-player MAME wooden cabinet (predrilled holes, etc), which was about $75 from an eBay seller.

Display is whatever HDMI-input device I have lying around. Using a 24" monitor at work right now (building one of these for the office lounge).

My grand total: around $200.

<comment><USER3> Woah, can you please provide a little more info on the software and OS you're using on the Pi? I've got a good Windows-based setup using MaLa as a frontend, but I'd love to do this on the Pi.

<comment><USER2> [https://retropie.org.uk/](https://retropie.org.uk/)

</comment></comment></comment><comment><USER4> For cabinets, if you don't mind a weekend project, I've found the Vigolix to be a fantastic DIY cabinet you can build from a single sheet of plywood:

[http://www.instructables.com/id/A-Super-Easy-Arcade- Machine-...](http://www.instructables.com/id/A-Super-Easy-Arcade-Machine- from-1-Sheet-of-Plywoo/)

I also went with the Tankstick, and am now entering my 6th month of heavily abusing it (my 4-year-old beats the heck out of it) and it still works great. I was able to just cut a hole in the Vigolix and drop the Tankstick right in. The latest one with the trackball is really fun for games like Centipede and Tempest:

[http://shop.xgaming.com/products/x-arcade-tankstick- trackbal...](http://shop.xgaming.com/products/x-arcade-tankstick-trackball- usb-included)

I first ran it on a brand new LCD screen, but so many of the games look terrible on it. I eventually bought a 24-inch CRT from a used electronics store for $100, and it made a huge difference. I would love to get a larger CRT, but they seem to get exponentially more expensive the larger they go.

For MAME ROMs, I went with an 8-year-old torrent of 6,000 ROMS, which had screenshots and config files all ready to go. There was some iffy software in the MAME files that Windows flagged as spyware, so I took the ROMS and screenshots and dropped them into a fresh MAME download (I had to grab an older version of MAME because the config files weren't compatible with newer versions). The MALA front end is fantastic, and I easily configured it with a Star Trek LCARS theme. I've been exploring this collection for months now and keep finding favorite classics I had completely forgotten about.

My only complaint is that no matter what version of MAME I run, I seem to only get about a 50/50 chance of any ROM I download running. I know I'm not the only one who has this problem. Otherwise, this is very fun hobby preserving these old titles that would otherwise be forgotten.

</comment><comment><USER5> I went through the process of attempting to build my own arcade cabinet in the mid-2000s and failing spectacularly. [1] I think I'm too much of a perfectionist to accept my own woodworking as "good enough" (even though in retrospect the results were not terrible and could likely have been finished by someone skilled).

Lately I've been researching pre-built kits to save some time and sanity. From what I can tell, the folks at Northcoast have decent pre-built cabinets [2]. Has anyone tried those out?

[1] [https://www.google.ca/search?q=site:grack.com+cabinet](https://www.google.ca/search?q=site:grack.com+cabinet)

[2] [https://www.mameroom.com/webstore.asp?productid=UAIIKIT&cate...](https://www.mameroom.com/webstore.asp?productid=UAIIKIT&category=136)

<comment><USER6> There's also Polycade: [http://www.polycade.com/](http://www.polycade.com/)

<comment><USER5> I have a friend who was considering a cabinet of this style. While I really like the tiny footprint, there's something about playing classic arcade games on a big boxy cabinet that evokes a real nostalgia dopamine response in me. That's a great option, though - thanks for pointing it out.

</comment></comment></comment><comment><USER7> I made an arcade machine for my dad (though far from budget) for Christmas in 2013 and chronicled the build here: [http://mattparkes.net/project/arcade- machine/](http://mattparkes.net/project/arcade-machine/)

I'm about halfway through building one for myself (following the same build with a few refinements).

</comment><comment><USER8> These MAME cabinets are neat, but there's also something magical about restoring and owning the original single-game cabinets.

My favorite video channel on the subject: [https://m.youtube.com/user/blkdog7/channels](https://m.youtube.com/user/blkdog7/channels)?

<comment><USER4> Although I went the MAME route, I have immense respect for people who restore the old cabinets. There really is nothing like stepping up to the original Star Wars, Space Harrier, or Tron cabinet. I wish I had the room for so many cabinets, and I wish arcades were a viable business model (Dave and Busters aside) to play with these old machines.

</comment></comment><comment><USER9> I've been postponing building my own for some time now for one reason only. Monitor! There are three issues that bug me. First, I really like CRTs, but I can live without one. Second, I wan't a big 4:3 and that is not going to happen. There are some 16:10 options, but not as big as 16:9. Third, which is more important to me, is that I want an elegant cabinet with rotating monitor that rotates between horizontal and vertical (tate) mode. This is important for shmups which I enjoy playing. Until I resolve this, I won't go forward.

<comment><USER10> We still buy a few CRT monitors from time to time (museum field) and get them from Dotronix. Not cheap, but you can get big ones:

[http://www.dotronix.com/dnrSeries.html](http://www.dotronix.com/dnrSeries.html)

<comment><USER9> Are those new, as in still in production? If so, that's fascinating.

<comment><USER10> Yes.

</comment></comment></comment></comment><comment><USER11> A few years ago I built a cabinet for my family. I used equipment purchased off of Ultimarc ([https://www.ultimarc.com/ipac1.html](https://www.ultimarc.com/ipac1.html)), did the woodworking myself. I'm a _very_ inexperienced amateur woodworker, but I _love_ doing it. It's a fantastic hobby to contrast against a day of programming.

Here's a photo album of the process. I picked up the Donkey Kong marquee later as a gift for my wife at Christmas time - she's the Donkey Kong Pro in our household.

Of course, when I look at it - I only see the flaws. I'd love to get a second shot at building it!

[https://www.icloud.com/sharedalbum/#B0Q5qXGF1OaZiJ](https://www.icloud.com/sharedalbum/#B0Q5qXGF1OaZiJ)

<comment><USER12> Well done, looks great!

Don't worry, I work in a structural steel fabrication workshop - everyone only ever sees the flaws.

</comment></comment><comment><USER13> Here's mine:

[http://imgur.com/a/hzE1x#0](http://imgur.com/a/hzE1x#0)

</comment><comment><USER14> One way to add a more "authentic" feel on an LCD (but isn't very cheap) is to use a scanline generator: [https://www.youtube.com/watch?v=vscKaVByjRU](https://www.youtube.com/watch?v=vscKaVByjRU)

</comment><comment><USER15> For a step by step on building an arcade box check out iliketomakestuff.com. Lots of fun woodworking projects on his site.

[https://m.youtube.com/watch?v=K3QXLQ1UXqs](https://m.youtube.com/watch?v=K3QXLQ1UXqs)

</comment><comment><USER16> I would like to hear everyone's opinions of the various UIs for MAME. I've been searching for a hands-off, games only interface for choosing, one where it won't accidentally quit or pop up the control config window during gameplay, and frankly, every MAME front end I have ever used is terrible in a completely unique way.

<comment><USER4> I've found MALA to fit my needs quite well, but I'm sure you've already tried it. I was going to post a link, but Chrome is giving me a malware warning on the site now. It's definitely not "hands-off," as I wanted an LCARS display from Star Trek The Next Generation on it, and had to spend an hour positioning the sceenshots and title lists for my monitor dimensions in their cyrptic config files (Is this the variable I want to change? No. What about this one? No.)... and then go through all that again when I changed my monitor dimensions.

So yeah... Now that I think about it, MALA kinda sucks. What do others recommend?

</comment></comment><comment><USER17> I have the same tankstick and cabinet setup, but as another poster mentioned, use an RPi3 to power it all with RetroPie. The tankstick is best on a powered USB hub, and that leaves you with enough options for a USB drive and a hidden mouse/keyboard for setup/maintenance.</comment>