Herbert2

For me, an emphasis on Go indicates that I won't have problems with cross compilation and that I'll have a static binary to run. I'm more inclined to give a tool a try when I don't have to deal with language sandboxes.

Using it for two days now on OSX for a client so I don't have much experience with it. First impressions are ok, the documentation could be better and it's not very googleable as you get a lot of irrelevant hits from normal .NET, MS really should have more creativity when it comes to naming. Problems I've hit which I wouldn't expect to hit in a more mature framework:

* Running EF Core migrations against postgres on startup. I wasn't able to google a solution to this. I hacked around this by deploying an init container with a migrate.sql script but I expect that'll bring me problems later on.

* Let's Encrypt. Found an archived package on GitHub, I expected more maturity.

* Not very easy to ascertain the state of the setup, things need to be registered in a certain order for them to work (UseDefaultFiles & UseStaticFiles f.i.). This would be made easier by me having more experience with the stack or better docs, still a waste of time.

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.

As a foreigner in Germany, I'd add to that list bureaucracy & the German language, a duet that does little to bolster the willingness of non-native speakers founding companies here.

react + grpc with services in go & python

Simplest solution I've found is to run the devserver in a gulp task instead of using any of the pipeline/compressor projects.

I'm all for less sprawl but artificial limits like the ones you're describe would IMO only needlessly accelerate gentrification. For instance, it's very difficult to get a spot at a daycare in Munich, not because there isn't space in the system but because the city can't afford to hire staff that can afford to live in Munich.

Very nice but very US centric.

capital controls.

It's understandable that developers aren't abandoning their current projects, but starting new ones suddenly carries the risk of developing for a platform that you have doubts that gamers will buy.

Alright, these were approximately the fields that were Postgre-fied.

CREATE TABLE event ( "references" text[], (was 2 tables, references and reference_on_event) "entities" text[], (ditto) "actors" text[], (ditto) "targets" text[], (ditto) "payload" json, (EAV) )

Gin index on all the text arrays. There are about 150k events saved per day and PostgreSQL is running on the same kinds of hardware as SQL Server was. The application is quite read heavy.

Anecdotal, I migrated a sluggish multi table SQL Server setup to a single table PostgreSQL by replacing the previous EAV setup with hstore and m2m "article-tag" tables with array fields. Exactly the same functionality, only 20x faster. Sometimes vendor lockin is worth it :)

I was hoping some of meteor's users could answer a few questions about it.

Can meteor use Postgres instead of MongoDB? Could meteor do sync with the database through a server-side rest client (instead of mongodb)? Is TDD possible? Is CoffeeScript possible?

I'm pretty sure that at Jane Street you get to solve engaging problems and get paid 250K+. OCaml or not, they're not going to have problems with hiring.