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.
When I was a kid learning BASIC, a lot of beginner examples in books used the (purely decorative) keyword LET for every assignment. Consequently I associate it with "coding like a baby who understands nothing" and still hate to write let to this day.
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.
My understanding of odin was that its good for data oriented.
I haven't really looked into odin except joining their discord and asking them some questions.
it seems that aside from some normal syntax, it is sort of different from golang under the hood as compared to V-lang which is massively inspired by golang
After reading the HN post of sqlite which recommended using sqlite as a odt or some alternative which I agreed. I thought of creating an app in flutter similar to localsend except flutter only supports C esq and it would've been weird to take golang pass it through C and then through flutter or smth and I gave up...
I thought that odin could compile to C and I can use that but it turns out that Odin doesn't really compile to C as compared to nim and v-lang which do compile to C.
I think that nim and v-lang are the best ways to write some app like that though with flutter and I am now somewhat curious as to what you guys think would be the best way of writing highly portable apps with something personally dev-ex being similar to golang..
I have actually thought about using something like godot for this project too and seeing if godot supports something like golang or typescript or anything really. Idk I was just messing around and having a bit of fun lol i think.
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.
The iPhone 13 Pro -> 16 Pro upsizing is ridiculous. The 13 was just the right size, but now they had to change it so they could sell more cases. It's almost phablet-size now. Look at an iPhone 6S by comparison.
The iPhone 13 pro is 71.5mm x 146.7mm x 7.65mm [1] and the iPhone 16 pro is 71.5mm x 149.3mm x 8.25mm [2].
While it did get a tiny bit bigger I wouldn’t have noticed this u less you would look up the spec, especially as it got lighter from 204g [1] to 199g [2] at the same time.
This is an “unpleasable customer” problem. When the 13 Pro was current, everyone was yelling at Apple that it was too thin and that they wanted a slightly thicker phone with more battery life, which is what Apple did.
Not really. The iPhone 13 Pro non-Max was fine. If people want bigger, they can get a Max phablet. It's the 6 and 6 Plus especially that had a bendgate. They're trying too hard to make them too thin, sometimes. I'd be fine with a 5-7 mm thicker. Apple should do what's it's best at... not listening to frivolous criticism.
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
It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)
reply