Wanting to learn is a good requirement in itself.

Try starting with the language and then see what you can make of it in that case. You may find out that it’s not exactly viable, but then you can always try something else.

Understand what tradeoffs different solutions make, then inform your decision on that. A fairly general principle for example is that the more cross-platform compatible a solution is, the less well-suited it will be for any given platform in terms of looks/behavior/performance. This may or may not matter for what you’re building.

There are inherent qualities to some solutions (for example, a particular library may make for good solutions on a certain platform), and some qualities will be situational (a particular library is good for you because you happen to know the language/patterns/framework/whatever).

I personally like to build things in Kotlin and Jetpack Compose, but that’s because I primarily build mobile apps for Android and I like the reactive UI paradigm that underpins this library along with the language that it’s written in. I would perhaps reconsider if I were building a desktop app (not as well supported), and definitely reconsider if I were building a web app (definitely a poor fit).

So yeah, start with what you’re building and what its requirements are. Then think about what you already know, and finally put those together when evaluating a UI solution.

General purpose: Kebab case

But really, follow the conventions of what you’re working on. For example, I’d use pascal case when working on a Java/Kotlin project, and snake case when working on a Python project.

Testing in prod is a power move honestly. Rock star-level

I don’t know if it matches your desire for easy install of small disk space, but it might make up for it in other arenas - Ruby is my new-found love when making simple scripts. Being able to mostly emulate the shell integration that bash has by just using backticks to call a shell command is the killer feature in my book.

Kotlin-style async is pretty neat, ngl.

Spill the beans!

While Rust would probably have been a good choice for implementing a new browser, I don’t think Swift deserves the criticism it’s getting in this thread:

• Swift was created by the same person who created Rust, and has many of the same nice traits
• Swift is a modern language that is easy for plenty of developers to pick up; I’d place it in the same family as Rust and Kotlin
• Swift grants access to a large pool of native iOS/Mac developers

Possibly. I’ll have to add it to the mix when comparing. Thanks for the suggestion.

It’s highly unlikely that this app even comes up on the radar insofar as competing with Google Maps.

The answer is probably more mundane - an automated system made an incorrect call. It keeps happening when it comes to these Play Store app reviews.

I was mostly against having the amount of ads that it blasted on me. They had a setting to turn off the recommendations, but that made it nigh-unusable.

You can do a lot of things! I’ve replaced the launcher and installed an altstore on it, giving me access to plenty of good stuff.

It’s running Android under the hood, so any APK is theoretically installable, but most won’t run well unless they are optimized for the use-case.

Because the pandas are all staring at you.

AI-generated, perhaps?

Healthcare is pretty rough, I’d be willing to bet that the grass actually is greener in this case.

Jon Schlinkert, I believe. Sindre has a lot of stuff as well, but has a better reputation afaik

While the rest of the world shifted left dudes went ahead and shifted right

Go is in a good position, yeah. JavaScript has prettier, which is nice. Java has google-java-format. Python has ruff, which is quite good. Kotlin has ktfmt, which I believe made a mistake with their standards by not following the standard formatting guidelines for the language, but whatever. Uniform and deterministic for the win.

Automatically enforced deterministic formatting is the best, there’s nothing that beats it. The productivity in just being able to format on save knowing that the code will be in the ideally formatted state, along with the anti-bikeshedding properties of this strategy, makes it unbeatable.

Yes

Those things sound super great… but they’re of course all meant to keep you working around the clock, meeting deadlines.

This is not going to be universally true at all big tech-companies. There are places with perfectly reasonable WLB on top of huge salaries and fantastic perks.

These places are usually big enough that you’re going to see extremes on both ends within the same company - some departments with huge deadline pressure cultures, and some with highly relaxed work settings. It can be a bit of a gamble.