Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Not So Great For Codec Implementing

codecs.multimedia.cx

Post reply on HN
Print view View original

181–190 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#181

Post by glandium »

WalterBright wrote: post #153
flavio81 wrote: post #144

Earlier quoted context omitted.

> And that’s why C is still the best language for systems programming I think the only reason C is very popular for systems programming is that it allows you to do most of what you could do in assembler, but in an easier-to-work way. So basically C is an "acceptable, easier-to-use assembler", but far from ideal, because of the reasons you point out. Honestly, the popularity of C itself is due to the success of UNIX,…

> Honestly, the popularity of C itself is due to the success of UNIX, I beg to differ. C was a fairly obscure language until MS-DOS came out. C turned out to be ideal for programming on DOS, and DOS programming was far and away the most programmed system in the world for a decade and a half. MS-DOS also made C++ into a major language (via Zortech C++). When ZTC++ came out the penetration and popularity of C++ went th…

Turbo Pascal was much better for programming on DOS IMHO.

Re: Rust: Not So Great For Codec Implementing

#182

Post by WalterBright »

turboturb wrote: post #175
WalterBright wrote: post #153

Earlier quoted context omitted.

> Honestly, the popularity of C itself is due to the success of UNIX, I beg to differ. C was a fairly obscure language until MS-DOS came out. C turned out to be ideal for programming on DOS, and DOS programming was far and away the most programmed system in the world for a decade and a half. MS-DOS also made C++ into a major language (via Zortech C++). When ZTC++ came out the penetration and popularity of C++ went th…

In my part of the world, we used the Borland compilers for MS-DOS, Turbo C and Turbo C++. Turbo Assembler and Turbo Pascal was also popular. Never heard of Zortech C++ before

Borland decided to develop TC++ because of the success of ZTC++. (I know some of the people involved.) Before ZTC++, C++ was a niche language, and Borland was having great success with Turbo Pascal. ZTC++ came out in 1987, and TC++ in 1990.

After the success of ZTC++ and TC++, Microsoft changed direction and decided to develop a C++ compiler, too. I heard (but was never able to confirm) that Microsoft had earlier been developing their own object oriented extensions to C called C*.

Re: Rust: Not So Great For Codec Implementing

#183

Post by WalterBright »

glandium wrote: post #181
WalterBright wrote: post #153

Earlier quoted context omitted.

> Honestly, the popularity of C itself is due to the success of UNIX, I beg to differ. C was a fairly obscure language until MS-DOS came out. C turned out to be ideal for programming on DOS, and DOS programming was far and away the most programmed system in the world for a decade and a half. MS-DOS also made C++ into a major language (via Zortech C++). When ZTC++ came out the penetration and popularity of C++ went th…

Turbo Pascal was much better for programming on DOS IMHO.

TP was indeed a fine project. But it wasn't OOP (which was very hot at the time) and TP was very customized to the PC, meaning it had no penetration outside of DOS. TP died when DOS died.

Re: Rust: Not So Great For Codec Implementing

#184

Post by Manishearth »

davemp wrote: post #172
Manishearth wrote: post #80

Earlier quoted context omitted.

> but if it makes an honest effort to be ergonomic for embedded There are constant improvements but I wouldn't say we're there yet. I think we will be though, embedded is something a lot of folks care about.

Good to hear. I'm sure there is a large group of developers sitting on the sidelines that check in from time to time hoping to be able to leave C behind. Has anyone on the rust team tried reaching out to get input/contributions from companies who are heavily invested in the embedded world? I know xilinx pours a lot of effort into language research, they do seem like an very proprietary company though.

We reach out and talk with companies regularly. We are both happy to organize a meeting with companies who approach us, and often (~yearly) organize calls with multiple companies using or evaluating Rust at once whom we reach out to. I believe there have been some of these focused on embedded stuff, but I wasn't on these calls.

Re: Rust: Not So Great For Codec Implementing

#185

Post by dbaupp »

comex wrote: post #174
pcwalton wrote: post #40

Earlier quoted context omitted.

As the article notes in an edit, there's a method for this: split_at_mut(). It's very useful, and I reach for it quite a bit in low-level array code. It might be nice to have some sort of pattern matching syntax for it, I suppose: let [ref mut a..16, ref mut b..] = *c; Meh. Sure is ugly. I'm not sure adding syntax would be worth it.

I feel like split_at_mut is a bit of a red herring - sure, it's exactly what the author was looking for and unable to find, but it's masking a bigger problem/opportunity here. Why does the author have to worry about aliasing in the first place? If they're dealing with POD types, there's no memory safety issue implicated by allowing overlapping slices (except possibly when accessing from multiple threads). No-alias gu…

