aaaaxy VS mattermost-mobile

> Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!).

Thank you. Feedbacks are very much appreciated. There is still a long was until an eventual release, but it's very fun to work on it.

> I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not.

I had trouble finding basic structures like sets or linked lists, as much as more specific ones like R-tree, M-tree, KD-tree quad-tree or specific kinds of tries.

When quickly searching on Google, there are pretty much always some results, but when looking at the details it's not that great. Most of the packages have some kind of flaw that was a deal-breaker for me. Most common ones are:

- The package is something developed by one guy 4 years ago, and has pretty much no stars and is abandoned

- The structure is somehow backed by the native `map`, meaning that it has the same randomized iteration order

- There is some kind of logic to try to handle multi-threading, mixed-up with the data structure's logic. Often with mutexes/locks, thus killing the performance. My game is pretty much only mono-thread, and I just need something simple and that does not care about synchronization.

- The structure is not generic, but only uses `interface{}`

- The structure lacks tests or have unreadable code made of 1-letter variables

> I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture?

Thanks for the reference. After looking at it, is seems to me that they are creating really tiny packages made of one or two files. I don't want my codebase to end-up with thousands of 1-file packages, it does not seem very maintainable. I want to keep having packages with clearly defined purposes and domains.

> Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself.

I think that you didn't understand my message (or I didn't explain clearly enough). I do not need the items to be sorted, I need the iteration order to be consistent.

Let's say that I insert A, B and C in a map, then want to iterate on it. I will get an unspecified order, maybe ABC, maybe CBA, maybe BAC, which does not matter to me. However, in any language, this order will be consistent across all future iterations unless the data is changed. This is a natural property of any data structure. So if I got CBA in the first loop, I will also get CBA in the second and third loops.

In golang this is not the case because they actively inserted a random order. It means that even if the data does not change, I may get CBA in the first iteration, but BAC in the second, then ABC... Which created a ton of issues for me.

> If you don't care about unloading https://github.com/pkujhd/goloader

AAAAXY (version 1.2.280+20220822.2294.9ff4b8b7): A nonlinear 2D puzzle platformer taking place in impossible spaces.

Mattermost, Inc. | Senior React Native Engineer | REMOTE (US Only) | Full-Time

At Mattermost we build an open core, chat and collaboration platform focused on making users with mission critical work more productive while also allowing our customers to self-deploy and have full control over their own data.

We’re looking for a Senior React Native Engineer who has the depth to significantly move the performance needle of our app while also having the breadth to contribute across our stack.

Check out our open source mobile codebase: https://github.com/mattermost/mattermost-mobile. Meta uses the Mattermost RN app as the benchmark for performance testing of their Hermes JS engine: https://mattermost.com/blog/hermes-mattermost/. Want to set the bar for what a complex, high performing React Native app can do? Want to do it open source? Join our team!

Apply here: https://jobs.lever.co/mattermost/a38ea8f0-6c27-4178-a988-801...

I've got as far as downloading the mattermost apps: https://github.com/mattermost/mattermost-mobile/releases/tag/v2.3.0 and have been using fastlane/match but i haven't been able to build it or run it in xcode.

Mattermost has a few products/versions, i used the selfhosted enterprise version because its also MIT licensed, so free of charge and also very well documented. It may not well suited for business projects, features are build for technical teams/projects. - Features: https://mattermost.com/pricing - Deployment Options: https://mattermost.com/download/#server - Mobile Apps for both worlds: https://github.com/mattermost/mattermost-mobile An other very special app, focused on productmanagement, https://www.documize.com . Never had a scope for to use it in productive, but may match!? :)

Mattermost Beta (version 1.55.1): Secure, self-hosted workplace messaging

This was the first commit on a clean, orphaned branch on our mattermost-mobile repo. This commit kicked off the work on mobile v2. At that time — some of you may not have been born yet (or not yet born into Mattermost — which would include yours truly) — it had become clear a bit of a reset was required. Mobile v1 had grown organically, as many products have, out of a proof-of-concept. Some fundamental design decisions (like only supporting a single server, or how state management works) were foundational limitations and effectively impossible to fix iteratively. A more hard cut had to be made. Not a full rewrite per se, but close. This work kicked off inside of the mobile team, but after about a year also started to include a whole slew of engineers across the organization, as well as product and UX.

On the mobile platform end, as we’re getting closer to the mobile v2 GA we’re trying to pull our weight to shipping this thing on time. Hardcore style. We’ve now added support for announcement banners (allowing us to broadcast our new levels of extreme hardcoreness), and we will soon allow you to share how extremely hardcore fans you are of v2, with an in-app review dialog. We have also integrated Sentry, so we will have more insight into how the app is performing and when it crashes, hardcore. And last but not least, the work on a nice piece of share sheet is heading toward Android (previously only implemented on iOS).

Notes from the latest multi-product architecture sync-up. On the mobile platform end, an early look at how we’re trying to measure performance and performance regressions in the future (video). We’re closer to integrating Sentry. Search just got merged and should go out with the next (internal) beta (which should release today) — the platform team is covering this functionality with end-to-end tests.

On the mobile platform end, we’re going to try something new: a weekly mobile hangout (in the public ~Developers: Mobile channel of course, using Calls) on Mondays. The goal is to have a casual “drop in and out as you like” type of environment. Some of our mobile engineers will be there, if you like to talk about mobile development, are stuck somewhere, or would like to share your love of dynamic islands — this will be the opportunity. We’re also pushing three initiatives forward: automated performance testing (channel: ~Client Performance Automation) in collaboration with the web platform team, Sentry Integration and the “single command” installer for development environments. On the latter topic, we polled people last week. We’ll create a prototype of the “single binary” (written in Go) option.

Mattermost Beta: Open source platform for developer collaboration