- taminka parentthat's just called having a complete project in a stable language lol, not everything needs a change every week to function well...
- unfortunately just an inherent consequence of treating software as needing continuous improvements and having yearly release targets, you can't just say that this settings menu is already perfect as is, you have to change it, therefore everyone perpetually shuffles around ui and adds features that nobody wants
- can anyone explain why telegram doesn't use an audited e2e implementation? is it really because they wanted more convenient and faster cross-device sync? have they been threatened and/or backdoored by the fsb? they basically stole vk from him, but left him alone w/ telegram?
it's suspicious, but at the same time, iirc, nobody's been able to find a vulnerability in their encryption protocol :shrug
- how are ovh and hetzner like an order of magnitude cheaper than everyone else? maybe w/ a lot of sharing for VPSs it's understandable, but they also sell dedicated for super cheap...
is it a honeypot? also did ovh change prices recently? I remember checking a couple years ago and it was more expensive vs hetzner
- unfortunately this is an inherent property of a system (software in this case) that punishes stability and rewards changes for the sake of changes
if you don't modify your library, app, OS, etc for 2 years, it's perceived as abandoned or obsolete, meaning even if you're achieved perfection in your product in terms of ui, you can't stay there, you must move forward and break it (i'm not talking about bugs or security vulnerabilities here, only the functionality itself)
prominent example is w/ microsoft word, where they kept adding an absurd number of features simply bc they felt like they had to, since ppl were paying for it, and this will KEEP HAPPENING TO EVERYONE so long as the software keeps moving at breakneck speed and backwards compatibility and stability are thrown out of the window...
- spotlight routinely fails to find existing files, newly added programs or system stuff, settings search ranks search results incorrectly, doesn't have fuzzy matching, fails to find stuff, for some languages parts are unfindable in that language at all, parts of the ui are sometimes straight up untranslated...
like, you learn to work around this, mostly by just using raycast, but it's just unacceptable that they've spent BILLIONS on useless ai shit, while stuff THAT HAS WORKED CORRECTLY ALREADY IN THE PAST gets broken and goes unfixed for literal years
- > Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.
C has macros, which is the ultimate form of hidden control flow, where a symbol can expand to any arbitrary code... also hidden allocations and functions that can error, which you could argue isn't traditionally understood as hidden control flow, but it's still nice to know when stuff is allocated and/or can create an error
- only a very small percentage i think, for example only 4.2% work anywhere in the medical field [1]
[1]https://www.uscis.gov/sites/default/files/document/reports/o...
- any language that has a standardised build system (virtually every language nowadays?), but doesn't have a centralised package repository, such that including a dependency is seamless, but takes a bit of time and intent
i like how zig does this, and the creator of odin has a whole talk where he basically uses the same arguments as my original comment to reason why odin doesn't have a package manager
- i just realised that my comment sounds like it's praising python's package management since it's often so inconvenient to use, i want to mention that that wasn't my intended point, python's package management contains the worst aspects from both words: being centralised AND horrible to use lol
my mistake :)
- i'm saying that ease of dependency inclusion should not be a main criterion for evaluating how good a build system is, not that it isn't the main criterion for many people...
like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?
- lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management
the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and all the related issues like security, build times, etc
how good a build system isn't equivalent of how easy it is include a dependency, while modern languages should have a consistent build system, but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies