this post was submitted on 05 Mar 2025

9 points (100.0% liked)

Rust

6854 readers

28 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago

MODERATORS

[email protected]

Using Rust since beginning of 2023 (programming.dev)

submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

27 comments fedilink hide all child comments

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 🏳️‍⚧️

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 0 points 1 month ago (3 children)

TOML is a terrible format. It is anything but obvious, especially when you have more than one level of nesting.

It is pretty annoying that there isn't an obvious format that Serde supports to use though:

YAML is an awful format (worse than TOML in many ways). serde-yaml is abandoned anyway.
serde_json is great but dtonlay refuses to support comments/trailing commas
serde_json5 is an option but JSON5 doesn't have good IDE support.

I would probably go with either RON or one of the forks of serde_json that adds support for comments. I think there's serde_jsonc and serde_jsonc2 maybe.

[–] [email protected] 3 points 1 month ago (1 children)

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.

[–] [email protected] 1 points 1 month ago (1 children)

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.

[–] [email protected] 1 points 1 month ago

Personally, I've found excessive nesting to be problematic, because each level of nesting is an invariant, which might not fit your application anymore as it evolves.

For example, let's say you've got "application.logging.enabled" as one flag.
Then you decide to introduce more extensive telemetry in the next release. So, if you go with 'proper' nesting, you'd have to call the flags for that:

application.telemetry.metrics.enabled
application.telemetry.tracing.enabled

Theoretically, you'd have to move the logging config also under that nesting level, but that would break existing configs.

Obviously, this example is relatively easy to avoid by not introducing the nesting in that case.
But you can find other examples where you might have called that level one way and then later ended up introducing a bunch of configs under a different name, where it could've also been under. That will confuse end users who try to configure your application and also might make it just more difficult to remember or guess config names in general, when you also have to guess the intermediate levels.

[–] [email protected] 1 points 1 month ago

JSON5 is seriously what I feel JSON should've been. Comments, trailing commas, hex numbers, etc.

[–] [email protected] 1 points 1 month ago (1 children)

JSON doesn't have comments according to the spec. So he is right. Same with trailing commas.

[–] [email protected] 1 points 1 month ago

Right but JSONC does support them. We just want support for JSONC as well as JSON.