Skip Navigation

Posts
407
Comments
271
Joined
3 yr. ago

  • And the Copy question.It is not that s reference has to implement Copy. A reference IS Copy, by the simple fact that it is a primitive value on the stack.

  • A reference &T holds a pointer, ie. the memory adress to the actual content of T

    So, in the example x doesn't hold the value 42, it holds the memory adress to the memory there the integer value 42 is stored. So, to access the value, you need to dereference the reference. Which is why you need to use *x when you assign the value.

  • Fixed it.... I come from a language culture were we like our negations :) Also, not native english speaker, so combine the two and you are in for a ride!

  • But isn't it kind of obvious that if you are able to do 180k times improvement, then the baseline is probably not very impressive to begin with. Still, that doesn't take away that the optimizations were impressive, and that it was interesting to read about it.

  • Sync for Lemmy @lemmy.world

    Lemmy 0.19 Breaking Changes - Lemmy

    lemmy.ml /post/5711722
  • Rust @programming.dev

    Announcing the New Rust Project Directors

    blog.rust-lang.org /2023/10/19/announcing-the-new-rust-project-directors.html
  • And if I understand it correctly, it now would be enough for them to ping in this community in a post to get it do show up here... so that might be something for them to think about.

  • I actually agree, I much prefer articles. However, I found this interesting since it looked at turbopack, parcel, rspack and others and talked about how it comes that the JavaScript ecosystem seems to start to use a lot of rust for their tooling. It was quite long though...

  • You don't have to use it....

  • Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.

    For non-gc languages you always have ownership, in most languages you just have to keep track of it manually. And whenever the rust compiler gives an error, you would most likely have had a future issue in another language. For gc languages, this may still exist if you share data between threads, causing possilbe race conditions and data corruption. So, the ownership/borrow model is just a formalization of implicit rules that exists in most languages.

  • I see where you come from. I first turned to Go, but at the end of the day it was a nice language but it didn't tick my boxes. One of my main issues for backend servers, is for them to be robust. They should never fail in runtime. That means error handling is quite important, and as few runtime errors as possible. Go, fails this hard. The strictness of Rust, may be a pain while learning, and some syntax may be less than optimal, but the result will almost never fail in production. I have in fact never had a backend I wrote fail in production. The error handling also makes it easy to find any errors due to things out of my control. I switched a project from Java to Rust, and the log shrunk by a factor 10.

    Note, I still use Go sometimes, but it is not my go to language. And on a second note, that you point to .unwrap() indicates that you never really used rust to write a backend, since use of .unwrap() will panik if you use that. You normally use .unwrap_or(...) or some other better construct. Also, complaining about unwrap() would indicate that you prefer a null pointer issue? Because, dropping null/nil is one of the great design choices, having null/nil is just a recepie for getting a runtime crash.

  • So, Linux is written by system programmers for system programmers.

    This must be one of the most uninformed comment in a long time. Already 2001, there was quite a lot of UI work being done by the company Eazel, founded by Andy Hertzfeld who from Apple and with a bunch of former Apple people. Around the same time, Ximian (I think) was pushing project Utopia with the idea to form project teams of people from kernel devs up to UX, to ensure common tasks worked out of the box. One result of this is that printer configuration on Linux is a much easier than on any other OS. This all happened 20+ years ago, there have been quite a lot of UX people involved after that. And my experience is that people with little prior knowledge have an easier time with a modern Gnome desktop, than with Windows. The problem here is that most people know Windows to some extent, and are used to the weird quirks there, but any slight inconvenience on a new OS make them quit.

  • So, I will finally be able to drop some deps and use the built-in chown. Nice!

  • Always happy to see more projects being open source.

  • Now, I don't have any experience with Axum, but my experience is that the frameworks are quite similar, so much of the porting tend to be in parameters and types, authentication and session (of course, this may vary from project to project). So if you are familiar with Axum this might be a good way to start contributing to Kellnr. Well, I guess if you just want to learn Axum, it might also be a good way to start, it will just be a little slower.... but I guess it is a good way to learn a new framework if you have the time to invest.

  • Great to see that this moves forward in a steady pace. And being able to compile Rust for Linux seems like a nice milestone, especially since many objections initially against rust in the kernel was about GCC support.

  • That depends on the job I want to do. But generally my selection is something like this.

    1. Is it a short simple script: Bash
    2. Longer script, then a more competent dynamic language like Perl/Python.
    3. Backend, a strong typed compiled language, with as few runtime errors as possible. If it depends on some particular API, the language with good enough bindings.

    Preferred backend language, Rust, since that have the least runtime errors, thanks to its strong typing and the great error handling. But I also use Go if it have better libs for what I do, or Java for situations where that is more suitable.

  • In the annoying popup, there is a cog wheel, clicking that will show a menu. That menu have a checked checkbox, Always offer to translate, uncheck that.

  • Yes, you have a point. However adding heat is often implicit when talking about melting stuff. However, if it requires 3400C, then the answer would probably include a comment about that.

  • Well, I agree. But what I mean is that when people ask physics questions, it is often implicitly understood to mean under current conditions. You rarely hear normal people or kids (who I find asks most of the physics question) include anything about frictionless vacuums in the question. (For reference: https://xkcd.com/669/ ). So, for the egg question, regular people would most likely consider the answer to be "No, except under very special circumstances". But, I agree with you that if a simple Yes/No answer is expected, it have to be Yes.