amimetic

This article doesn’t cover depreciation.

Much harder to model but I’d assume quite important to consider.

I didn't go that far (every permission) but had the same experience.

I tried this and doesn't seem to work; though unclear what permissions I should be granting it, so possibly that is the issue.

There is an article about this based on a Chris Lattner talk/links to previous HN discussions: https://danielchasehooper.com/posts/why-swift-is-slow/

I assume RAM will also be a major constraint for on device ML; most Macs still default to 8GB (with absurd bumps in price to upgrade) so I'd guess some very high percentage of Macs sold in last 2 years are going to be quite bad for any major new software stuff Apple release in 2024. That is assuming they even are supported at all; if Apple follow their iPhone playbook they might just release the new stuff on late 2024 Macs.

Releasing the (more) mainstream model “as early as the end of 2025” or about two and a half years from now seems pretty depressing if accurate.

Allowing another year for some kind of volume of sales that might justify the development of apps etc suggests we are a long way off this being a supported, mainstream computing platform.

Is there really a minimum of 3? It seems to offer a "Just me" option.

I also noticed it seems to include something equivalent to a standard zoom subscription so this whole thing might save me money!

PS A lot of the comparison tables etc are confusing and in past I noticed (I'm in UK) the offer details vary by country.

The economic theory would be something like given lack of (senior) engineers, salaries should rise to expected marginal revenue.

Conflating actual outcomes in real markets with economic theory is typically unhelpful.

As I’d guess most people spend most of their time in Chromium browsers and electron apps probably a case to make that ‘native’ in the sense you imply is Chromium!

Stateful hot reload is pretty awesome when doing UI work. On desktop that is pretty hard to find.

Also, as a TypeScript/Swift/Kotlin person, Dart is fine; sure I’d like algebraic data types but overall it is good. The tooling (auto completion etc) is great. And it has a few cool unique(ish?) features like cascade and every class is an ‘interface’.

It isn’t a theme per sae, really an alternate set of widgets: https://flutter.dev/docs/development/ui/widgets/cupertino

This "Dev builds perfect note-taking system which only stores info about building note-taking systems": https://www.theolognion.com/dev-builds-perfect-note-taking-s... is well timed

Pretty misleading headline, as fourth paragraph: "But overall, the country is actually using less energy because of businesses being closed."

Today is a weird time to get into mobile app dev. The standard 'native' UI frameworks are pretty terrible in terms of how they cope with complexity and their ability to change over time with their dated OOP APIs. Though on both platforms the tooling has been climbing ever upwards towards local maxima.

The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future.

SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.

I was addressing the comment and in no way claimed Android doesn’t have a hot reload solution.

For static layouts this can work pretty well. I think it is still typically a bit slower/more awkward. And often harder to change. (I actually have most experience with native Android.)

Please try out one of Flutter or React Native. I think you’ll be surprised how much nicer they are for anything like this. The code is certainly not cumbersome when compared to the equivalent XML.

Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.

This is exactly the kind of thing that is unnecessarily hard in non-React-like UI frameworks. XML definitely does not do this well!

In React Native or Flutter I can just declaratively go from an array to rows of UI. It will be a few lines of code and will be incredibly clear (and easy to change).

In Android or iOS I can either do something procedural (which is messy, hard to reason about etc) or do something horrifyingly boilerplate-y (as you suggest), spreading things across multiple files and greatly increasing cognitive load.

I've worked with native Android, native iOS, React Native and (a tiny bit) with Flutter. I really wouldn't use vanilla native Android or iOS (even for a single platform app) unless there were some particular requirements around perf or whatever; so much more tedious, slower and (this one is subtle and will be missed by simple comparisons) so, so much harder to go back and make changes or additions to.

SwiftUI and Jetpack compose look promising for the future. But neither are ready for mainstream (enterprise?) use today.

But a lot harder to address (probably effectively impossible). This is actually one of the best comparisons I’ve seen.

I’m not a huge fan of Dart (too OOP for my tastes), but if you know JavaScript or Java it is really easy to pick up. The only thing I struggled with are the required semi colons!

I have spoken to people who have used it for backend code, though that is rare.

"better tools for mocking in tests, ways to build custom lint rules": thanks to Elm being pure functional you don't really need mocking. And the amazing DX/tooling would make linting in style of JS completely unnecessary. So no need to toil over these issues at all in Elm. It won't help with isomorphic rendering.

(I write this as someone who mainly does TypeScript, but did a few months of paid Elm work. The main problems with Elm I see are the lack of jobs + as of 0.19 the hostile (NB technically, not personally) approach to those not aligned with Evan's direction for Elm).

Dart is designed to be uninteresting! But certainly Kotlin deserves a mention if Elixir makes it onto the list.

There is a proper explanation of why Swift makes sense for TensorFlow at https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

One other option not considered for employees: become contractors. Most mid to senior level people in London on 'standard' salaries could probably double their income.

A scaled resolution is now default on most MacBooks. I haven't noticed battery problems but certainly seen RAM usage at least double that of Chrome and considerably above Safari.

Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift. Flutter also provides a first class Reactive UI story: something sorely lacking in native iOS (or Mac) development.

PS Java (or Kotlin) are AOT compiled in all recent versions of Android.

Yeah, as a developer I do find iOS and Android compelling: there are such low barriers to entry I can (and have) released games for both.

Does anyone else find the overwhelmingly positive coverage of Switch and its games a little puzzling?

From a consumer's perspective I just don't get it. The Switch costs more than a vastly more powerful PS4 or Xbox One S. It (particularly) versus a PS4 has a tiny library of games. And the PS4 has actual VR. But even more remarkable is comparing the prices of games on the systems: often you will pay 2-3x as much for a (probably inferior) version of a game (compared to PS4/Xbox/iOS/Android).

I bought a Switch a few months ago. Played (and loved) the nostalgia of Mario. Played and dropped (as it seemed frustrating/grind-y) Zelda. And as far as I can tell that is basically the two games worth getting it for it. So I sold it. As I have a dozen great games ready to go on my PS4, and seems like more excellent stuff on the way, I just don't get the point of the Switch. If I want to play games on the move I can use my iPhone.

They should probably just remove it. Long press would almost always achieve same thing. And is slightly more intuitive.

Hoping the "100-hour-work-week" bit was a joke.