Readit News logoReadit News
qalmakka commented on Rust in the kernel is no longer experimental   lwn.net/Articles/1049831/... · Posted by u/rascul
jcranmer · 8 days ago
There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran, and BASIC-with-an-asterisk, are the only languages to really have done so), and Perl is the only one I would risk money on departing in my lifetime.

I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.

qalmakka · 8 days ago
We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.
qalmakka commented on Rust in the kernel is no longer experimental   lwn.net/Articles/1049831/... · Posted by u/rascul
obviouslynotme · 8 days ago
A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript.

There will be small niches leftover:

* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.

* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.

* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.

* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.

* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.

qalmakka · 8 days ago
> Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

Modern embedded isn't your grandpa's embedded anymore. Modern embedded chips have multiple KiB of ram, some even above 1MiB and have been like that for almost a decade (look at ESP32 for instance). I once worked on embedded projects based on ESP32 that used full C++, with allocators, exceptions, ... using SPI RAM and worked great. There's a fantastic port of ESP-IDF on Rust that Espressif themselves is maintaining nowadays, too.

qalmakka commented on Micron Announces Exit from Crucial Consumer Business   investors.micron.com/news... · Posted by u/simlevesque
jmward01 · 14 days ago
I am a huge believer in AI, but the build-out right now, justified or not, will definitely hit a slowdown at some point. Not being diverse in their customer base could really hurt them later on. Sometimes you keep something going for tomorrow's business even if it is costing you something today.
qalmakka · 13 days ago
There's a huge difference between "AI" and "tech bros and finance guys getting amazed by an LLM that talks back to them without realising it's just a language model and not intelligence, so they started chucking the massive piles of cash they had lying around the world to evade taxes to them in a pyramid scheme of colossal scale". We currently are heading more and more towards the latter, and when it crashes it will sow so much distrust and curse the "AI" name so much that we'll probably get a decades-long AI winter after that. In the end none of this nonsense will help the world towards getting better AI any time soon.

Already most "AI researchers" outside of the big corps have basically turned in the last 3 years from "people training their models and doing research" to "webdev plugging into other people's APIs to use LLMs they don't know crap about". When, not if, the big AI bubble bursts, the damage done to the sector will be immense

qalmakka commented on The Linux Kernel Looks to “Bite the Bullet” in Enabling Microsoft C Extensions   phoronix.com/news/Linux-6... · Posted by u/keyle
messe · a month ago
The important one is "Unnamed Structure and Union Fields"[1], in particular unnamed structs and union fields without a tag.

ISO C11 and onward allows for this:

    struct {
      int a;
      union {
        int b;
        float c;
      };
      int d;
    } foo;
In the above, you can access b as foo.b. In ISO C11, the inner struct/union must be defined without a tag. Meaning that this is invalid:

    struct {
      int a;
      union bar {
        int b;
        float c;
      };
      int d;
    } foo;
As is this: union bar { int b; float c; };

    struct {
      int a;
      union bar;
      int d;
    } foo;
-fms-extensions makes both of the above valid. You might be wondering why this is uesful. The most common use is for nicer struct embedding/pseudo-inheritance:

    struct parent {
      int i;
      void *p;
    };

    void parent_do_something(struct parent *p);

    struct child {
      struct parent;
      const char *s;
    };

    struct child *c;
    struct parent *p = (struct child *)c; // valid
    parent_do_something(p);
    c.i++; // valid
[1]: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html

qalmakka · a month ago

   struct parent *p = (struct child *)c; // valid
Note that this cast would be valid without the MS extensions too, you can always cast a pointer to a struct to a pointer to its first member and viceversa. What the MS extensions allow you to do is to just do `c->i` directly, without having to name the parent

qalmakka commented on Jujutsu at Google [video]   youtube.com/watch?v=v9Ob5... · Posted by u/Lanedo
Ferret7446 · 2 months ago
Not that there are any other options. You're not gonna run datacenters on Mac boxes or Window s, nor would you want to pay a Unix vendor
qalmakka · 2 months ago
> UNIX vendors

Well FreeBSD exists, just look at Netflix

qalmakka commented on Programming in Assembly Is Brutal, Beautiful, and Maybe Even a Path to Better AI   wired.com/story/programmi... · Posted by u/fcpguru
antonvs · 2 months ago
Re your counterpoint, learning to write small extremely toy programs in assembly isn’t hard. But using it to write bug-free programs with non-trivial functionality is much more difficult.
qalmakka · 2 months ago
Yeah it's all shit and giggles until you need to allocate memory and handle it. Or when you need to use vector instructions or some CPU-specific stuff. Then you start understanding why people call it nightmarish
qalmakka commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
qalmakka · 2 months ago
OT: using the `strcasecmp` family of functions is basically asking for trouble - unless you've previously set the locale to "C", which is basically the only locale with a defined behaviour. Otherwise you're basically bound to run onto very funny internationalisation issues you'd rather know nothing about (and fail the Turkey Test)
qalmakka commented on Windows Subsystem for FreeBSD   github.com/BalajeS/WSL-Fo... · Posted by u/rguiscard
rkagerer · 2 months ago
I realize not everyone will care about this, but I find the naming for these WSL-like subsystems is confusingly backwards. i.e. It should have been Linux Subsystem for Windows, or Window's Subsystem for [Linux | FreeBSD | etc].
qalmakka · 2 months ago
yeah especially since it stopped being an actual subsystem in the Windows NT sense of the term with WSL2 - it's a hecking virtual machine that's very convenient to run, but that's like saying that WinBoat is a "Linux subsystem for Windows" - totally ludicrous
qalmakka commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
qalmakka · 2 months ago
Integer operations, the one thing in computers where basically there's no non-annoying way to do them right except being over pedantic with checks
qalmakka commented on RedoxFS is the default filesystem of Redox OS, inspired by ZFS   doc.redox-os.org/book/red... · Posted by u/doener
wraptile · 3 months ago
I feel like MIT license will prevent this from ever becoming a linux alternative unless of course they switch to something more sane later on.
qalmakka · 3 months ago
Linux didn't win because it was GPL'd, it won because it was the only real alternative back in '92. The BSDs were all caught up in the moronic SCO lawsuits of the time, otherwise we'd all be using FreeBSD or some other 386BSD variant today instead of Linux. The GPL was a nice bonus but it isn't the real secret sauce that has powered Linux's growth, it was mostly good timing.

That doesn't mean that I'd rather see some form of copyleft in place (like the MPLv2) or at least a licence with some kind of patent protection baked in (like the Apache 2.0), the X11/MIT licences are extremely weak against patent trolls

u/qalmakka

KarmaCake day4736November 10, 2017View Original