Comment by scarface74 | Hacker News Reader

Comment by scarface74 | Hacker News Reader

First for context, I’m far from a Microsoft hater. I spent 22 years exclusively in the MS ecosystem. I love C# and even now I’m the go to person when it comes to implementing MS solutions on AWS for my department.

That being said, when I was a dev lead, the first things I thought about when choosing a technology were the ecosystem and the how hard it would be to find competent devs. You can throw a rock and find a good enough enterprise C# dev in any major city. I would not have chosen F#.

As far as Flutter, Google has the attention span of a crack addled flea and I wouldn’t tie my horse to any platform with a Google specific language or runtime.

Even Google is moving away from Flutter for internal apps.

https://9to5google.com/2021/10/10/google-ios-apps-native/

I’m very much a native framework snob. But I understand the need to have a cross platform mobile platform for a bootstrapped company. Why not use a JavaScript based mobile platform? He already new TypeScript and Typescript devs are a dime a dozen.

Finally, why use Docker for Postgres?

One advantage of using docker for everything is reproducibility. Your dev and prod environmentsncan be almost identical.

Is it really that much easier than just installing the same version of Postgres and running SQL queries to create the schema/seed the data? You’re not going to be using the same data in production and dev.

I personally definitely find it easier to use Docker than to setup the same versions of postgres across multiple OSes, or OS versions.

How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the Debian/Ubuntu packages?

Or I can sidestep all these questions, and just use the same Docker image everywhere, which will give me the same version of Postgres and the same config. I agree it shouldn’t contain any schema/data.

SQL is a fairly common standard that’s been around for a few years.

Postgres is an open source product that has some traction, and even if it disappears next week you still have the source.

Linux is starting to catch on and you can even find places that support it.

The POSIX layer is widely implemented and even Windows and Mac have sone level of support.

What I’m saying is, you can choose from a wide variety of databases on pretty much any common OS and most of the features will just work on all of them.

Minor versions of a single database on different flavors of the same OS are not a big deal.

I wouldn’t go as far as say SQL is a standard. Yes there is standard SQL. But every database has its own dialect even for simple stuff like choosing a range of rows.

It’s been ages since I did bare metal/VM installs of databases and then it was MySQL. But installing the database is a one time thing. The challenge was and is always syncing schema changes and loading seed data.

Couldn’t you just install the server OS in a VM on the dev machine and solve all the problems?

That sounds like a more heavyweight[0], and much more cumbersome[1] version of using Docker.

[0] Much more CPU and RAM needed.

[1] You rarely work with a fresh OS install; you'll have to install things, edit files in /etc/ or whatever, set firewall rules perhaps. For me at least, many of this comes with googling, say, "how do I allow an incoming TCP connection for a port range?". Ie, tiny details I don't want to memorize. I'll have to replicate these steps between the dev VM and the prod environment. If I use Docker, I can write these things into the Dockerfile and then just do "docker-compose up" in production, and it will just work. Also, I can commit that Dockerfile into a repo. It makes it much easier for others, or future-me, to understand what the dev-ops setup is like.

Where in that article does it say they are moving away from Flutter?

If they are using UIKit, they aren’t using Flutter for cross platform development. They aren’t eating their own dog food.

> Google concluded that it was time for the latter route, and that Apple’s UIKit had matured enough for internal needs. The company no longer had to maintain most of the custom components that it built out over the years, including app (top) bars, lists, and menus.

Reply on news.ycombinator.com