GCC Rust Approved By Steering Committee, Likely To Land For GCC 13

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MajorBarnulf
    replied
    Originally posted by Sin2x View Post

    ... you have missed the point of the article: Rust is a badly designed jack-of-all trades language that has only one thing going for it -- and this thing, safety, is irrelevant to kernel programming. ...
    Hi, slightly off topic, but I will point out that this is a very reductive view of the language and its features:

    A lot of people (including Drew DeVault apparently) are overlooking aspects of the languages that are not directly related to safety.
    For instance the convenience and strength of the type system: with the right tools, a well designed API can provide security, but also documentation and some degree of testing done directly by the compiler (c.f. thread safety provided by the standard library).
    But also stuff like traits which allows for an OO approach in a much more concrete, pure and simple to understand way as C++.
    Even actual innovating stuff like the hygienic macro system and other aspects of meta programming, (which in themselves may significantly simplify a lot of C projects pipelines).
    And the thing which I find most emblematic of Rust: the algebraic types. (yes I know about Ocaml)

    All in all, it is true there is a lot of features packed with rust -especially through the rustc front end- but luckily you can ignore a great portion of them without too much pain (except things like the borrow checker, of course) which in itself is a plus: you will be able to write a lot of code without having to eat a lot of doc.
    But it is also an inconvenience because people that do not take try to advantage of these features will not understand the parts of the language that attracts so many people.

    About kernel and system programming, it is true that these features have never been truly used, but it is mainly because they really never were available as such a low level in the first place, but now that it is; maybe there is room for a lot of QoL improvements and code simplification (which would be greatly welcome, especially on projects like the Linux kernel).

    It is truly hard to assess where all of this will go.. there is indeed a lot of noise both because of a few but loud part of the rust community that may be seen as zealots, also because of the friction with other communities competing for the support of their language ecosystem, but mainly because of the skepticism around new technologies in general that inevitably applies to Rust.

    For now, it is simply impossible to see any core parts of the kernel being updated to rust, the tool chain and the devs are not adapted, but in the far future it is still a possibility...
    my guess is that rust will become a tool for interfacing with other code bases like kernel modules and for writing security or performance focused parts.

    Leave a comment:


  • Developer12
    replied
    Originally posted by archkde View Post

    Or you could port LLVM to these architectures, which might turn out to me be less effort and have more benefit in the end.
    Linux supports more than just x86, arm, and RISC-V. There are quite literally dozens and dozens of architectures supported by linux and not LLVM. Many of them are old and not worth porting to LLVM at all, but are still required support by linux.

    It's a fuck of a lot easier to port one frontend than to port dozens of backends. Especially when backends require intimate architectural knowledge.

    Leave a comment:


  • uid313
    replied
    Originally posted by archkde View Post

    Actually, using modules is not that different from the other languages you mentioned, except that "using" or "import" is called "use". "mod" is a bit awkward at first, but it has a number of advantages over a module structure solely determined by the filesystem layout (for example, modules can be defined inline or compiled conditionally).



    Ah, I totally forgot about it being a third-party plugin, because cargo has such a great plugin integration
    I don't like inline-defined modules.

    Leave a comment:


  • archkde
    replied
    Originally posted by uid313 View Post

    I still find the module system tricky.
    Other languages like in C#/.NET, Java or PHP you just use "using Foo.Bar.Baz;" (C#) or "use Foo\Bar\Baz;" (PHP) which is much easier.
    In JavaScript you have to do "import { foo, bar, baz } from Baz" so its a little bit trickier, and it also has some other "import * from Baz" syntax so it is a bit trickier but still easier than Rust.
    In PHP the modules are scoped relatively to the folders they are in, so its a bit trickier C#, Java and PHP but still easier than Rust.

    Rust is the worst, you have two statements, both mod and use, not just one statement. It also has many variants such as use crate::foo, and I think use this::foo, or use base::foo, or something like that. Then you have to do weird things like if you have a folder named foo then you also need to put a file named foo.rs outside that folder that have to declare pub mod line for each file in the folder. It is just awkward.
    Actually, using modules is not that different from the other languages you mentioned, except that "using" or "import" is called "use". "mod" is a bit awkward at first, but it has a number of advantages over a module structure solely determined by the filesystem layout (for example, modules can be defined inline or compiled conditionally).

    Thanks, I didn't know about this.
    I wish this was easier and worked out-of-the-box without having to install some third party Cargo plugin.
    In the JavaScript world this is much easier with npm since npm already has an outdated command option without any third-party plugins.
    Ah, I totally forgot about it being a third-party plugin, because cargo has such a great plugin integration

    Leave a comment:


  • ssokolow
    replied
    Originally posted by uid313 View Post
    Yeah, but if mod.rs is the old way, then I rather want to get away from it, and move to something easier and more modern, not be stuck in the past.
    It's old in the sense that it's the first one they thought of. Shirking something purely because it's old takes you down the road to spending all your time buying As Seen on TV junk purely because it's new.

    They're both equally valid ways to lay out a project with their own strengths and weaknesses.

    Leave a comment:


  • uid313
    replied
    Originally posted by ssokolow View Post

    Python has:
    • import mod1.mod2, mod3
    • from mod1 import ident1, ident2
    • from mod1 import *
    • from . import ident1
    • from .. import ident1
    For mod1 to be considered a package so you can import mod1.mod2, it must contain __init__.py. ...__init__.py may be empty, but it must exist. Also, if you're writing a compiled extension for Python in C/C++/Rust/etc., you cannot create submodules, so you must do import mod1 and then mod3 = mod1.mod2.mod3. They also have __main__.py which is what gets run when you python -m mod1.mod2.mod3, despite it seeming more consistent to just allow it to invoke __init__.py with the pre-existing if __name__ == '__main__': trick.

    ...and there are rules for when from . and from .. are allowed that'll trip you up, so they recommend not using them, despite them being only added around the time of Python 3.x IIRC.

    If you want to import something from a path, such as to make a plugin system, you have to dig through the manual and figure out how to rebuild the relevant parts of the import system from component pieces because all the obvious stuff indirects through the global search path and doesn't take filesystem paths.

    I'm sure there are other examples, but Python is my big area of prior expertise.
    You're right, maybe Python is a bad comparision if I want to make a point that other languages are easier, the Python module system is pretty shitty too.

    Originally posted by ssokolow View Post
    (eg. C will trip you up if you don't write include guards or use #pragma once and PHP requires you to know the difference between include, include_once, require, and require_once.)
    Yeah, now that I think of it, PHP could be confusing too, because as you mentioned there those, so its a couple.
    In modern PHP when you use namespaces and configured an autoloader it could be quite nice tho with just using a use statement, but yeah that's only as long as an autoloader is configured.

    Originally posted by ssokolow View Post
    "Old" does not mean "deprecated". In fact, Clippy has lints to prefer/require/reject either. (mod_module_files and self_named_module_files)
    Yeah, but if mod.rs is the old way, then I rather want to get away from it, and move to something easier and more modern, not be stuck in the past.

    Originally posted by jacob View Post

    Frankly I find that the module system is probably one of the worst parts of Rust. It's very confusing and complicated and yet, as you say, ultimately it's nothing more than namespaces. I wish Rust had generic modules like Ada or OCaml (but those languages it's still easier and more intuitive than what Rust does today).
    Yeah, overall I like Rust, there are so many great things about it, so many things they did right. Just the module system is a source of confusion for me.

    Leave a comment:


  • jacob
    replied
    Originally posted by uid313 View Post

    Yeah that all is pretty overwhelming and overly complicated to me. Other languages dont have that, it's so much easier in other languages.
    Other languages just have namespaces, then you import that namespace, super easy.
    Frankly I find that the module system is probably one of the worst parts of Rust. It's very confusing and complicated and yet, as you say, ultimately it's nothing more than namespaces. I wish Rust had generic modules like Ada or OCaml (but those languages it's still easier and more intuitive than what Rust does today).

    Leave a comment:


  • ssokolow
    replied
    Originally posted by ubuntulove74 View Post
    Thanks to everyone who brought up Drew DeVault in the comments and talked about his new programming language (hare lang)that I had never heard of so I was curious to look it up and see what it was and after a while I saw that This is the same language that I made in my mind a long time ago!
    This made me seriously consider it and migrate to it from Rust!
    It always makes me happy to see people getting what they want without having to duplicate effort.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by uid313 View Post
    Yeah that all is pretty overwhelming and overly complicated to me. Other languages dont have that, it's so much easier in other languages.
    Other languages just have namespaces, then you import that namespace, super easy.
    Python has:
    • import mod1.mod2, mod3
    • from mod1 import ident1, ident2
    • from mod1 import *
    • from . import ident1
    • from .. import ident1
    For mod1 to be considered a package so you can import mod1.mod2, it must contain __init__.py. ...__init__.py may be empty, but it must exist. Also, if you're writing a compiled extension for Python in C/C++/Rust/etc., you cannot create submodules, so you must do import mod1 and then mod3 = mod1.mod2.mod3. They also have __main__.py which is what gets run when you python -m mod1.mod2.mod3, despite it seeming more consistent to just allow it to invoke __init__.py with the pre-existing if __name__ == '__main__': trick.

    ...and there are rules for when from . and from .. are allowed that'll trip you up, so they recommend not using them, despite them being only added around the time of Python 3.x IIRC.

    If you want to import something from a path, such as to make a plugin system, you have to dig through the manual and figure out how to rebuild the relevant parts of the import system from component pieces because all the obvious stuff indirects through the global search path and doesn't take filesystem paths.

    I'm sure there are other examples, but Python is my big area of prior expertise.

    (eg. C will trip you up if you don't write include guards or use #pragma once and PHP requires you to know the difference between include, include_once, require, and require_once.)

    Originally posted by uid313 View Post
    Yeah, I heard that there is a new way and that the old way is mod.rs, but I still see the old way widely used when I look inside crates with VS Code.
    Also this new way might be better than the old way, but I still don't like it. It is still confusing and awkward to have to put a filename with the same name as the folder and have it outside the folder. I want everything that relates to that folder to be inside that folder and not have a file outside.
    Very awkward. This is a big fail for the Rust language, because so many other languages do this so much easier.
    "Old" does not mean "deprecated". In fact, Clippy has lints to prefer/require/reject either. (mod_module_files and self_named_module_files)
    Last edited by ssokolow; 14 July 2022, 12:38 AM.

    Leave a comment:


  • Ironmask
    replied
    Originally posted by conner View Post
    I find it incredible how easy it is to trigger Rust fans. I've never seen a language be held on an immaculate pedestal that to the extent that Rust is.
    I'm not sure what world you're from, but I've only seen Rust users act pretty chill. It's when you mention Rust do other people come frothing at the mouth that people get angry for no reason. I've even trolled around a few times by blindly saying "they should rewrite it in Rust" and watched the thread explode into gore.
    Oh yeah, not to mention that every post in favor of Rust just talks about it's features, and every post against it can largely be summed up as "look at these angry cultists using this new gimmick language I don't understand, see how many tantrums they throw? obviously nobody should use it" which is, embarrassing.
    Last edited by Ironmask; 13 July 2022, 05:51 PM.

    Leave a comment:

Working...
X