Hello,

This is my first post to this Rust community and I am happy to introduce myself and discuss what I love about this language, but first a little about myself.

I’m Alice, Fluffy to most, and she/her are my pronouns. I’m from the UK. I got a little boy who love like crazy. I’m Autistic, suffer from cPTSD and I also 🩷 Rust!!

Rust I feel appeals to Autistic people because of it’s focus on accuracy and correctness. It’s a common feeling people have about the language. But as the type of person I am I love it.

I began learning it in 2023, before this I was using C++. Rust showed me the importance of error’s as values and helped improve the quality of my code.

Currently I’m writing a game-engine as a hobby. The game-engine is a work in progress (WIP) and I have only just begun it’s development. Since the game-engine will natively support various platforms. To ensure consistency I’m writing all the platform specific code manually and building my own custom standard library for my engine, loosely based on the actual Rust standard library.

Right now I have the code in place to create/remove directories and to create, delete, write, read and set file pointer location. Convert UTF8 to UTF16 and output to the console in Unicode (Windows C API uses UTF16) and heap functions to get the process heap and create and delete memory dynamically.

Next will be the ‘config.json’ for which Serde will be used. Then the logger, and so on.

So it is a WIP but it’s fun and given my conditions allows me to do what I love, writing Rust code.

Thanks for reading!!

Alice 🏳️‍⚧️

  • sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    9 hours ago

    TOML… nesting

    If you’re doing a lot of nesting in your config, you should rethink your config. Config should be pretty flat.

    If you’re putting data in TOML, you’re doing it wrong. If your config needs to include data, IMO it should just reference the data in a separate file that uses a proper data format (e.g. JSON).

    TOML rocks precisely because it nudges you into making simpler configs. Nesting is inherently hard to read (see endless debates over indentation standards), and TOML sidesteps the whole problem elegantly, forcing you to think about whether you actually need it. In most cases you don’t, and when you do, it’s possible and not unreasonable.

    • FizzyOrange@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      9 hours ago

      Config should be pretty flat.

      Why? I don’t see any reason for that.

      TOML rocks precisely because it nudges you into making simpler configs.

      This is just “you’re holding it wrong”.

      In most cases you don’t, and when you do, it’s possible and not unreasonable.

      Really. Here’s the first Gitlab CI example I could find:

      lintDebug:
        interruptible: true
        stage: build
        script:
          - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
        artifacts:
          paths:
            - app/lint/reports/lint-results-debug.html
          expose_as: "lint-report"
          when: always
      

      Let’s see the TOML:

      [lintDebug]
      interruptible = true
      stage = "build"
      script = [
        "./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint"
      ]
      
        [lintDebug.artifacts]
        paths = [ "app/lint/reports/lint-results-debug.html" ]
        expose_as = "lint-report"
        when = "always"
      
      

      Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.

      IMO JSON5 is the best:

      {
        lintDebug: {
          interruptible: true,
          stage: 'build',
          script: [
            './gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint',
          ],
          artifacts: {
            paths: [
              'app/lint/reports/lint-results-debug.html',
            ],
            expose_as: 'lint-report',
            when: 'always',
          },
        },
      }
      

      This is much clearer than TOML and less ambiguous than YAML. It could do without the outer {}, but overall it’s still better.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        8 hours ago

        Gross

        The only gross thing I see is your indentation. I find the TOML to be more readable honestly.

        In a config format, you want to group top level fields together, and it enforces that. Your example could be like this instead:

        lintDebug:
          stage: build
          script:
            - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
          artifacts:
            paths:
              - app/lint/reports/lint-results-debug.html
            expose_as: "lint-report"
            when: always
          interruptible: true
        

        It’s easy to tack stuff on like that, and it’s also easy to miss when quickly scanning, especially if you’re using 2-space indenting.

        The TOML would be the same in either case, because it forces related fields to be grouped separately from child groups.

        The main thing I don’t like about TOML is yellow table groups:

        [[thing]] 
        
        [[thing]] 
        

        I rarely see it in the wild though.

        IMO JSON5 is the best:

        It’s trying to do two things at once, and ends up doing neither very well. The extra curly braces are there because it’s trying to be a data format, and it’s bad as a data format because it’s not universal. We’ve standardized on JSON as a community for data, and that’s unlikely to change, so we shouldn’t try to “fix” it just for configs. IMO, either use JSON or a config-specific format.

        I agree that YAML is plain awful. It shouldn’t exist.

        XML is awful for anything outside of markup, and even then I think we can do better. I’m partial to Lua tables:

            {x=10, y=45, "one", "two", "three"}
        

        A typical HTML drop down menu {pulled from MDN):

        <select name="pets" id="pet-select">
          <option value="">--Please choose an option--</option>
          <option value="hamster">Hamster</option>
          <option value="parrot">Parrot</option>
        </select>
        

        Could be like this in a Lua table:

        {
          node="select", 
          name="pets", 
          id="pet-select", 
          {value="", "--Please choose an option--"}, 
          {value="hamster", "Hamster"}, 
          {value="parrot", "Pattot"}, 
        } 
        

        Or maybe something a little different with the node type outside:

        select{
          name="pets", 
          id="pet-select", 
          option{value="", "--Please choose an option--"}, 
          option{value="hamster", "Hamster"}, 
          option{value="parrot", "Parrot"}, 
        } 
        

        I think QT Quick uses something like that, but it’s been years since I played with it.