It is safe, and was even modeled explicitly as part of https://www.ralfj.de/blog/2017/07/08/rustbelt.html .

There's the external https://crates.io/crates/alias and even an approved RFC for adopting it into std: https://github.com/rust-lang/rust/issues/43038 .

Re: Rust: Not So Great For Codec Implementing

#186

Post by glandium »

WalterBright wrote: post #183
glandium wrote: post #181

Earlier quoted context omitted.

Turbo Pascal was much better for programming on DOS IMHO.

TP was indeed a fine project. But it wasn't OOP (which was very hot at the time) and TP was very customized to the PC, meaning it had no penetration outside of DOS. TP died when DOS died.

TP 5.5 (1989) had OOP. https://en.wikipedia.org/wiki/Turbo_Pascal#Object-oriented_p...

I only started using TP with version 6, so all I know is OOP TP...

Re: Rust: Not So Great For Codec Implementing

#187

Post by comex »

dbaupp wrote: post #185
comex wrote: post #174

Earlier quoted context omitted.

I feel like split_at_mut is a bit of a red herring - sure, it's exactly what the author was looking for and unable to find, but it's masking a bigger problem/opportunity here. Why does the author have to worry about aliasing in the first place? If they're dealing with POD types, there's no memory safety issue implicated by allowing overlapping slices (except possibly when accessing from multiple threads). No-alias gu…

It is safe, and was even modeled explicitly as part of https://www.ralfj.de/blog/2017/07/08/rustbelt.html . There's the external https://crates.io/crates/alias and even an approved RFC for adopting it into std: https://github.com/rust-lang/rust/issues/43038 .

Doh, way ahead of me then. Though it seems there are more steps needed, e.g. adding support to the ‘bytes’ crate.

Re: Rust: Not So Great For Codec Implementing

#188

Post by StavrosK »

atbentley wrote: post #108
StavrosK wrote: post #31

Earlier quoted context omitted.

I agree! Are you running a local node? I was thinking that a browser extension that automatically redirected URLs like ".*/ip[fn]s/\w+" to the local daemon address would be pretty useful.

Check out ipfs station if you use chrome. https://chrome.google.com/webstore/detail/ipfs-station/kckhg...

Fantastic, that's exactly what I wanted, thank you. It doesn't seem to like my remote node, but I'll figure it out.

Re: Rust: Not So Great For Codec Implementing

#189

Post by dep_b »

flavio81 wrote: post #145
cryptonector wrote: post #81

Earlier quoted context omitted.

"do what I want" usually means "simple ABI that is trivial to interface with" which means you "can layout structures the way you want" and "calling conventions are simple so you can call C from assembly and any HLL FFIs and vice-versa". Really, that's all. If it was possible to build C++ classes in C or assembly, it would be done. But it's not because C++ doesn't have the kind of ABI (or any) that would allow one to…

> If it was possible to build C++ classes in C or assembly You would be surprised, but Object-oriented programming has been done in C many times... and even before C++ existed.

Objective-C used to be a precompiler to C. Hence the weird syntax, they needed some character patterns that weren't used yet in C to be able to preprocess the Objective-C parts.

Re: Rust: Not So Great For Codec Implementing

#190

Post by wahern »

adrianratnapala wrote: post #151
legulere wrote: post #118

Earlier quoted context omitted.

Just a tiny nitpick: Only signed integer overflow is undefined, unsigned integer overflow follows modulo arithmetics. It's pretty much impossible to remember all those details.

These things originate in hardware variations. Apparently all architectures use binary the same way so unsigned overflow just drops the MSB. But signed integers aren't always two's complement, so there is variation. See, no tedious rules to remember, you just have to understand how computers work. But the C standards call such things "undefined behaviour" rather than "platform specific" behaviour, and then try to pre…

At least one extant (or recently extant) system has to emulate unsigned, modulo arithmetic. This can be handled by the C compiler transparently, however. From the C compiler documentation:

  | Type          | Bits | sizeof | Range                                  |
  +---------------+------+--------+----------------------------------------+
  | ...                                                                    |
  | unsigned long | 36   | 4      | 0 to (2^36)-2 (see the following note) |

  ...
  Note: If the CONFORMANCE/TWOSARITH or CONFORMANCE/FULL
  compiler keywords are used, the range will be 0 to (2^36)-1.
  See the C Compiler Programming Reference Manual Volume 2 for
  more information.

  -- Section 4.5. Size and Range of C Variables of the Unisys
  C Compiler Programming Reference Manual Volume 1.
  https://public.support.unisys.com/2200/docs/cp16.0/pdf/78310422-012.pdf
Post reply on HN