>almost 2 weeks trying to write a decent JSON parser in C++. >buffer overflow everywhere

>almost 2 weeks trying to write a decent JSON parser in C++
>buffer overflow everywhere
>memory leak in stress tests (file dumping)
>switch to Rust
>finish the work in 1 week
>zero memory leaks until now
I will never try to do file I/O in any language other than Rust again.

A Conspiracy Theorist Is Talking Shirt $21.68

The Kind of Tired That Sleep Won’t Fix Shirt $21.68

A Conspiracy Theorist Is Talking Shirt $21.68

  1. 2 months ago
    Anonymous

    skill issue

    • 2 months ago
      Anonymous

      Imagine automating your development process without compromise in performance and control over your code, definitely not me

      • 2 months ago
        Anonymous

        Rust has worse performance than C#

        • 2 months ago
          Anonymous

          Good bait

        • 2 months ago
          Anonymous

          Hmm... No?

          • 2 months ago
            Anonymous

            Rust has worse performance than C#

            Also: https://kornel.ski/rust-c-speed
            >I'm never worried that I'm going to hit a performance dead-end with Rust. There's always the unsafe escape hatch that allows very low-level optimizations (and it's not needed often).
            >Fearless concurrency is real. The occasional awkwardness of the borrow checker pays off in making parallel programming practical.

          • 2 months ago
            Anonymous

            you have the same "unsafe escape hatch" in C# but in Rust you don't have CLR making optimizations during runtime (and they're only really getting started real work with this, they only recently enabled what they call "Dynamic PGO" by default)

            Hmm... No?

            if you benchmarked no unsafe Rust with C++ you wouldn't see Rust anywhere near the speeds of C++ which just tells me no benchmarks do the same courtesy to C# than they do with Rust

          • 2 months ago
            Anonymous

            >you have the same "unsafe escape hatch" in C#
            How well-integrated is this? Being able to write inline C is one thing but I'm curious if it combines well with nice-looking high-level C# code. Rust is good at this, your pointer tricks might require only a very thin wrapper to expose to safe code.
            (I don't use C# but I've heard good things about it and have a high opinion of Hejlsberg, I'm genuinely curious.)
            >if you benchmarked no unsafe Rust with C++ you wouldn't see Rust anywhere near the speeds of C++ which just tells me no benchmarks do the same courtesy to C# than they do with Rust
            You'd be surprised. The solutions on https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html are interesting. For fannkuch-redux the top 3 programs all use manual SIMD intrinsics but then the best portable solution is Rust with no unsafe blocks. And you see this same pattern for other problems.
            The standard library does use unsafe, as does the third-party thread pool library. But these are very generic components, not import solution tier. You can in practice often write very fast programs without unsafe blocks.
            The benchmarks game does seem to allow unsafe C# for whatever that's worth: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-csharpcore-1.html

          • 2 months ago
            Anonymous

            >How well-integrated is this?
            they have unsafe blocks where you can do pointer shit but they also provide some tools like Span<T> and Memory<T> (and some other's like stackalloc) which let you operate on memory without indirection in safe contexts. It's way better than what most people think because to most people C# immediately forms the word "enterprise" in their heads.

            While 1brc maybe isn't the hardest of challenges (and is mostly about disk reading speed) I found this interesting: https://hotforknowledge.com/2024/01/13/1brc-in-dotnet-among-fastest-on-linux-my-optimization-journey/#results
            the article also displays some performance tricks for C# if you're interested.
            Also C interop is also very easy in C#, but that's not really a good argument for C# being a fast language really.

            As for the benchmark stuff you posted, looks interesting I'll look into those.

          • 2 months ago
            Anonymous

            Interestingly nonlinear curves. Why is there such a hike after around 1 MB?

          • 2 months ago
            Anonymous

            cache maybe

          • 2 months ago
            Anonymous

            Interestingly nonlinear curves. Why is there such a hike after around 1 MB?

            definitely cache, you can see that the cache capacities are marked on the graph too

          • 2 months ago
            Anonymous

            Doesn't all fit in L2 cache (noted as L2 capacity and a small bar between 2^-1 and 2^1, very confusing graph to read)
            Note that most consumer processors nowadays have L1 caches that are 1MB, L2 caches of 16MB+ and L3 caches of 30MB+ and up to 128MB, so this a quite old graph

          • 2 months ago
            Anonymous

            >Note that most consumer processors nowadays have L1 caches that are 1MB, L2 caches of 16MB+ and L3 caches of 30MB+ and up to 128MB, so this a quite old graph
            How much cache is visible to a workload is what matters for the performance characteristics of a benchmark.
            A 7950X3D, for example, does have a total of 1MB L1, 16MB L2 and 128MB L3.
            But each core only has 32KB L1 I$ + 32KB L1 D$, 1MB L2, and either 96MB or 32MB L3 cache shared with the rest of the CCD. So those working set sizes are where you'll see performance cliffs.

          • 2 months ago
            Anonymous

            C# isn't on that graph

          • 2 months ago
            Anonymous

            >-Ofast
            immediately suspect and bad benchmark. it shows rust with iterators is faster than regular C++ but it's framed in the most disingenuous way possible saying that using -Ofast is a default behavior

          • 2 months ago
            Anonymous

            How dangerous is -Ofast? Is there a Rust equivalent, or a way to opt into similar optimizations locally?
            The labels are bad yeah

          • 2 months ago
            Anonymous

            >-Ofast Enables all the optimizations from -O3 along with other aggressive optimizations that may violate strict compliance with language standards.
            very. you're signing up for UB and not even using c++ anymore because it enables optimizations that violate compliance with language standards. there's not even a guarantee optimizations are sound because of how little they're tested, fast flags should be avoided. i can't even easily find a list of the optimizations.

            closest thing rust has is some intrinsics added recently for "fast math" type things but it's only for when you don't care about reassociation of floating point ops to enable vectorization.
            https://doc.rust-lang.org/nightly/std/?search=algebraic
            https://github.com/rust-lang/rust/pull/120718

            there are also interesting issues with clang ir generation related to reassoc and fast flags. it's pretty messy
            https://github.com/llvm/llvm-project/issues/82813

          • 2 months ago
            Anonymous

            >you're signing up for UB and not even using c++ anymore because it enables optimizations that violate compliance with language standards
            I'm interesting in knowing more, do you have a link about this? I'm asking Gemini and it just says some already undefined behavior might become a problem if your code was making assumptions before (which it shouldn't have been).

        • 2 months ago
          Anonymous

          Stay in your lane, dot pajeet.

          • 2 months ago
            Anonymous

            That's actually an impressive lower limit for C#, beats all the other non-C/C++/Rust langs

          • 2 months ago
            Anonymous

            that's not too bad for C shart
            those go average though, lmao

          • 2 months ago
            Anonymous

            C# is very quick given it's garbage collected. It was also created by an Aryan white male, not some disgusting rust troon with a gaping axe wound. Shame objects fricking suck in C#.

          • 2 months ago
            Anonymous

            zero-alloc linq on span when

          • 2 months ago
            Anonymous

            C# is just Java with a low quality ecosystem

          • 2 months ago
            Anonymous

            >nord cuck
            >Aryan
            ??
            ???

    • 2 months ago
      Anonymous

      Ah, yes, the old "skill issue". I wonder if there is any "skilled" C programmer out there because I only see RAM eaters written in C.
      #include <stdio.h>
      #include <memory>

      using namespace std;

      class C
      {
      public:
      C() {printf("Constructor for C: this=%pn", this);}
      ~C() {printf("Destructor for C: this=%pn", this);}

      void setSharedPointer(shared_ptr<C> p) {pC = p;}

      private:
      shared_ptr<C> pC;
      };

      int main(int argc, char ** argv)
      {
      shared_ptr<C> pC(new C);
      shared_ptr<C> pD(new C);

      pC->setSharedPointer(pD);
      pD->setSharedPointer(pC);

      return 0;
      }

      • 2 months ago
        Anonymous

        rust doesn't protect against memory leaks

        • 2 months ago
          Anonymous

          It doesn't guarantee no memory leaks but it protects against it significantly (on the same level as modern C++). There are only a couple of cases in which they can happen

          • 2 months ago
            Anonymous

            If C++ is as good at protecting against memory leaks as Rust is, what was the point of constructing that contrived example?

            Ah, yes, the old "skill issue". I wonder if there is any "skilled" C programmer out there because I only see RAM eaters written in C.
            #include <stdio.h>
            #include <memory>

            using namespace std;

            class C
            {
            public:
            C() {printf("Constructor for C: this=%pn", this);}
            ~C() {printf("Destructor for C: this=%pn", this);}

            void setSharedPointer(shared_ptr<C> p) {pC = p;}

            private:
            shared_ptr<C> pC;
            };

            int main(int argc, char ** argv)
            {
            shared_ptr<C> pC(new C);
            shared_ptr<C> pD(new C);

            pC->setSharedPointer(pD);
            pD->setSharedPointer(pC);

            return 0;
            }

            As you say, I could encounter a leak in Rust as well.

          • 2 months ago
            Anonymous

            Oh yeah, that is the exact case you can have in Rust. My bad.

      • 2 months ago
        Anonymous

        >C
        found your problem bro, you forgot
        >++

      • 2 months ago
        Anonymous

        ><stdio.h>
        >using namespace std;
        definitely skill issues, only a fricking idiot would write that.

    • 2 months ago
      Anonymous

      You don't have to write it in rust, the compiler can do it for you with a macro

      Language issue. C++ does not have the basic features necessary to automatically serialize and serialize data structures. Rust does.

      • 2 months ago
        Anonymous

        You talking about compile time class/struct reflection? Yeah C++ sucks balls for that, because it can't do it at all.

        • 2 months ago
          Anonymous

          I still don't know why they've taken so long to add it to the language. I doubt the 23 spec will be implemented either.

          • 2 months ago
            Anonymous

            I guess anyone can try to submit a feature to the C++ spec but I have a feeling anything practical will be ignored for being too obvious and not obscure enough.

          • 2 months ago
            Anonymous

            The trick is to get two big compilers to implement the feature you want as extensions, and slightly differently, so users are griping at compiler authors and the committee for fricking around.
            Yes, this is silly, but it's the main way that standards in anything happen.

      • 2 months ago
        Anonymous

        Have you actually read any of that macro code? It's incomprehensible, maybe it is easy to use if you are just a code monkey junior, but writing your own macros is some of the most autistic shit syntax I've ever seen

        Meanwhile there is a no heap required fast as frick json parser in C that's less than 400 lines of code that a poojeet toddler can read and understand

        • 2 months ago
          Anonymous

          >Have you actually read any of that macro code?
          Rust procedural macros are the most comfy macro system I've seen so far.

          >Meanwhile there is a no heap required fast as frick json parser in C that's less than 400 lines of code that a poojeet toddler can read and understand
          Post link

        • 2 months ago
          Anonymous

          >Have you actually read any of that macro code? It's incomprehensible
          https://github.com/serde-rs/serde/tree/master/serde_derive/src
          ???

  2. 2 months ago
    Anonymous

    >there are already millions of json parsers
    >wastes time writing yet another json parser that's most likely worst than everything else

    • 2 months ago
      Anonymous

      >there are already millions of json parsers
      And guess what? I simply CANNOT use them because of "muh compliance policies".

      >JSON parser
      >memory leaks
      Why are you allocating anything in a json parser?
      They can easily be done with zero allocations.

      >They can easily be done with zero allocations.
      How come? I tried something similar to DaveGamble/cJSON but at the end of the day I'm still doomed. I was about to give up on this task.

  3. 2 months ago
    Anonymous

    >JSON parser
    >memory leaks
    Why are you allocating anything in a json parser?
    They can easily be done with zero allocations.

    • 2 months ago
      Anonymous

      the result has to be heap allocated

      • 2 months ago
        Anonymous

        No.

      • 2 months ago
        Anonymous

        no. see libwebsockets json parser.

        https://i.imgur.com/11bLzPQ.png

        >almost 2 weeks trying to write a decent JSON parser in C++
        >buffer overflow everywhere
        >memory leak in stress tests (file dumping)
        >switch to Rust
        >finish the work in 1 week
        >zero memory leaks until now
        I will never try to do file I/O in any language other than Rust again.

        still waiting for stdin/stdout in rust without line buffering without external crates

      • 2 months ago
        Anonymous

        You made an initial implementation, learned a bunch of things, then did a complete rewrite with the lessons you learned and found it went a lot better? Honestly this is classic library development- the first version is always garbage. It almost doesn't matter that the second version was written in rust.

        >there are already millions of json parsers
        And guess what? I simply CANNOT use them because of "muh compliance policies".
        [...]
        >They can easily be done with zero allocations.
        How come? I tried something similar to DaveGamble/cJSON but at the end of the day I'm still doomed. I was about to give up on this task.

        Yeesh the high-level requirements being given to you are insane. I can't imagine working at a place where you're not allowed to pull in even something like rapidjson which is MIT licensed. What license requirements are placed upon you? "If it's not invented here then it's too restrictive"? Your senior leadership is cucking your dev teams.

        • 2 months ago
          Anonymous

          >Yeesh the high-level requirements being given to you are insane. I can't imagine working at a place where you're not allowed to pull in even something like rapidjson which is MIT licensed. What license requirements are placed upon you? "If it's not invented here then it's too restrictive"? Your senior leadership is cucking your dev teams.

          this is going to sound absolutely insane but there are some software jobs that aren't just copy paste stack overflow fragments to make a web browser inside a phone app, there actually exists software written to standards (e.g. where peoples lives rely on the outcome) where the dev team has to be able to explain every aspect.
          something trivial like a parser can sometimes be more simple to just implement than import when 90% of the actual work is going to be bullshit paperwork which is going to double when you decide to use something you have zero provenance of.

          • 2 months ago
            Anonymous

            At that point the procedure is definitely overkill though, for literal JSON parsing there will be off-the-shelf libraries that are better than what you'll whip up yourself and that are less effort to audit and vendor than to reimplement. Not saying that's true in general but in this particular case it seems that somewhat less procedure would lead to somewhat more trustworthy software

            Have you actually read any of that macro code? It's incomprehensible, maybe it is easy to use if you are just a code monkey junior, but writing your own macros is some of the most autistic shit syntax I've ever seen

            Meanwhile there is a no heap required fast as frick json parser in C that's less than 400 lines of code that a poojeet toddler can read and understand

            >no heap required
            How does this work? What kind of interface does it have? You could do streaming decoding instead of deserializing it into a single object but then I'm wondering how you deal with escaped strings. Bounded scratch space?

          • 2 months ago
            Anonymous

            >there actually exists software written to standards (e.g. where peoples lives rely on the outcome) where the dev team has to be able to explain every aspect.
            I've written such software and you're full of shit, many FOSS tool are validated to be used in scanners or missiles, in fact I can guarantee that some missiles are running on C++11 with nlohmann as a json lib.
            even fricking spacex is using electron and nodejs in their space modules.
            if your trashy company can't validate third-party software then you should definitely change job because whatever you're building will be dogshit.
            from your posts in this thread I can already tell that you're just an intern at some defence/aerospace company and that whatever you're doing is nothing more than busywork.
            daddy got you the internship but no one wants to actually involves you in anything serious.
            I'm 100% certain taht your coworkers are using actuall FOSS libs, even for critical parts, you just don't know it yet because they don't talk to you and you don't have access to most git repos.
            I've had nepokids like you in my team, do know that everyone hates you

          • 2 months ago
            Anonymous

            >where peoples lives rely on the outcome

            https://i.imgur.com/11bLzPQ.png

            >almost 2 weeks trying to write a decent JSON parser in C++
            >buffer overflow everywhere
            >memory leak in stress tests (file dumping)
            >switch to Rust
            >finish the work in 1 week
            >zero memory leaks until now
            I will never try to do file I/O in any language other than Rust again.

            >buffer overflow everywhere
            >memory leak in stress tests (file dumping)
            RESIGN IMMEDIATELY before you kill someone
            Your impostor syndrome is fully justified

          • 2 months ago
            Anonymous

            I have no impostor syndrome, homosexual. At least I have an actual job. What about you?

          • 2 months ago
            Anonymous

            You are not even self aware.
            Seriously, resign. You are a danger for whoever is depending on that tragedy you call software.
            Rust will not save you from your clear reasoning deficiency everyone you know is suffering from.

          • 2 months ago
            Anonymous

            this but with you and stopping posting

          • 2 months ago
            Anonymous

            I accept your concession. Now go switch to webdev. Preferably in blogging or something of equal impact on society.

          • 2 months ago
            Anonymous

            Jeets are too arrogant to experience imposter syndrome.

          • 2 months ago
            Anonymous

            >e.g. where peoples lives rely on the outcome
            you're very clearly not skilled enough to be writing such software. take the other anon's advice and resign from the task.

    • 2 months ago
      Anonymous

      >zero allocations
      how???
      you could be loading a json file with 1000 strings in it
      how do you put 1000 strings into memory without allocating?

      • 2 months ago
        Anonymous

        Anon is talking out of his ass, pay no mind.

      • 2 months ago
        Anonymous

        The way I could think of would be to retain the original buffer you parsed from and use a pointer to the beginning of the string literal in the buffer (+ length and stuff).

        • 2 months ago
          Anonymous

          Won't work with escaped characters

      • 2 months ago
        Anonymous

        The way I could think of would be to retain the original buffer you parsed from and use a pointer to the beginning of the string literal in the buffer (+ length and stuff).

        The actual way to do it is for the parser to not produce its own AST, and instead invoke a bunch of callbacks
        Actually using this style of parser is enormously complicated, but at least the parser itself avoids having to allocate, which is the entire original point

  4. 2 months ago
    Anonymous

    >buffer overflow everywhere
    >memory leak in stress tests (file dumping)
    It doesn't take a genius to avoid these things in C/C++ you just need to be familiar with the language(s) and how memory/pointers work. Hate to break it to you but this is indeed a "skill issue"

  5. 2 months ago
    Anonymous

    >1 month to write a shitty parser for a static data format
    grim. what kind of experience of you have?

    • 2 months ago
      Anonymous

      *do you

  6. 2 months ago
    Anonymous

    >a whole week to write a JSON parser
    Holy king of morons

  7. 2 months ago
    Anonymous

    ITT:

  8. 2 months ago
    Anonymous

    >2 weeks to write a json parser
    >fails
    >blames the language
    absolute moron. you will never make it in tech and everyone in this thread is laughing at you. Just find another career at this point. not everyone is cut out for programming.

    • 2 months ago
      Anonymous

      >blames the language
      Of course. Almost 2 years working with C and still failing to keep up with all this fricking shit. I literally never programmed a single line of Rust and I still managed to deliver my task faster and without bugs or memory leaks. And you still think that language doesn't make a difference? Just being very intellectually dishonest.
      What's the point in fighting pointers? Not even smart pointers can be as efficient as Rust's borrow checker. It's simply stupid to continue programming in C when we have better, more efficient, faster and more memory-safe options.
      >"no, but you need to waste your time fixing calls in your program instead of handing in the damn ticket ready otherwise you're not a real programmer"
      No, thanks.
      >you will never make it in tech
      I already made it.
      >everyone in this thread is laughing at you
      And? I literally don't give a frick lol. I created this thread to discuss about file I/O in Rust. If you don't like Rust then why did you come here?
      Also, t.

      • 2 months ago
        Anonymous

        >I already made it.
        Are you a troon diversity hire? I can't imagine how else you could have made it being this moronic

        • 2 months ago
          Anonymous

          otoko da!

        • 2 months ago
          Anonymous

          nobody is hiring failures from the internet like op that don't actually code.

      • 2 months ago
        Anonymous

        > daily rust troony nocoder seething thread

        > rust troony nocoder has no idea how any language works
        stick to what you're best at: raping children.

      • 2 months ago
        Anonymous

        >Of course. Almost 2 years working with C and still failing to keep up with all this fricking shit. I literally never programmed a single line of Rust and I still managed to deliver my task faster and without bugs or memory leaks. And you still think that language doesn't make a difference? Just being very intellectually dishonest.
        not trying to be mean or trolling but it's DEFINITELY a skill issue.
        a json parser is VERY simple to write in basically any relevant language except maybe for assembly.
        >What's the point in fighting pointers?
        go back to school
        if you pass programming 101 and still have issues with raw pointers then you should change carrier asap.
        >It's simply stupid to continue programming in C when we have better, more efficient, faster and more memory-safe options.
        lmao moron
        >I already made it.
        no you didn't.
        >I created this thread to discuss about file I/O in Rust
        read your op post against, you're b***hing about C++ being too hard for a sub 90iq mongoloid like yourself.
        what makes you think you can discuss advanced topics?

  9. 2 months ago
    Anonymous

    > be moron
    > still attempt to reinvent the wheel
    rope

  10. 2 months ago
    Anonymous

    overflow everywhere
    leak in stress tests (file dumping)
    Aren't these two solved by Modern C++™ using RAII and .at()? Unlike use-after-free and data races I thought these were basically covered
    Why write your own parser at all? I don't know about C++ but for Rust serde(_json) is really very nice
    t. knows Rust but doesn't use C++

  11. 2 months ago
    Anonymous

    >until now

  12. 2 months ago
    Anonymous

    should have used Go.

  13. 2 months ago
    Anonymous

    I don't like Rust, not because of the language itself. But because of tribalgays like you.

  14. 2 months ago
    Anonymous

    2 weeks trying to write a decent JSON parser in C++
    overflow everywhere
    Skill issue. I did it in 2 days in C, and the only issue was one memory leak I found and patched immediately.

  15. 2 months ago
    Anonymous

    it took me 4 days in asm, back to json too obv. you have a major skill issue

  16. 2 months ago
    Anonymous

    >knifo.jpg
    he aims for your balls
    it's time.

    >I suck at coding, LOL
    try other profession maybe

  17. 2 months ago
    Anonymous

    Yes, welcome to actually using the language. All the shit talkers here never write anything so they don't know what it's like to actually be done with a project. Lack of having to debug things and maintenance is a breeze

  18. 2 months ago
    Anonymous

    >amazing rust
    some sort of bernaysian globohomosexual push.

  19. 2 months ago
    Anonymous

    is it chopping penises off with that knife?

  20. 2 months ago
    Anonymous

    >switch to Python
    > import json
    >finish the work in 1 second

    • 2 months ago
      Anonymous

      use serde_json beats import json (but maybe not import pydantic)

  21. 2 months ago
    Anonymous

    >starts talking about a JSON parser
    >I will never try to do file I/O in any language other than Rust again.
    I'm confused, what does one thing have to do with the other?
    Your API isn't some hood shit that takes a filename and spits out an std::map, right?

  22. 2 months ago
    Anonymous

    >git submodule add https://github.com/nlohmann/json.git
    Problem fricking solved you god damn tinkertroony

  23. 2 months ago
    Anonymous

    import json

    I'm leaving this thread because I figured out I'm a monkey

  24. 2 months ago
    Anonymous

    stop using malloc and use arenas
    stop using cstring or std::string and roll your own string type

  25. 2 months ago
    Anonymous

    2 weeks trying to write a decent JSON parser in C++
    overflow everywhere
    leak in stress tests (file dumping)
    to Rust
    the work in 1 week
    >>zero memory leaks until now
    that only means you suck at c doe
    youre the exact use case rust has been created for, enjoy

    • 2 months ago
      Anonymous

      Holes arent parte of the chesse,its space,with that lógic every bit of Air would be a part of chesse

      • 2 months ago
        Anonymous

        define "air"
        bc matter is 100% space with energy charges floating in it

      • 2 months ago
        Anonymous

        ur so goddam weak.
        go back to IQfy already, i want IQfy back

  26. 2 months ago
    Anonymous

    >1 week to build a program that can parse a json file.
    Reassess your life.

    • 2 months ago
      Anonymous

      seems reasonable for a json parser from scratch

  27. 2 months ago
    Anonymous

    bait is good enough for me to respond, if it took you 2 weeks to write a json parser in c++ then it's time to use the rope. writing a json parser should take an hour max, but i do agree that file i/o stuff is kind of shitty w/ cpp's stdlib hence why there are millions of alternative for it.

  28. 2 months ago
    Anonymous

    Why would you write your own JSON parser?

    • 2 months ago
      Anonymous

      Wagecuck problems. We hardly use 3rd party libs here, almost everything must be built from scratch because of compliance policies.

      • 2 months ago
        Anonymous

        That may be a good thing in the end. I've had to deal with old software that used libraries for simple things, and it became a serious problem when the company wanted to update the software for Windows 10 since the old libraries were no longer available and they didn't work on Windows 10. Very expensive to fix, it would probably have been much cheaper to simply write those parts in-house from the start.

      • 2 months ago
        Anonymous

        your company is based, shut up soiboi

        • 2 months ago
          Anonymous

          Why though?

    • 2 months ago
      Anonymous

      >n-no writing that is too hard just import the solution
      What happened to rust users needing crates for everything

  29. 2 months ago
    Anonymous

    >Memory leak
    Rust considers memory leaks "safe".
    have a nice day shill.

    • 2 months ago
      Anonymous

      Memory leaks are logic errors, not safety errors.

    • 2 months ago
      Anonymous

      It's still really hard to cause them, realistically you'll only see them if you use too much reference counting. Same for modern C++ AFAIK but good luck getting everyone to avoid the unsafe old ways

  30. 2 months ago
    Anonymous

    a json parser in haskell is like 100 LoC.

  31. 2 months ago
    Anonymous

    >https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html
    C-sister how do we cope now?

    • 2 months ago
      Anonymous

      Did you ever notice how rust users are always evangelizing their language ?

    • 2 months ago
      Anonymous

      >ask a tribesmen to tell you how great his tribe is, the answer won't be biased at all.
      wasted trips

  32. 2 months ago
    Anonymous

    Json is really one of those formats that trips up every language. I have to always use either a third party package or Microsoft's parser when I use C#. Just accept that json is stupid and use a third party package. No shame in it.

    • 2 months ago
      Anonymous

      Serde just works. Imo the only language that has better Json interoperability is JS itself.

  33. 2 months ago
    sage

    There are literally dozens of c++ Jason parsers. You failed. But that's because you are moronic

  34. 2 months ago
    Anonymous

    Shell out $20 for ChatGPT Plus and ask GPT-4 to write one for you or diagnose issues in yours.

  35. 2 months ago
    Anonymous

    I've never written a parser, what's the easiest way to do it in Rust? I wanted to write a parser for this format: https://github.com/TylerGlaiel/GON using https://crates.io/crates/winnow but got filtered.

    • 2 months ago
      Anonymous

      https://github.com/zesterer/chumsky

  36. 2 months ago
    Anonymous

    skill issue

Your email address will not be published. Required fields are marked *