7mo ago

Using Rust since beginning of 2023

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

28 comments

Next will be the ‘config.json’ for which Serde will be used.
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’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.
- 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.
  
  JSON doesn't have comments according to the spec. So he is right. Same with trailing commas.
  
  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.
  
  JSON5 is seriously what I feel JSON should've been. Comments, trailing commas, hex numbers, etc.
  
  The thing is, for many use-cases, you care about the configuration language being widely understood/supported. And TOML hit kind of a local maximum, where it's capable enough for most configuration needs, while being basically INI++. Presumably, you could even fork an INI parser for building a TOML parser, which makes it easy to adopt in many ecosystems.
- 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
Good for you!
I will agree that rust is a very satisfying language to write in. Lol.
For me it’s either go full rust aiming for correctness and robustness, or go full python aiming for duck typing and flexibility.
This all being said Gleam and Scala are also quite beautiful to me at least.
- At my company, we picked an awful middle-ground: write Python like it's Java, but don't use correct type hints.
  In our project:
  everything is a static class - from a.b.c import C; C.thing() instead of from a.b.c import thing; thing() or import a.b.c; c.thing()
  use declarative dependency injection frameworks instead of duck typing
  force rigid class structures, but don't do typing properly, and don't necessarily keep the calling signature of the base class methods (i.e. break SOLID all over the place)
  use decorators to hide magic (i.e. implicit is better than implicit and other Zen of Python violations)
  We get the worst of OOP and functional styles with none of the benefits by abusing Python's flexibility.
  But hey, I guess it works...
  
  That’s terrible. I noticed that there is a certain type of programmer. Normally they went to Uni in the late 90s or early 2000s and their entire education was focused around Java.
  They went out to get a job writing “Enterprise” Java for 10 years.
  This programmer then tries to learn another language, but because all they know is Java everything ends up looking like and structured as Java.
  I’ve seen this developer over and over again. It’s possible for them to overcome Java Brain but it’s rare.
  I bet one of these types of programmers is or was the technical lead of that project.
  I noticed something similar when I worked on a Scala project in the past. Yes I know we’re on the JVM, but we don’t need a data deconstructor factory when flatmap is right there.
  
  I’m sorry
- I've been meaning to try Gleam, I hear really good things about it. Maybe I can make a Gleam-like scripting language for my game-engine.
  
  That would be interesting.
  Have you considered using LUA or perhaps scheme?
  I know helix is likely to use scheme as its future scripting language. It’s quite robust and there is an excellent library to embed it.
  I only mention LUA because it’s like the goto embedded scripting language in my book.
  https://github.com/mattwparas/steel
glhf
- I have came accress WGPU. But my goal is to write as close to the OS and other API's as possible. So i will probably go with Vulkan natively but thanks for the idea!!
Awesome! Good to have you!

28 comments