exacube

These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory).

>> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)

as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.

>> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.

If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense.

>> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.

I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB.

>> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.

Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?

>> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).

>> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.

Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?

>> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.

This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning? I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.

It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles.

And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code.

It's unclear to me that this is a sticking point.

I'd love some further explanation here:

what does locking memory mean in this context? For what purpose do security sensitive programs lock their memory? what is the performance degradation that happens with low-spec computers?

i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome.

as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it

yes, if the government could manage to pass a good law there :) but in the event that the government won't, tipping helps correct the situation.

yes! tipping is like a naturally occuring form of redistrbution of wealth in capitalist countries :) I personally view the evolution of tipping culture as positive on the whole. and also, I think people tend to tip a bit higher if they feel good about the service, so it still incentivizes good service. When I visit Europe, I am reminded how nice the service industry in America is.

It's pretty possible, and has been for a while: 1) Flutter already implements the Material spec and Cupertino spec, so the biggest cost, the upfront cost, is satisfied. In fact, the Flutter team found inconsistencies with the Cupertino spec vs. what iOS' animation kit implements and filed bugs for them. 2) It's OSS; this problem will minimize as more people are contributing and using Flutter.

From googling: https://www.keycdn.com/blog/web-font-performance/

Skip to "Here is a comparison of hosting Open Sans locally vs Google CDN."

They found it was faster to use a Google CDN. One of the things this article suspects is that CDNs will have better world-wide coverage, and therefore overall latency, than hosting your font yourself.

I'd like to see a comprehensive study of your counter point, though.

> God, how arrogant. It's one thing to be opinionated about music, it's another to judge another's enjoyment

It was meant in jest

it sounds like you only enjoy it, not love it :P

if you look at Spotify, you find they have all these features that music lovers would use, even though they may not be the majority class of users. This feels to me like Apple is marketing themselves as what Spotify is (the leading competitor in this space), but their product development falls short of their marketing.

Couldn't have guessed from this comment/URL that it would be about finding/accepting jesus.

IIRC the biggest contributor to the transportation's emission are freight ships that cross the oceans. I wonder how they will be solved.. Maybe going all-electric will help people transform their mindset to no-emissions production (since cars live with people, frieghts ships don't), so it could be that this is an important cultural shift.

Every browser borrows from other browsers. But really, browsers are mostly technology, and Chrome was a few notches above all the other browsers in terms of performance, security and crash-recovery. The browser industry owes a lot to Chrome for really pushing the boundaries back then.

1) using channels + goroutine to implement a map doesn't seem like the most sensible thing to do; even golang's new sync.Map type is implemented with mutexs (eg https://github.com/golang/sync/blob/master/syncmap/map.go#L2...). Idiomatic doesn't mean ALWAYS do this no matter what; it is the natural thing to do if it feels like the right approach.

2) Don't use "considered harmful" so much; it is considered harmful.

or atleast ~4 years like iOS devices get.

lyft currently does like 200-250 million rides/yr [1] with a crazy trajectory. if we "conservatively" assume 40-50% average growth YOY in ridership

that's like 6 billion rides/yr by 2025.. which puts this estimate at 15% - 30% of rides being all-electric + autonomous.

[1] https://www.bloomberg.com/news/articles/2017-04-27/lyft-book...

if this is not a joke, i'm amazed by your perspective..

from googling: http://hyperphysics.phy-astr.gsu.edu/hbase/Nuclear/cardat.ht...

"The low activity of the carbon-14 limits age determinations to the order of 50,000 years by counting techniques."

how so? how would a type system have helped here

maybe you don't mean it, but the way you speak sounds very judgemental and not-in-my-backyardy.

I find it odd to tip for professions where they earn decently; restaurant waiters don't earn much (they earn 'restaurant minimums' or even under the table) and rely on tips.

Uber and Lyft drivers earn decently ($20/hr+ in the bay area, $30/hr+ in NYC), and I wouldn't consider tipping them if I was earning similarly/less than they are. OTOH, if you're a high earner and paying a tip doesn't make a difference to you financially (but does to someone else), then you should do it!

this is not ockham's razor. people here are refuting the 40% hiring decline, so it's not an explanation to choose from to begin with.

there are many forms of intelligence!

how do they estimate this stuff?

definitely slow farts (it is not emulated, but runs inside a linux container instead, so it won't have that emulation overhead)

i'm pretty sure they're talking about adding these "layers" at the C++ stdlib level, not at the language level. So it will remain portable.

in general, hardware improvements will drive new swanky software, and make computing on smartphones closer to a first class citizen (remember motorola's laptop+phone dock, where the phone powers the laptop?).

another big pain point is battery (and battery consumption). still waiting on hardware (and software in conjunction) to get more efficient. you'll remember how power hungry PCs were in the beginning and how much better they are now (laptops notably).

feels to me like we still have many years to go, and many more "big" technology investments.

How do the economics of providing Basic Income work?

I guess you would have increase taxes or provide lesser services? e.g., expect that basic income will cover some parts of the medical costs and provide a lesser health care for the average person. I'm guessing an implementation will be somewhere in between.

Money has gotta come from somewhere.

:( !!!

I've recently started going through the Raft lab for 6.824 (and still working on it), and I /highly/ recommend doing the labs in this course (I am not an MIT student, nor in college). This course is fairly practical in nature, and will expose you to the real-world aspects of distributed systems!

Even the first assignment, which is just implementing aspects of mapreduce, will make you exercise some nice concurrency concepts. They have tests and everything to check that you have a working implementation!

At the very least, checkout the recommended readings!