Announcement

Collapse
No announcement yet.

Sovereign Tech Fund Providing €300k For GNU libmicrohttpd

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

  • #21
    Originally posted by oleid View Post
    Ah, the obligatory waiting for somebody to mention rust crate. Clearly nothing better to do.
    Anyone who can mention C is busy debugging 24/7

    Comment


    • #22
      Originally posted by V1tol View Post

      Anyone who can mention C is busy debugging 24/7
      But apparently they don't like rust keep writing similar stuff in any thread, no matter it is related to rust or not. Probably to provoke flame wars or something.
      Last edited by oleid; 07 June 2024, 10:03 AM. Reason: clarification

      Comment


      • #23
        Originally posted by oleid View Post

        Indeed. But apparently they don't like rust keep writing similar stuff in any thread, no matter it is related to rust or not. Probably to provoke flame wars or something.
        oh please just because people like c does NOT means they're always debugging 24/7 sounds like you just have no idea what you're talking about maybe go learn how to write proper C code before you criticize it its actually very powerful and a lot of professionals prefer it over rust which is trying so hard to be something its not and the problems it brings in are a whole different story don't get me started on rust amateurs WAKE UP and stop spreading this nonsense if you have no clue seriously

        Comment


        • #24
          Originally posted by bhptitotoss View Post

          oh please just because people like c does NOT means they're always debugging 24/7 sounds like you just have no idea what you're talking about maybe go learn how to write proper C code before you criticize it its actually very powerful and a lot of professionals prefer it over rust which is trying so hard to be something its not and the problems it brings in are a whole different story don't get me started on rust amateurs WAKE UP and stop spreading this nonsense if you have no clue seriously
          Please use proper punctuation.
          By the way, I'm programming embedded C professionally at my day job. You should really try to calibrate your humor detection.

          Comment


          • #25
            The USA should do the same thing x20

            Comment


            • #26
              Originally posted by ssokolow View Post
              What a trash article to link. He is conflating binary dependencies managed for your by the distro, with stuff your buildsystem downloads off the internet, and which always requires the latest untested compiler to build. It is NOT the same. if JS and Rust worked like deb or rpms, it wouldn't be such a shitshow.

              Comment


              • #27
                Originally posted by carewolf View Post
                What a trash article to link. He is conflating binary dependencies
                ReadThe impact of C++ templates on library ABI by Gentoo's Michał Górny back in 2012 (before Rust was anything but a hobby project).

                Your non-Rust dependencies aren't as independent and binary as you think and it's because dynamically linking code containing templates/generics is an unsolved problem. Rust is actually better than C++ on that front since, unstable ABI aside, it can store partially compiled bytecode for generics in its libraries instead of just omitting it from them.

                Also, the "gotta go deeper" part I linked to was explicitly how, for want of something like Cargo, every C project embeds bespoke or header-only duplicates of functionality that it's then unfeasible for package managers to split out into library packages and deduplicate.

                Go read "gotta go deeper". I'd quote the whole thing here, but it mentions function names that cause Phoronix's IDS to think I'm trying to exploit it and reply with error 403.

                Specifically, the part ending with this:

                So, yeah. An argument I’ve heard against the Go/Rust paradigm of statically linking everything is “you end up with bunches of copies of the same library code compiled into each different program!” All I can say to that is… lol. That said, with these vendored utility libraries there’s a strong incentive to keep them small, simple and task-specific, which is good. On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?
                The current situation is a "head in the sand" reaction to the inevitability of languages like C, C++, Go, and Rust having code that is a separate dependency, but cannot produce a separate library (either because it's too simple in C's case, or because of how it integrates in all four cases), and the proper solution (at least until the templates/generics problem is solved, if it ever is) is to extend the build tooling so it can graft the dependency tree encoded in files like Cargo.toml onto its own tracking of what needs to be rebuilt when a dependency needs to be bumped.

                Originally posted by carewolf View Post
                managed for your by the distro
                For me to respond to that, I'm going to need some more detailed points on why you see "managed by your distro" as virtuous... though I can say that, at least with Cargo.lock, nothing inherently prevents distros from managing dependency versions and rebuilds there too.

                Originally posted by carewolf View Post
                with stuff your buildsystem downloads off the internet
                Your project's Cargo.lock file contains SHA256 hashes for all dependencies, which Cargo will verify on download, and Crates.io is an immutable store where cargo yank can't prevent a Cargo.lock file from referencing and downloading versions, only the admins can actually delete something, and they promise to only do that for malware or stuff they're legally compelled to.​

                Cargo has cargo fetch and the --offline option for things like cargo build to separate downloading from building on a "single-project, right-now" basis.

                Cargo has cargo vendor to automate the process of vendoring your dependencies without losing the ability to automatically check for new releases.

                Cargo also has facilities for swapping in a private mirror of some or all of Crates.io which should be perfectly suitable for groups like Debian or Red Had to run a private mirror of the dependencies for the packages they ship.

                Originally posted by carewolf View Post
                and which always requires the latest untested compiler to build.
                False. In the early days, that was true, because Rust v1.0 was a minimum viable product, but Rust now has a MSRV (Minimum Supported Rust Version) field for its metadata,there's always been a push in the ecosystem's culture to stop depending on new features once the compiler and standard library mature to the point you actually need to write something maintainable, and there's work to add new Cargo features to make it easier to choose and lint your MSRV to make sure you don't accidentally depend on something that was added later.

                The only way C and C++ do better is the "Latin is a dead language" effect... you can't accidentally depend on a method introduced in a newer version of C if C is an unchanging fossil that never gains new methods.

                Originally posted by carewolf View Post
                if JS and Rust worked like deb or rpms
                APT and RPM are to C as Cargo is to Rust. As that Michał Górny post details, they bake in enough C assumptions that even C++ makes them creak under the strain. They're only OS package managers because "UNIX is a C IDE masquerading as an operating system".

                Originally posted by carewolf View Post
                it wouldn't be such a shitshow.
                [citation needed] (that Rust actually IS a shitshow and that you're not just assuming that all language-specific package managers are NPM.)
                Last edited by ssokolow; 08 June 2024, 02:19 PM.

                Comment


                • #28
                  Originally posted by bhptitotoss View Post
                  oh please [uncapitalized unpunctuated stream of gibberish]
                  If you don't respect your audience enough to write properly, people will ignore what you wrote or tell you to f*** off. Paste your garbled crap into an LLM and ask it to fix it, you lazy clod.

                  Comment


                  • #29
                    Originally posted by Karlson2k View Post
                    Being "memory safe" is not a magic panacea for all problems.
                    There are a lot of other kinds of bugs.
                    Most errors a logical. A well known example is Java:
                    The long-running BBC sci-fi show Doctor Who has a recurring plot device where the Doctor manages to get out of trouble by showing an identity card which is actually completely blank. Of course, thi…


                    And logical ones are the ones a compiler cannot fix. Memory related errors are luckily the type of errors a compiler can tell us about. Regarding C++ I've hope that the language sees a #safe keyword which restrict things within compiler-time, similar to Rust. For C I don't have that hope because of the requirement to stay compatible all the way back to C98 or older.

                    Anyway. The super-powers of GCCs and CLANGs --address-sanitizer are awesome. They act at runtime and with unit tests an automatic checks are possible. Using this properly eliminates likely most issues. Please use it


                    PS: We've the most issues with Java applications consuming memory like it is free. It seems the developers think resource handling is something for C or C++ only. The memory strategy and consumption matters, as file/network handles and of course database connections. The other thing are logic bugs where a seemingly innocent data structure grows infinite until an OutOfMemory occurs. And then some people add dependencies like there are no consequences, after framework a, b and c...you will have probably some unintended behavior.
                    Last edited by hsci; 17 June 2024, 08:35 AM.

                    Comment


                    • #30
                      Originally posted by hsci View Post
                      And logical ones are the ones a compiler cannot fix.
                      A powerful type system allows you to teach a lot of new invariants to the compiler. See my previous comment about Rust's Hyper using the typestate pattern to reject "tried to set header but body is already streaming" at compile time. (The typestate pattern basically leverages the borrow checker to enforce correct traversal of a finite state machine at compile time.)

                      Originally posted by hsci View Post
                      Anyway. The super-powers of GCCs and CLANGs --address-sanitizer are awesome. They act at runtime and with unit tests an automatic checks are possible. Using this properly eliminates likely most issues. Please use it
                      Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. -- Edsger W. Dijkstra, "The Humble Programmer" (1972)

                      (Or, in more specific terms, it's very impractical to ensure you've tested everything you need to be testing. SQLite is the only piece of consumer-available software I've ever seen that has 100% MC/DC test coverage.)

                      That said, if you are going in that direction, Rust can be compiled with LLVM features like ASAN, but it also has cargo-miri, which is effectively ASAN, but implemented on top of the MIRI (Mid-Level Intermediate Representation) execution engine for evaluating functions in const initializers for easy cross-testing, and with the goal of being able to catch and provide characteristically high-level and friendly error messages for 100% of Undefined Behaviour so long as your code doesn't step outside of the APIs that Miri's VM supports.

                      Rust also has stuff like Loom and cargo-fuzz.

                      Loom is a testing tool for concurrent Rust code. It runs a test many times, permuting the possible concurrent executions of that test under the C11 memory model. It uses state reduction techniques to avoid combinatorial explosion.
                      ...and that's not counting the interest various sectors of the community have in advancing the state of program verification/proving with things like Prusti, Creusot, Aeneas, and Verus. The promises Rust's type system makes have got a lot of researchers very excited.

                      Comment

                      Working...
                      X