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.
Thanks for the tip, does FluentMigrator require me to duplicate the table structure in it's DSL or does it have a way to pick up EF Core tables & detect changes?
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.
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.
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.
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.
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.
But people need to learn things like OO and memory anyway, why not do it with a language that teaches you both? It's not like the introduction to programming in Java would have final bufferbuffers everywhere to avoid garbage collection. C++, as bad as it is, teaches you both how memory works and how OO works.
I went through a similar switch from MSSQL to postgres. We moved 7 applications of various sizes over and the biggest hurdle was office politics. The migration never took more than a day for each app. ETL and reporting were not affected since we had previously integrated messaging (rabbitmq) pretty heavily into every system at the company and ETL gets their data from there.
We also switched the DB servers to over to linux and got a huge performance boost from that.
We did rewrite some stuff, but that was mostly to take advantage of postgres features like array types (instead of a article tags table, you'd have an tags array) which we used to speed up some applications. One we sped up by a factor of 10, just by using array types and offloading json generation to postgres: select array_to_json(array_agg(row_to_json(t))) from ( some query ) t
Despite the overall ecosystem being rather small, the standard library and adjoining experimental packages are excellent. I wouldn't be surprised if go 1.2's stdlib would cover most of what Python's stdlib and Twisted can do.