O-stevns

It becoming "very good" now is the problem, because it's not backward compatible. So for us developers who are still lingering around supporting those poor iOS 15 (soon 17 thankfully) users, you are stuck with UI acting anywhere between horrendous or not not working at all, to being slightly broken, to working as intended.

It didn't have to be like that though... It hasn't always been this bad. Personally I think they've been ruining Swift since version 4.

It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)

No need to defend yourself, I share this sentiment as well. If I'm going to spend time writing and reading a lot of code in a new learning language, I want my previous knowledge to be somewhat reusable.

For this reason I was able to get into Odin as opposed to Zig because of some similarities with Swift Syntax as well how easy it is to parse.

The less I need to rewire my brain to use xyz language, the greater the chance of me getting into it.

If my life depended on it, I could get over such a shallow reason to dismiss a language but fortunately it doesn't and that's why I write Swift rather than Rust.

As we dive further and further into them being dependent on said devices to be part of modern society... Yes we do.

It's the niche that wants open and flexible devices and the ability to customize everything.

Let's not ruin iOS by trying to make it Android.

I say that both as an iOS developer and Android user.

That's a lot of code for a PR, though i should admit I have made PR's being half that size myself.

Personally I think it's difficult to address these kinds of PR's but I also think that git is terrible at providing solutions to this problem.

The concept of stacked PR's are fine up to the point where you need to make changes throughout all yours branches, then it becomes a mess. If you (like me) might have a tendency to rewrite your solution several times before ending up with the final result, then having to split this into several PR's does not help anyone. The first PR will likely be outdated the moment I begin working on the next.

Open source is also more difficult in this case because contrary to working for a company with a schedule, deadlines etc... you can't (well you shouldn't) rush a review when it's on your own time. As such PR's can sit for weeks or months without being addressed. When you eventually need to reply to comments about how, why etc.. you have forgotten most of it and needs to read the code yourself to re-claim the reasoning. At that time it might be easier to re-read a 9000 lines PR over time rather than reading 5-10 PR's with maybe meaningful descriptions and outcome where the implementation changes every time.

Also, if it's from a new contributor, I wouldn't accept such a PR, vibe coded or not.

Odin has no primary use case, it just happens that a lot of the members in the community have made or are interested in game making

I got the iPhone 13 mini as a work phone for the sole reason of it being the smallest iPhone at the time. I too dislike the phone landscape nowadays with their ridiculous and ever increasing sizes.

My personal device is a Motorola Razr 50 Ultra, which I got because while it's huge when flipped, it's portable enough when it's closed. I can have it in my pocket without it falling out.. without it being annoying while i put on shoes etc...

I use its cover screen a fair amount too, to avoid having to flip it open, which is also why I got the ultra rather than the slightly smaller version.

It's been years since I used Total Commander, so I don't recall all its features anymore. On macOS I use Marta https://marta.sh/.

It's not my hill to die on but I will say use wireless in-ear monitors myself to avoid ever having to deal with adapters because... Adapters are terrible, often wonky in one way or another, incredibly inconvenient for anything but having them lie on a desk. It's also something you easily forget to carry around, or you lose or break because of shoddy build quality.

It's a bad alternative to something that wasn't a problem except it took up space and people still talk about it because there's still a need for something better

Yes, as mentioned here on the overview: https://odin-lang.org/docs/overview/#built-in-constants-valu...

x: int // initialized with its zero value

y: int = --- // uses uninitialized memory

Not loving this trend that we are starting to doubt whether everything is AI generated.

Ahoy is a known Youtuber who has made content for 14 years. His voice is definitely not AI generated.

"Study smarter" or just make it easier to cheat... you be the judge of that. Maybe we should just go back to doing tests and exams on paper? What was the benefit of going digital with this again?

> a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready.

A blind person can and should get cues from their assistive technologies that an item is is being loaded and is shown, either using announcements or aria tags that provide this information to the user.

While its fine to expect that something is available immediately, that's rarely a realistic expectation, whether you're blind or not.

The _mostly_ same behavior is what caused the problem though :P I'm curious, did these solutions come to pass because you had to make adjustments based on actual user feedback or was it just a developer trying to think ahead? I'm questioning whether forcing the user to tab to get to the menu item is a hindrance at all or whether the animation was a problem.

Maybe the former could have been solved using ARIA tags or maybe it would require bigger changes to the component itself. Accessibility is a roller-coaster for all these reasons alone.

Of course there are edge cases, I work with accessibility too, for an app in the public sector where WCAG rules are no joke, so I know this as well but even so, we don't build custom accessibility UI for our users. We (try to) build the UI with accessibility in mind so it's scalable, can be used and navigate properly by voice over and keyboard.

On mobile it's not perfect either but in general you do have features to change stuff like. focus, grouping of elements, how the keyboard navigate the view stack, how to access a button through custom actions and like you mention, change the tab index programmatically.

Even so, not everything can be fixed or handled through standard accessibility means and as such hacks will inevitably make it into the products.

I get what you're saying but I still think that making things accessible and designing with common accessibility in mind should be default and as such it has to be thought about when designing and developing from the get go. Having to create custom interfaces to fulfill a specific need might be a good fit for some things but not when developing apps and websites unless you're targeting that user-group specifically.

Seems like a non bug to me.

The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. Stick to what you get by default and design your components so they work for both usecases. Don't try to be smart when it comes to accessibility.

What he ended up doing is what I would have considered a hack. A solution that inevitably breaks or has side effects.

The reason there rarely are good handles to do things differently in accessibility context, is because it's not something that's meant to be handled differently.

