drmidnight

hanging in there with you. Its a great phone.

Duck.ai has it as an option

GPT-5 generated the chart

1987 Toyota Camry Wagon. Fills my needs and isn't bogged down with complexity making it easy enough to fix myself.

The approach I took for a recent project was to generate raster tiles for 0-7 zoom levels on the server. This is done in the data pipeline when new data becomes available. I then load the dataset into memory on the tile server and any requests for zoom 8 and above will generate tiles on the fly and cache them for other requests.

Its worked out very well so far, but I'm working with time series that adds a new set of data every 5 minutes so I need the "on the fly" approach. After some heavy optimization it's become quite fast and often the generated tiles are returned before the base map layer is.

The upside is that it works with any map system that supports raster tiles, so any platform really.

I have had a similar hold up, though after 5 days I knew something was up. I rejected the build and resubmitted. Went through the same day.

Diablo 4 has been working for awhile now. Not sure about overwatch though.

I've been playing on Linux. Both on desktop and my Steam deck. Runs fine under Proton.

I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine.

Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.

GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.

I still rely on GDNative for really performance critical systems though.

I too am in my late 30s and I've been writing Swift for 7 years now and the language itself is not buggy, at least anymore.

SwiftUI has it's issues and one is platform support. If you want to support anything before iOS 13 (even that has limited support) then you are out of luck. The only SwiftUI I have shipped is for WidgetKit and WatchOS, both being somewhat forced upon you.

While it can be cumbersome to do simple things in SwiftUI that were easy to do in UIKit, I haven't found too many bugs. Most issues I have run into are on the Xcode side.

If you work with any Apple platform it is worth pursuing. If you want to just learn and use Swift it does have decent support on Linux thanks to being able to bind with C libraries. Windows support is there, but is very much in its infancy.

Personally I find it to be a nice blend of language features that I really enjoy. It's expressive and readable.

If you can find a language that you actually like to work in then why not use it on other platforms?

The dependencies really come down to the Apple frameworks. Ditch those and it's no different than any other general purpose language.