Skip Navigation

soulsource

@ soulsource @discuss.tchncs.de

Posts
1
Comments
19
Joined
3 yr. ago

  • Elegoo Neptune Max 4: What should I attempt to fix it?

    Jump

  • I finally printed something again yesterday, and, as far as I can tell, the z-positioning was perfectly stable thanks to your suggestion.

    Thanks a lot!

  • What additional concepts should I learn before starting to learn rust?

    Jump

  • I think you have done way more work than would be needed to learn Rust. I mean, it certainly is useful knowledge if you want to do any of those things in Rust, but it's definitely not needed to learn Rust.

    The Book (the Rust language guide) assumes that you know some other language first, but you don't need to be an expert in anything in order to start learning Rust. If you understand the basic concepts of branching, loops, recursion and function calls, you are good to go.

    There are of course other concepts you will encounter in Rust (like Algebraic Data Types, Polymorphism, Ownership,...), but those are all explained in the Rust Book, so there really is no need to learn them in advance.

  • Elegoo Neptune Max 4: What should I attempt to fix it?

    Jump

  • Thanks, gonna do that first before I start my next print. This sounds like a really plausible cause!

  • 3DPrinting @lemmy.world
    soulsource @discuss.tchncs.de

    Elegoo Neptune Max 4: What should I attempt to fix it?

  • Where to start if I wanted to try making my own drawing program?

    Jump

  • For 2) I'd also suggest to check out SDL. There are excellent SDL bindings for Rust, and it's way less involved than dragging in a fully-featured game engine.

  • Memory Safety Philosophies: Rust vs C++

    Jump

  • Oh, sorry. I stand corrected then.

  • Memory Safety Philosophies: Rust vs C++

    Jump

  • I'm willing to bet that it's AI. It soft-contradicts itself quite often, emphasising that C++ is "Performance First", but then also claiming stuff like "Rust achieves memory safety with zero runtime overhead".

    Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.

    Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust's type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races... Here, for instance, have a data race in safe Rust...

  • Where do you guys buy your 3D print and such at?

    Jump

  • I'm new to both, FreeCAD and Blender, but what I've been doing up to now:

    • Draw the to-measure parts in FreeCAD
    • Export them as STL
    • Import STL in Blender
    • Add decorative elements there in Sculpt Mode.
    • Profit

  • Flattening Rust's Learning Curve | corrode Rust Consulting

    Jump

  • Yep. One reason why those situations become less frequent over time is that one learns to avoid such designs. Thought process: "Sharing data across threads is annoying. So I'd rather avoid it. Maybe message passing can solve the same problem as well?"

  • Rust is now a government conspiracy

    Jump

  • This is so fucking stupid, I can't even.

    For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

    Since it's in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):

    • Software development is stuck in a vicious cycle regarding project budgets.
      • Some competitors don't know better and just budget the "happy path", that assumes that everything during development goes right.
        • The author uses a term for this which I like a lot: "Hybris of the programmer"
      • Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
      • Therefore almost all software projects end up with a way too low budget
        • So we get buggy software
    • Rust might be a way out of this misery, because
      • it is understood that it takes longer to develop something with Rust
      • but on the flip-side the safety-guarantees rule out a lot of bugs
      • so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
      • and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.

  • rust_analyzer takes forever to load; cargo check is instant.

    Jump

  • No solution, but I have a similar issue with the higher crate.

    There the /prelude/src/lib.rs file lets rust-analyzer lose its mind and allocate gigabytes upon gigabytes of memory, even though the file compiles just fine and nearly instantaneous...

    I think this has something to do with recursive macros. Doesn't iced also have such? I have faint memories of a column! macro?

  • Do people use Cargo?

    Jump
    • cargo install is for installing rust programs for your user, not for adding dependencies to your Rust project. Many cargo subcommands can be installed this way, for instance cargo bloat.
    • The file you are talking about is called Cargo.toml, because it is the file you need to write in order to configure cargo for your Rust project. TOML is the name of the file format. For details, please see the introductory chapter to Cargo in the Rust book.
    • Cargo recently got a new subcommand called cargo add, which allows to add dependencies directly on the command line. However, all it does is to add/edit/remove the respective lines in Cargo.toml. (Personal opinion: I have found it way easier to just edit the file directly than to learn yet another command...)

    That said: You still need to edit the Cargo.toml file, even if you solely use cargo add to manage your dependencies. That's because that file contains a lot more information about your project than just the dependencies. For instance the current version, the feature-flags, your name, a link to the public repo,...

  • What are you working on this week? (Sep. 29, 2024)

    Jump

  • I haven't done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.

    However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.

    For now I only did a relatively small change, but it's one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.

    This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.

    Long and boring explanation with way too much detail:

    Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.

    For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.

    So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad's Pure-nodes. That way it is readily available via the State Monad Transformer's get()/put() functions, and the "use within two lines" limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.

  • One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

    Jump

  • I would be very surprised if they wouldn't fix all 50 filesystems.

    In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don't compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

  • One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

    Jump

  • That's a very good point. I hadn't considered potential lack of domain knowledge at all. In that case Rust might even help, because it's easier to write interfaces that can't be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.

  • One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

    Jump

  • Behind all the negative tone there is a valid concern though.

    If you don't know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.

    This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?

    I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.

  • Rust is growing

    Jump

  • The "it's hard" claim is also a bit of a misconception imho. Rust for sure has a high entry barrier, but it isn't particularly difficult, at least in comparison with C++, which I'd consider its biggest competitor. While it's easy to start working with C++, it's a horribly complex language with hard to use features, lots of weird edge cases, and tons of missing pieces, that one has little chance of ever learning properly, because it's just so much to keep in mind at all times... Oh, and don't get me started on how error prone memory management is without a Borrow Checker...

    Sorry for the rant, back on topic: I agree that it's not the right tool for many domains. That's what I was thinking about when I wrote that people might misunderstand what niche it tries to fill. If one needs a low level language that is very explicit about performance costs, and offers memory safety and (some) abstraction at zero runtime cost, then Rust is definitely worth a look. If performance is not a key concern, then higher level languages might be a better choice, because one can build things faster, and focus more on the problem at hand instead of low-level details.

    We are at work in a similar situation, as we would like to add another programming language besides C++ to our projects, and Rust is currently the top candidate. However, one of our goals is to use abstractions that are common in functional programming, and that's where I think Rust is a suboptimal choice. I've been playing around with such abstractions in Rust recently (I've written blog posts about Free Monads and Reader/State Monads in Rust), and my conclusion is that Rust isn't the right tool if one wants to use those. (Or, rather, those abstractions are not suited for the domain of systems programming.)

    We are using Unreal Engine, so C++ is the obvious choice for performance critical code. Rust would then fill the same niche, and while it obviously would be much more convenient to use than C++, we would still need to train people, and set up FFI bindings. If we, however, are already willing to do that, we could also go all the way and introduce a higher level pure functional language. That way we would actually get a tool that covers a different domain and is suitable for abstractions coming from functional programming. We could then choose, based on a system's requirements, if we need to focus on performance (-> C++), or if we can trade a bit of performance for much easier to write/maintain code (-> whatever high level functional language we pick).

    That's why, as it stands now, I also won't push towards the adoption of Rust at work.

  • Rust is growing

    Jump

  • Controversial opinion: There are only 2 kinds of people that think Rust will not become a widely used language:

    • Those who don't bother to learn it, and only argue about it without any hands-on experience, and
    • those who don't understand which niche Rust tries to fill.

    For me it was funny, btw. I started out as basically a Rust fanboy, back when the "First Edition of The Rust Book" was still just called "The Book"...

    Then I learned a bit of Haskell, and was immediately disappointed that Rust doesn't offer the same convenience when it comes to working with Traits (cough Higher Kinded Types cough). So, while I never considered myself part of the first group, I definitely was part of the second for some time.

    However, the more I've been trying to abuse Rust for stuff that would be better done in a higher level language (like Haskell), the better I understood why Rust doesn't offer those abstractions: They often can't be zero-cost, and using them in a language that tries to be very explicit about performance costs becomes very verbose... In other words, I learned the hard way what "systems programming" means in the case of Rust, and which languages it competes with, and which it doesn't.

  • Why Rust is the most admired language among developers?

    Jump

  • I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.

    For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I've also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.

    Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.

    So, some of the reasons why I personally love Rust:

    • Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
    • Rust's syntax is elegant. It's not as elegant as Haskell, but it's a lot more elegant than any C-based language.
    • Rust is (mostly) type safe. There are (nearly) no implicit conversions.
    • Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
      • This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
    • The memory management model of Rust ("borrow checker") makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn't match them, development will become an uphill battle against the borrow checker.
    • Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
    • Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it's needed, using virtual function tables.
    • Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
      • This, together with the borrow checker, ensures that there are (nearly) no "weird bugs". Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference ("oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it's undefined behaviour"), that almost never happens in Rust.
    • Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
    • Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)

    The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.

    This brings us to the downsides. Rust isn't perfect. Far from it, actually. Here are some of the things that aren't great about Rust.

    • No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the async keyword in the language itself.
    • Unsafe Rust is hard. In my opinion even harder than C++, because of Rust's aliasing rules. Unlike C++, Rust doesn't allow mutable memory aliasing. That's because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
      • Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it's hard, and I'd generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
    • Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.

    However, the upsides clearly outweigh the downsides imho.

    tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.