While I understand your question is about the Transit app in general, I'd just like to mention in correlation to the article that my team and I worked with one of the public transport operators in Denmark, to utilize the motion predictability feature found in Android and iOS SDK's, so I can enlighten you with some details regarding that.

Our conclusion was that the feature didn't work in the danish metros for reasons we never got to deep dive into. It's most likely related to the fact that many of the metro stations are built in concrete, as such there's no GPS data in most of them unless you're very close to or on the surface and no motion data.

I'd be surprised if they got this particular feature working but who knows... maybe if we had looked into the raw sensor output we might have been able to work something out.

In the end we made a solution to help determine when you're moving or not by utilizing beacons.

While Lottie has existed for a long time, I'd consider looking into Rive instead https://rive.app/

Compared to Lottie, you can make animations for Rive directly in their web editor.

The downside is that you have to create an account to use it.

The whole concurrency agenda with local reasoning sounds great in theory but in practice becomes such a pain in the ass for projects that has existed for years.

Maybe our current app has unknown data race bugs, maybe not... with a crash free session percentage of 99.80% and hundreds of thousand monthly users, it's not something I consider a big enough problem, to the point where more friction to the language should be added to maybe fix it.

Yup I agree, to me it is turning into the next c++ with the kitchen sink in terms of features. The language is trying too hard to cater to too many use cases.

At some point I hope it stabilizes without it being the end of the language.

I use Swift every day and while I still enjoy it, I think the language was nicer to use in its earlier iterations than it is now, which is a shame.

The native experience benefits the user and the device more because it's using the APIs as they were intended, WPA's will forever be the inferior choice.

Imo there's nothing suspicious about, I am an early adopter and I happily pay for it. It simply provides better results than Google, Bing, DDG and any other search engine I've tried. I'm not a fan of subscription based software/services at all, but for once I think it makes sense when it comes to search queries.

Before I was an avid user of google but seeing the results getting worse and worse made me look for different solutions. For now i'm interested in supporting a search engine that can keep itself above water through my wallet.

I'd say like with most things, simply going through the material is not enough. You need to follow the tips like reading the script out loud. This has had major impact on my ability to learn and furthermore speak the language.

I've been using Duolingo daily for soon 3 years (pro user), approx. 30 min, learning Japanese. Although I also use other apps for deeper knowledge and understanding of the grammar, I would be lying if I said duo didn't work for me. I understand most of what I've learned so far although reading is still a challenge, especially text with more complex kanji in it.

You say you've gone through the course but is that still true? at least today there are 810 quests, each with a meter for you to fill up.

Id be shocked if you got through all that and still didn't know how to count to ten.

Duolingo is no silver bullet. You still need to be really interested in learning, practice as much as possible and last but not least, investigate and deep dive into the grammar.

In case you're interested, here are the other apps I use for learning Japanese. - KanjiGarden, for memorizing kanji - Takoboto, my favorite dictionary - Renshuu, good for deeper explanation of grammar

Figma also went to great lengths to make it perform as well as it does. Doing something similar for Inkscape seems unlikely but who knows.

https://www.figma.com/blog/building-a-professional-design-to....

I'm definitely a part of the outliers in those statistics given my monthly use varies.. sometime 800, other times +1200 queries.

The pricing seems reasonable to me although I do not see myself paying 25 bucks for unlimited search. I'll probably stay on the 1000 queries and see where it takes me... The fact that you'll pay per queue once you hit the limit seems to have been missed by some in the thread...

You do not have to upgrade to $25 unless the cost of per queue ends up being more expensive than the tier.

Additionally you can set a soft and hard limit and although it's of course more expensive than the current unlimited plan, it's imo still better than the alternatives.

One thing is for sure, I can't go back to Google, DDG or bing, Kagi is just so much better.

It doesn't suck per say... it comes down to the course and your own interest in learning a language. To me Duolingo worked well as an entry barrier for getting started, the app interface is polished and the gamification aspects makes it enjoyable and sometimes pushes you do to a bit more than you'd otherwise have done.

I've been doing the Japanese course for 2 years continuously, during the first year I only used Duolingo but as I progressed and became better at understanding the basics, I sought other apps for the things that Duolingo lacked. nowadays I use 'renshuu' as well for getting a deeper understanding of some areas, and 'kanjigarden' to learn all the various kanji that one can bump into.

Last but not least, I also use Takoboto as a dictionary to regularly look up stuff that's not well explained.

I pay for it to get the benefit of Google's better search results without ads. It's better than DDG, Bing, Google and Brave Search based on my experience... I've had Kagi subscription since October 2022.

Adding to this excellent explanation, the guard is compile time checked too, so you can't accidentally screw up the early return like one could in say c or c++

It might seem like a quality of life feature to some, to me however it's an essential feature of swift and one of the better ones.

In many cases yes, but svg support has been available in xcode since ver. 12 and before that pdf had been available. As a consultant I haven't worked on a project yet where vector assets has been chosen over bitmap

If you think it looks unpolished, then you're missing the point of having different UI kits. Mobile and desktop are not the same and does not have the same needs, eg. fancy animations when scrolling or tapping or moving between interfaces.

The world of iOS and iPadOS is meant for touch and caters to the consumer. Mac OS is meant for mouse and keyboard caters to consumers but it also serve as a development platform for its app ecosystem. As such it need to get out of way too.

Both platforms fulfill different needs. I'm personally glad Mac OS does not look nor behave like either iOS nor iPadOS, even though Apple is definitely trying to add a bit of the same UI with each Mac OS iteration.