• 0 Posts
  • 57 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle



  • Ultimately though, the thing with English is that it’s a complete dumpster fire of a language, and literally every rule has nearly as many exceptions as it does cases where it applies. The language didn’t evolve so much as it metastasized in fits and starts. Nearly every feature of the language from its words, to spelling, to grammar was either awkwardly bolted on from some other language, or it was just invented from whole cloth by some random printer or author (often with highly dubious logic driving it). This is just the latest iteration of that process with people inventing distinctions between characters that didn’t really exist in the past. Single quote is already a bit of an aberration, eventually it will likely just die out in actual usage and we’ll be left with this abortive calcified single quote character in the UTF character set to mark where it used to be.




  • Which is still stupid as a single quote is an apostrophe. Quotation marks of any kind didn’t really exist prior to the creation of the printing press (this is also why there are many many local variants). There were several marks that were used to emphasize or highlight passages, but not to directly mark something as a quotation. When printers found themselves in need of a character they didn’t have they re-used existing characters (since characters were literally hunks of metal and they couldn’t exactly go out and whittle a new one).

    For apostrophe they just flipped a , upside down, and thus the apostrophe was born (a similar mark used to denote where something was omitted was used in writing, so the apostrophe did exist prior to that point, but it was written more in the style of a carat above the word typically).

    When they needed a way to mark quoted text different printers used different characters. For some they re-used the same trick as they used for apostrophe and just used upside down commas and thus the single quote was born. Others did the same, but in order to differentiate it from the apostrophe they double it up, hence the " character is literally a double upside down apostrophe. Some used either single <> or double << >> brackets to denote quotations. Some use a comma and apostrophe E.G. ,a quote’ or doubled it E.G. ,another quote’’ (N.B. it looks like the comment renderer on here is eating the double , replacing it with a single , and possibly replacing the double ’ with a single " character). It was all down to whatever the local printers had available and felt was appropriate.

    Hence getting bent out of shape about if a ’ is an apostrophe or a single quote is utterly stupid, it’s both as they’re literally the same character.


  • if you use a garbage collector which is perfectly suitable unless you write low level embedded systems or oses

    Or games, or realtime systems, or high reliability/mission critical systems, or high performace systems. There’s a long list of programs that GC isn’t suitable for for one reason or another.

    and even if you use something like C or C++ where you manually allocate or deallocate, if the app is properly tested memory issues won’t happen.

    There’s about four decades of security vulnerabilities in extensively tested and widely used software that says this is absolutely false.


  • Cargo is doing too many things at once. It’s a build system but also a package manager but also manages dependencies? Idk what to even call it.

    Somewhat agreed, but it’s a very difficult problem to solve. No language has yet come up with the perfect build tool. JS is on what, like the 12th build tool in as many years now? Some serious throwing stones in glass houses vibes here.

    Syntax is very confusing for no reason. You can’t just look at rust code and immediately know what it does.

    Strongly disagree on this point. Those extra glyphs in Rust are not just cosmetic, each one means something very specific and conveys very important information.

    Having to pollute your code &, ? and .clone() everywhere to deal with ownership

    You don’t “deal with” ownership, it’s an incredibly powerful tool you use. This just sounds like you haven’t really understood what the borrow checker is actually doing and the hundreds of problems it solves for you. I can not count how many times now I’ve been working in another language and had the thought “I could solve this with the borrow checker”

    Js is way more readable.

    JS is not more readable, JS is just far less detailed. It omits a vast swath of information such that you have almost no idea what it’s actually doing. It feels easier to you because you don’t care about any of the details, but those details become vitally important when things stop working and you’re trying to figure out why. This sounds to me like you’ve never had to write any actually complicated code. If all you’re trying to do is chain together a series of HTTP calls and maybe parse a tiny bit of JSON, yeah, Rust is like using a nuke to kill an ant.

    Similarly, Async code starts to look really ugly and overengineered in rust.

    A little bit, but mostly because doing async right is really complicated. Once again no language has a really great solution to this problem yet, they all involve tradeoffs.

    Multiple string types like &str, String, str, instead of just one “str” function.

    Once again it seems you don’t really understand the difference between owned and borrowed values or stack vs. heap allocation and why it matters. Really there’s only one type of String which is String, the others are just different ways of borrowing a String (with different tradeoffs).

    i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript. Even in C you can just write “int” and be done with it

    If all you want is a “int” you can just use i64 for everything and “be done with it” as you say, you’ll just be adding a ton of wasted memory and needless overhead for no good reason. Seems like you just don’t like strong typing. I’m surprised you even bother with TypeScript instead of just using JavaScript.

    Having to use #[tokio:main] to make the main function async (which should just be inbuilt functionality, btw tokio adds insane bloat to your program) yet you literally can’t write code without it.

    You absolutely can write code without using #[tokio:main], you can even use tokio without that, it just saves you having to write a bunch of boilerplate to initialize tokios executer and pass your async functions to it. You can even use async functions without tokio, you just need to provide your own executor. Async in Rust is still pretty new and some of the rough edges are still being worked out, it will get smoother, but honestly the things you’re complaining about aren’t even the annoying parts about it.

    Speaking of bloat, a basic get request in a low level language shouldn’t be 32mb, it’s around 16kb with C and libcurl, despite the C program being more lines of code. Why is it so bloated? This makes using rust for serious embedded systems unfeasible and C a much better option.

    I have no idea what you’re doing to generate code sizes like that, but I guarantee you could get a significantly smaller program in Rust that does exactly what the C code is doing. As for embedded this is patently false. I personally use Rust regularly on embedded devices that don’t even have 32mb of RAM on them.

    With cargo you literally have to compile everything instead of them shipping proper binaries. Why???

    This isn’t a cargo thing, this is a Rust compiler thing. The Rust ABI hasn’t been standardized which means currently there’s no guarantee that Rust code compiled by one version of the compiler can successfully link against code compiled by a different version. Until not that long ago C++ actually had the same problem. This will eventually get fixed, but the language team feels things are still moving too fast to define a concrete standard yet.

    Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.

    Rust is still pretty new, so a lot of libraries are still in active development, but there are already many excellent and very well documented libraries. Axum is literally one of the newest web frameworks in Rust and didn’t even exist that long ago. I’ve seen far worse documentation for JS libraries (and don’t even mention C, the gold standard there is practically a man page that’s just a glorified header file).

    As for “memory safety”, it’s a buzzword. Just use a garbage collector.

    Memory safety is not “just a buzzword”, there’s a reason all the top vulnerabilities for decades now are all memory safety issues. As for a garbage collector, good luck with that when writing embedded software or a kernel.

    The rest of your rant basically boils down to “my particular simple use case doesn’t see much value from what Rust provides”, which is fine. If you don’t need the power of Rust, use something weaker, not every problem needs the nuclear option, sometimes you just need something quick and dirty that will run a few times before it falls over. Hell, sometimes a quick Perl script is the right solution. I mean, not often, but it does sometimes happen. When you do find a problem that your quick and dirty approach isn’t working on then you’ll see the value in Rust.



  • It’s an interesting point but I think it kind of confuses two different but related concepts. From the perspective of the library author a vulnerability is a vulnerability and needs to be fixed. From the perspective of the library consumer a vulnerability may or may not be an issue depending on a lot of factors. In some ways severity exists in the wrong place, as it’s really the consumer that needs to decide the severity not the library.

    A CVE without a severity score I think is fine. Including the list of CWEs that a particular CVE is composed of I think is useful as well. But CVE should not include a severity score because there really isn’t a single severity but a range of severities depending on specific usage. At best the severity score of a CVE represents a worst case scenario not even an average case, nevermind the case for a specific project.


  • Yeah, our security team once flagged our app for having a SQL injection vulnerability in one of our dependencies. We told them we weren’t going to do anything about it. They got really mad and set up a meeting with one of the executives apparently planning to publicly chew us out.

    We get there, they give the explanation about major security vulnerability that we’re ignoring, etc. After they said their bit we asked them how they had come to the conclusion we had a SQL injection. Explanation was about what you’d expect, they scanned our dependencies and one of the libraries had a security advisory. We then explained that there were two problems with their findings. First, we don’t use SQL anywhere in our app, so there’s no conceivable way we could have a SQL injection vulnerability. Second our app didn’t have a database or data storage of any kind, we only made RESTful web requests, so even if there was some kind of injection vulnerability (which there wasn’t) it would still be sanitized by the services we were calling. That was the last time they even bothered arguing with us when we told them we were ignoring one of their findings.



  • Yep and that’s fair, but it’s still really critical that those of us that can migrate do so. It’s a chicken and egg problem. Developers won’t feel pressured to support Linux if there’s no sizable user base, but the user base won’t grow until developers provide support for Linux. He even mentions that in that video. There’s a reason I’m only this year planning on switching my primary desktop from Windows to Linux and it’s because of how good Proton has gotten. I’ve already checked every game in my Steam library and while it’s not 100% of the library that runs, everything that doesn’t is something I don’t care about.


  • Nah, Linux still only accounts for about 2% of all users on Steam (active per month) so it has a long way to go still, but at least it’s heading in the right direction. If you count only English speaking Steam users that number climbs to over 5%. If Linux can get to and reliably maintain 10% that’s probably good enough to make it a first class target for even AAA releases, but it’s not there yet. The fact that so many games run fine under Linux these days is almost entirely down to the effort Valve has sunk into Proton making it relatively easy for devs to check Steamdeck support off without needing to really put much work in at all.



  • We don’t need everyone to migrate, just enough that companies and developers feel obligated to support Linux. We’re slowly getting there. Valve throwing their weight behind Linux for gaming was a massive win for Linux. Another important factor is the rise of the mobile first generations and the fact that at its core Android is Linux based. It’s not completely trivial to port an Android app to Linux but it’s at least no worse than porting it to Windows.

    Microsoft may still have a stranglehold on corporate desktops, but they’ve long since lost the battle for servers and their hold on the home desktop is slipping a little more each day. Losing a significant chunk of gamers to Linux would be a massive blow to MS because it has been one of the few really unassailable markets for them historically.



  • It depends. There’s a lot of areas in coal country that are deeply conservative in part because conservative politicians promise to protect coal jobs and to disrupt renewables. That of course varies by location, but E.G. Texas which has a large oil company presence is going to have a lot of conservative voters who are anti-renewable because they’ve made their career working in the petroleum industry. So while not every conservative is going to be against solar, quite a lot of them are.


  • That can delay things, but ultimately it will be the US against the rest of the world and no amount of subsidies will be able to offset that. We’re already seeing the early stages of that with China having invested heavily in solar. Cheap Chinese made solar panels are starting to drive the cost of solar installs down and China is still ramping up. Between the public backlash against fossil fuels on one side, and increasing economic pressure on the other eventually they’ll cave and phase the subsidies out.