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 🏳️⚧️
Have you considered TOML instead? For files that need to be edited and read by humans it tends to be better than JSON due to the easier ability to split it over lines and add comments in between.
I have considered it in the past but JSON feels like the standard. But TOML could be an option. I might try to see which I like better
I’ll never understand how the rust community loves TOML (like me) but also loves Rust syntax (totally not like me)
I feel like they are opposite: rust syntax is full of symbols, toml is super minimal and square parentheses are just less “noisy” than curly ones…
Personally, I just think the amount (and use of) symbols needs to match the semantic complexity.
With spoken language, a few dots and commas generally suffice.
With programming languages, I do want to see scopes and whatnot, so I like having braces in place, for example. Something like Python largely turns to word soup in my brain.
With a configuration language, the complexity is almost even simpler than a spoken language, so I really don't need much in terms of symbols.
JSON has a mismatch for use in configuration. The keys in a object don't need to be quoted. The commas after each¹ line in an object really aren't necessary when pretty-printed. And well, JSON not having comments also kind of disqualifies it.
Having said that, not every symbol has to be my brain's favorite thing. I don't particularly care for having each line terminated with a semi-colon. But I do believe that Rust is able to generated such excellent error messages, because the semicolons make it very clear where the statement ends, so I don't mind putting it down.
¹) Don't add a comma after the last line, though, or you'll go to JSON jail.
Really? I feel the opposite. I'd much rather have indentation enforced by the language than merely convention.
That said, I prefer braces, mostly because it makes things like inline functions more reasonable (the lambda syntax sucks IMO), and my editor does a great job matching on braces.
The stupidest thing IMO is that JSON came from JavaScript, but it loses the flexibility of JavaScript. The quotes thing is acceptable IMO since it allows for flexibility in keys (e.g. you can have a URL as a key), but these aren't:
I love that semicolons mean something in Rust. Since pretty much everything is an expression, you only need a semicolon to turn it into a statement. That's really nice!
I don't think it has anything to do with error messages though, plenty of languages do that well without it.
@ex_06 @taladar Personnally it's not that I like the syntax, it's that I love the semantic.
Are you talking about rust or toml? Because if rust, just out of curiosity, would you still like it with keywords instead of symbols?
Rust has very few symbols, especially compared to pre-1.0 when they had ~ (box?) and @ (GC?).
Symbols in modern Rust are pretty reasonable IMO, but maybe that's just stockholm syndrome.
@sugar_in_your_tea @ex_06
-
&&
and||
instead ofand
andor
-
::
instead of the simpler.
Just those two changes would help significatly reduce the awkwarness. Even turbofish would be slightly less noizy.
Idk,
&&
and||
are pretty universally common, so I highly doubt they trip anyone up.::
is a little odd, but at least it's limited to imports. Having it be.
makes it a little ambiguous when you seex.y
as to whetherx
is a module or an instance. But it's absolutely fine in other languages, so that's not a hill I'm willing to die on.The turbofish is disgusting though. I prefer D's template syntax:
Type!A
orType!(A, B)
, though this conflicts with macros. If we have macros all use the same symbol (e.g.println#(...)
instead ofprintln!(...)
), then we could use the!
instead of the turbofish. But that ship has sailed and it's not clear if my bike shed is a better color.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:
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.
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.
Why? I don't see any reason for that.
This is just "you're holding it wrong".
Really. Here's the first Gitlab CI example I could find:
Let's see the TOML:
Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.
IMO JSON5 is the best:
This is much clearer than TOML and less ambiguous than YAML. It could do without the outer
{}
, but overall it's still better.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:
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.
JSON5 is seriously what I feel JSON should've been. Comments, trailing commas, hex numbers, etc.
JSON doesn't have comments according to the spec. So he is right. Same with trailing commas.
Right but JSONC does support them. We just want support for JSONC as well as JSON.