stefano

The only way to do that on App Engine is to have the client ask the server for a temporary signed URL to a writable cloud storage resource, and then have the client upload to that URL (i.e. the only way is by sidestepping App Engine...).

You can step-through your big ball of mud in a debugger, but you can't do the same with your small balls of mud. Not easily at least. That alone makes a huge difference.

> That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions

I'd argue that's on the developer, if he was the one to choose a database that doesn't support transactions, and then didn't implement application-level transactions (which is very hard to do correctly).

I wish they had python 3. It's still stuck on python 2, which will be unsupported in less than two years.

Sadly, many subreddits are slowly going down that path too.

What's so important about being async by default to build desktop applications? Offloading slow tasks to a background thread is not at all harder and actually allows you to use more than one cpu core.

Threads avoid the need of callbacks/promises/async/await and they're also cheap and performant unless you need to spawn >10k of them, which seems very unlikely in a desktop applications.

Being async by default is an advantage when you need to handle hundreds of thousands of tasks, all of which are mostly waiting on I/O, which is something that can happen on server side applications, and almost never on the desktop.

Earning 10k/month after taxes and still having to share an apartment is not normal.

Like we have botnets made out of thousands (millions?) of compromised computers, we could have entire fleets of compromised cars, rentable on the black market using cryptocurrency, that could be used to commit crimes (e.g. homicide) while keeping the killer anonymous.

Scary stuff. I hope these self-driving cars will be able and designed to work while completely offline, with no built-in way to ever connect to a network. But given the biggest player in the field seems to be Google, they'll probably be always connected in order to send data to the mothership and receive ads to show you.

There are at least GTK+, JavaFX, Swing and wxwidgets.

We got WASM instead, which I'd argue is much better than support for a specific language, which would lock you in and prevent you from taking advantage of new programming language research.

Why did you choose to support a single language instead of following an approach similar to GTK, with a binding-friendly C API and wrappers around it for major languages (or even just for Dart, the community would have quickly provided the rest)?

They could've made a C API, with a thin Dart wrapper around it, allowing multiple languages to create their own bindings, like GTK did. Instead, they decided to couple a UI framework with a language that almost no one is using. Maybe because it was easier for them to implement it that way, or as an attempt to make Dart popular after developers have been snobbing it for years.

In the end, if flutter becomes the de-facto standard for mobile apps, developers will hate it for the same reason developers hate on javascript: it's not necessarily for its technical merits, although they do play a role, but because it's forced on you with no other choice.

> We 100% promise that all the code we generate works across all browsers.

By supporting only Chrome, you're showing that you consider Firefox/Safari/Edge as second class citizens, making it harder to trust that you will keep supporting non-Chrome browsers in your generated code.

If you just get on with it, you're contributing to make Chrome a monopoly, and that will in turn slow down the pace of technology. Google/Chrome won't act differently from Microsoft/IE6. There's no reason to invest in improving a browser if there's no one left to compete against you.

> and no one can arbitrarily issue new bitcoin at a whim

Anyone can fork it though. And the interesting part, as seen for bitcoin cash, is that the total market cap of the fork + original chain right after the fork was greater than the value pre-fork. You can technically argue that this doesn't amount to creating new bitcoins, but for all practical purposes the total amount of digital tokens did increase.

Isn't it a failure of a decentralized system the fact that most, if not all, persons using it end up depending on a centralized system?

My guess is that there is very little real liquidity in the market, and most of the value is just paper gains that can't be fully realised, i.e. a single person can fully liquidate to dollars, but if everyone does it, many people will end up holding the bag.

When someone tries to cash out, exchanges might need for someone to put some money back in to avoid a liquidity crisis.

I believe this is especially true for tether-based exchanges, which Coinbase is not.

Then again, this is just my guess and I can't provide anything to back it up. Maybe it's just due to a buggy cowboy-driven codebase and awful customer service. Time will tell. If it's a liquidity issue, exchanges will eventually go belly up, if it's a codebase/customer service problem, they might get to a point where it's actually fixed and things just work.

I find it hilarious that people "investing" in decentralization have to turn to a central authority to be protected.

I'll be pretty happy to "lose out" from being tracked and profiled.

Hold on, you can't call a linked list theoretical knowledge. It's a basic data structure used in tons of real world code, including this forum. And even then, theoretical knowledge does have an impact in the real world. People don't study and research theoretical subjects because they have nothing better to do, they do it because it has real world implications.

If you ignore the theory, you end up with sub-optimal software that only kinda works (who cares about studying the theory and actually verifying those pesky edge cases) and is slower than it should be (who cares about advanced data structures, just use arrays and hash tables everywhere).

Blockchains seem to be really good at raising capital.

It's the problem of studying for the test vs studying to learn. Some knowledge will transfer, but the further the test is removed from reality, the lesser the transferable knowledge will be. When I look back at the interviews I had and what I actually needed to know at work, the difference is massive.

Yeah. Their TOS says that they're under no obligation of giving you dollars in exchange for tethers. In fact, no one has ever redeemed a single tether and there is no process in place to actually do it. Why people believe that 1 USDT = 1 USD is beyond me.

> as long as their books balance

This is a really strong assumption that I wouldn't bet on.

Market cap is very different from the actual money invested in the ecosystem. I don't know the exact number, but I bet it's a lot lower than $100bn.

Stupid example: I create 100bn coins. Then I sell one to myself for $1. Am I now running a $100bn experiment?

Tether might be a good candidate.

Transpilers used to be called "source-to-source compilers", or "compilers" when the "source-to-source" distinction wasn't relevant.

Then the JS world came along and decided to use a new word to make it look more hip and cool.

Compilation is for old people writing old programs that run on old things called "computers".

We're fresh and new and iterating quickly on our MVP, so we don't have time to wait for long compilation time. Instead we transpile our code and run it in a serverless environment, a docker container or a browser.

By having a nest egg that can keep you and your family going for a few years.

Aren't you worried about vendor lock-in?