burjui

Joined 11 years ago

Karma

Submissions

Member since

Jul 27

Yet another programmer.

View on Hacker News

Recent submissions

Comment · 1 year ago

> 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.

Comment · 1 year ago

It's more likely they will end up shotgunning sloppy AI PRs.

Comment · 1 year ago

... 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!"

Comment · 1 year ago

I've used the 2013 algorithm, it's fast, simple enough and easy to implement in Rust.

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

At least, we can assume that after a few weeks, he became not quite that depressed.

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 2 years ago

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.

Comment · 2 years ago

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.

Comment · 2 years ago

C++ & autotools. No, thanks.

Comment · 2 years ago

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.

Comment · 2 years ago

> 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.