HackerTrans
TopNewTrendsCommentsPastAskShowJobs

burjui

no profile record

comments

burjui
·ano passado·discuss
> rav1d is transpiled c-to-rust version of dav1d

Sounds like a bad way to port. Completely different languages. It took me some time to learn that one cannot simply write C code in Rust and expect the result to be any good. Should've started from scratch.
burjui
·ano passado·discuss
It's more likely they will end up shotgunning sloppy AI PRs.
burjui
·ano passado·discuss
... in the way of writing code with undefined behaviour. "You don't tell me how to live! Maybe I want to shoot myself in the foot sometimes! I already shot myself in the head, and it was awesome, instantly made me an old fart that refuses to learn. Ignorance is bliss!"
burjui
·ano passado·discuss
I've used the 2013 algorithm, it's fast, simple enough and easy to implement in Rust.
burjui
·ano passado·discuss
I wonder what's the point. 8 bits is not enough to store most values for most applications, it's bad for timers and multiplication, it's just a big waste of CPU cycles in general. The more work CPU has to do, the less time it spends sleeping, which is bad for battery-powered embedded devices. Perhaps, it has its place somewhere, but realistically, an 8-bit CPU these days is very niche at best. Imho, it's not going to take off in mainstream embedded.
burjui
·ano passado·discuss
One day I needed to parse and generate RISC-V instructions. I wrote a custom bitfield implementation, nothing fancy: no derive macros or any crap like that, only u32 bitfields specified by an array — [(RangeInclusive<u32> /src/, usize /length/, RangeInclusive<u32> /dst/]. One function + a bunch of tests. It worked great. Then I tried the `bitfield` crate, which claims to be as fast as code I would've written by hand. It had dependencies and was two orders of magnitude slower. Basically, it was as fast as code that I would've written by hand in Python.
burjui
·ano passado·discuss
At least, we can assume that after a few weeks, he became not quite that depressed.
burjui
·há 2 anos·discuss
Why it's always the borrow checker that bugs the haters? You don't even see it work most of the time, because instead of using references everywhere, like most C++ers are conditioned to do, not only you can move values (doesn't necessarily mean actually performing memory operations), but also the compiler checks that you don't use the variable from which the value has been moved. And even if you do use references everywhere, they don't usually cause any problems, unless you decide to put more than one reference in a often used struct. I often use both shared (RO) and exclusive (RW) references as function arguments and rarely have to specify lifetimes manually, because automatic lifetime elision done by the compiler is sufficient in most cases.
burjui
·há 2 anos·discuss
Exactly the same experience : my toy compiler project has 10477 lines of Rust code, and there is only one line with unsafe:

  let is_tty = unsafe { libc::isatty(libc::STDERR_FILENO) } != 0;
Here's the source, just in case: https://github.com/burjui/rambo/

In fact, there are exactly two "unsafe" blocks in all of my Rust projects, and the second one is not even needed anymore because of the language and ecosystem improvements, but the project is basically abandoned, so I'm probably not gonna fix it. There's just no need for unsafe in the vast majority of code.

I don't know where Rust critics get their statistics; probably from picking their noses, judging by their arguments. Most don't seem to even have read the official docs, the bare minimum required to form any conclusions at all about the language. I guess they don't read much Rust code and think there is no way we can write even semi-decently performing high-level code without resorting to unsafe hacks or calling C, because that's the way it's done in other languages.
burjui
·há 2 anos·discuss
It's literally THE unsafe part of the code. It's the only part of code that can invoke UB.

  fn do_something() {
      unsafe { ... }
  }

  // Somewhere in the program
  do_something();
Doesn't matter where "do_something" is used and how much. The only possibly problematic part of this code is the unsafe block. You only audit it.
burjui
·há 2 anos·discuss
Even plain C++ is very hard to read, it's one of the reasons I ditched it. Cannot even imagine writing code in this version. C++ is overcomplicated already, imho it's best to leave it to die naturally instead of prolonging the suffering of millions that use it.
burjui
·há 2 anos·discuss
Apply the flame to the sysadmin's hand and get root access. I mean, it's a cool demo, but if you can solder crap to the hardware, might as well do anything that physical access provides normally. Like, you can just install the payload without the exploit.
burjui
·há 2 anos·discuss
C++ & autotools. No, thanks.
burjui
·há 2 anos·discuss
I would like that veey much, but they likely will not go to prison, just pay off the damages, as usual. Capitalism works that way.
burjui
·há 2 anos·discuss
> I think Ada not being very popular shows that the need for a memory safe non-garbage collected language is kind of overstated.

It only shows that Ada is very old and verbose.
burjui
·há 2 anos·discuss
It's not impossible. But if one says "Rust is bad", they better elaborate, unless their goal was to post a meaningless comment.
burjui
·há 2 anos·discuss
It doesn't. Most people complaining about "ugliness" of Rust are either too lazy to read documentation (which is great btw), or just don't like the syntax, because it doesn't resemble their favorite language[s]. Some have valid criticism, but they usually lay it out straight, sometimes in the form of a blog post, instead of vague "Rust is bad" statements.
burjui
·há 2 anos·discuss
How about writing relatively complex things not in Bash? If your shell script requires configuration, it shouldn't be a shell script.
burjui
·há 2 anos·discuss
That's why paths in Rust don't have to be UTF-8. See Path and OsStr documentation.
burjui
·há 2 anos·discuss
The algorithm uses less memory, but more CPU time because of rather frequent deletions, so it's a tradeoff, not just generally better algorithm, as article may suggest.