• 0 Posts
  • 52 Comments
Joined 1 year ago
Cake day: June 16th, 2023
  • Solemarc@lemmy.worldtoProgramming@programming.dev•How to learn Rust?
    18·
    1 month ago

    IMO the best way to start in a new language is to rewrite some of your previous projects in that language.

    I generally start out by rewriting a couple simple 1-3 function console apps, basic leet code stuff like; palindrome, fizzbuzz, reverse an array in place, etc, and some simple unit tests for them. Then I go ahead and rewrite some of my previous projects or uni assignments in that language.

    At that point I generally have a good understanding of basics and have an idea of how to approach a new project. When I got to this point in rust I then started on threading, async, why it’s easy to return a String and an ordeal to return &str, etc.

  • Solemarc@lemmy.worldtoProgramming@programming.dev•Why is Go syntax so messy
    4·
    4 months ago

    To do quick and simple explanations:

    var test int = 0

    assign an int, var = let in rust land

    :=

    This is basically an inferred assignment e.g.

    a := "hello world"

    The compiler will know this is a string without me explicitly saying

    func (u User) hi() {}

    To return to rust land this is a function that implements User. In OOP land we would say that this function belongs to the user class. In Go, just like in rust we don’t say if a function returns void so this function is for User objects and doesn’t return anything:

    func (u User) hi(s string) string {}

    If it took in a string and returned a string it would look like this.

    map[string] int {}

    I will give you that this syntax is a bit odd but this is just a hashmap/dictionary where the key is a string and the value is an int

  • Solemarc@lemmy.worldtoProgramming@programming.dev•C++ creator rebuts White House warning
    2·
    7 months ago

    I remember watching a video of someone writing C code and making the same thing in unsafe rust. While the C code worked just fine the rust code had UB in it and was compiled to a different set of instructions.

    Unsafe rust expects you to uphold the same guarantees that normal rust does and so the compiler will make all the same optimisations it would if the code wasn’t unsafe and this caused UB in the example rust code when optimised for performance. It worked just fine on the debug build, but that’s UB for you.

  • Solemarc@lemmy.worldtoRust@programming.dev•How can I avoid "value assigned to last is never read" warning from this macro?
    2·
    7 months ago

    I’m not sure if the rules are different with macros, I’ve never written one but this lint is generally caused because you set a var to a value and then overwrite that value before you use it. e.g.

    let mut a = 1; a = 2; println!(“{}”, a);

    This will throw the same warning because 1 is never used, this could’ve just been:

    let a = 2; println!(“{}”, a);

    So first I’d double check that I NEED last at all. Maybe try:

    cargo clippy

    See if it can tell you how to fix it.

    If that doesn’t work, it’s sometimes necessary to skip certain lints. E.g. if you make a library, most of the code will be flagged as dead code because it isn’t used and you can use an #[allow(dead_code)] to stop the linter warning. You might be able to use #[allow(this_linting_rule)].

    Hope something here helps.