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

201–210 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#201

Post by WalterBright »

flavio81 wrote: post #200
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…

> I beg to differ. C was a fairly obscure language until MS-DOS came out. On the early days of DOS, what was used the most was IBM-BASIC (and GW-BASIC) for users, assembler for games like Alley Cat, IBM LOGO for teaching, some games were made on FIG-FORTH even Then borland brought Turbo Pascal which was hugely popular together with MS QuickBasic. Meanwhile, and we're at 1986-7, a good amount of software was already m…

There were probably 30 C compilers for the IBM PC. Turbo C didn't appear until 1987, it was quite a latecomer. C was immensely popular on the C before then.

Borland produced Turbo C not to introduce C to the PC, but because C was so dominant on that platform. After all, why would they have done that after being so successful with Turbo Pascal?

Re: Rust: Not So Great For Codec Implementing

#202

Post by WalterBright »

WalterBright wrote: post #201
flavio81 wrote: post #200

Earlier quoted context omitted.

> I beg to differ. C was a fairly obscure language until MS-DOS came out. On the early days of DOS, what was used the most was IBM-BASIC (and GW-BASIC) for users, assembler for games like Alley Cat, IBM LOGO for teaching, some games were made on FIG-FORTH even Then borland brought Turbo Pascal which was hugely popular together with MS QuickBasic. Meanwhile, and we're at 1986-7, a good amount of software was already m…

There were probably 30 C compilers for the IBM PC. Turbo C didn't appear until 1987, it was quite a latecomer. C was immensely popular on the C before then. Borland produced Turbo C not to introduce C to the PC, but because C was so dominant on that platform. After all, why would they have done that after being so successful with Turbo Pascal?

The Aug 1986 issue of Dr. Dobb's lists:

* Aztec C

* C86

* Datalight C (mine!)

* DeSmet C

* Eco-C88

* Hot C

* IBM C

* Lattice C

* C Prog Sys

* Let's C

* High C

* Microsoft C

* Mix X

* Toolworks C

* Whitesmiths C

* Wizard C

PC Tech Journal reviewed 8 C compilers for DOS in their Nov-Dec 1983 issue, though I don't have a copy of it.

Re: Rust: Not So Great For Codec Implementing

#203

Post by camgunz »

_5ysi wrote: post #196
camgunz wrote: post #101

Earlier quoted context omitted.

I can't speak for the author of course, but probably their argument is that a systems language should be able to directly manipulate bits and bytes without outside dependencies. I don't know that I agree. A reasonable counter example is that you need library support to allocate memory in C. The argument is that it's a feature to not require C implementations to include dynamic memory allocation because not all projec…

You don't need a library to allocate memory in C. For example on Linux, use sbrk() system call to grow the heap, then start using it. But your larger point still stands.

Aha yeah, fair point :)

Re: Rust: Not So Great For Codec Implementing

#204

Post by camgunz »

kibwen wrote: post #176
camgunz wrote: post #148

Earlier quoted context omitted.

Sure it is. We're talking about what should and shouldn't be a dependency. The acute problem with left pad was npm's design, but the cultural problem (if you consider it a problem) was that anything depended upon something so small in the first place.

The circumstances that led to the left-pad fiasco were because of Javascript's uniquely anemic standard library (at least until very recently). Rust's stdlib is not small in the same way that Javascript's historic stdlib was. Rust's stdlib is narrow, yet deep : a relatively small number of modules that themselves provide a very large number of operations and convenience functions. Rust dependency graphs can get prett…

Agree 100%. I think Rust's stdlib is useful and coherent, and shows the way for other libraries. It's a great piece of engineering.

Re: Rust: Not So Great For Codec Implementing

#205

Post by binarycrusader »

pcwalton wrote: post #124
binarycrusader wrote: post #107

Earlier quoted context omitted.

The short version is that a component distributed with an embedded copy of its dependencies means a single legal review since it's a snapshot in time of a particular version of that component and its dependencies. A component that instead references its dependencies and that have their own release schedule/versions, etc. requires a legal review for that component and each of its dependencies. This has been true at mu…

Again, that's what the Rust Platform is for. It's a better solution than copying code, because it doesn't throw away all of the benefits of Cargo just to make some legal policies at some large companies a little easier.

We're going to have to agree to disagree.

This is where I actually prefer Go's "vendor" approach to dependencies. It would be great if rust / cargo eventually had the same and more authors adopted it or simply copied their little dependencies instead of having external dependencies on them.

Something like this proposed command, except for crate maintenance instead of distribution:

https://users.rust-lang.org/t/cargo-cook-subcommand/10288

Re: Rust: Not So Great For Codec Implementing

#206

Post by camgunz »

kbenson wrote: post #152
camgunz wrote: post #148

Earlier quoted context omitted.

Sure it is. We're talking about what should and shouldn't be a dependency. The acute problem with left pad was npm's design, but the cultural problem (if you consider it a problem) was that anything depended upon something so small in the first place.

Rust has the capability to, and I believe the developers have expressed they are amenable to, internalizing crates that become the best solutions for a problem. Would you rather a flawed, or later deemed incomplete internal solution be implemented and then the language is forced to support it in perpetuity, or would you rather one or more solutions get tried and the best implementation and syntax eventually accepted…

Oh God no, haha. I started out in Python and I'm pretty sure all of us have fallen out of love with batteries included.

You can see what happens when you go too far the other way though. C has effectively no basic data structures like strings, lists, hash tables, etc., so anything you interface with has its own idea on how to handle that stuff. Library X might return an array of Things that's NULL terminated. Library Y might return an array of Thangs and a size_t output param. Or like you pointed out in JS, its standard library is full of holes so you get tiny projects that attempt to plug them, or larger projects that try to make JS into a specific kind of language (Underscore), or full on programming languages that transpile to it.

I just don't think the problem is definitively solved though. Personally I think Bytes should be in Rust's stdlib. I think bit and byte manipulation is a fundamental part of a language and there should be a standard way of doing it, especially if there are things like TCP/UDP and hash tables in there. I understand the arguments against; I really like the design of Rust's stdlib, but I feel like there's room for disagreement. That's all I'm saying :)

Re: Rust: Not So Great For Codec Implementing

#207

Post by nnethercote »

Gankro wrote: post #86
AceJohnny2 wrote: post #83

Codecs are actually a wonderful test-case for Rust: they're a frequent source of vulnerabilities because they have to deal with arbitrary input, they usually have to perform fiddly sub-byte and/or array manipulation, and their pressure for maximum performance mean they have to make as efficient use of the hardware and memory as possible (and any mistake lead back to the first point) So even if you don't agree with so…

Yes, let us never forget how many exploits there are in trivial codecs like ICO and BMP, because they're written in C(++): https://bugzilla.mozilla.org/show_bug.cgi?id=775794#c0

BMP isn't so trivial, largely because it's been extended multiple times while never having a proper spec.

http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b2092... has some of the gory details.

Re: Rust: Not So Great For Codec Implementing

#208

Post by jschwartzi »

dbaupp wrote: post #178
StillBored wrote: post #171

Earlier quoted context omitted.

What I find odd about your reply, is that you downgrade C++, yet its really the only language that has sufficient operator overloading to do what the poster was requesting (transparent support without OO overhead). AKA, its completely possible, and there are quite a number of C++ libraries that make vectors look like native types complete with long lists of global operator overloads for interaction with other base ty…

I didn't denigrate C++, I'm specifically talking about the behaviour of the data types/mention of OOP which is orthogonal to the surface syntax like using symbolic operators instead of textual names. It is factual that the default data declaration in C++ has a little of the "pointer soup" due to methods and `this`. This can often get inlined away and so is usually irrelevant (hence "almost so"), but the poster did em…

You could also wrap a reference to a plain old struct and operate on it using a class. That's often how I write C++ when I need to be explicit about how the data is structured. Not everything in C++ requires an OO approach.

OP was specifically recommending operator overloading on a plain old struct, which can be done without declaring a class. Indeed, operator overloads can be declared as global functions in C++. The this pointer doesn't enter in to it at all in that case.

Re: Rust: Not So Great For Codec Implementing

#209

Post by IncRnd »

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

ZTC was a fantastic compiler, that is until it was purchased by Symantec, renamed, and become slow and bloated.

I could even say something similar about turbo c vs turbo c++, but that was more due to the language issues with c++ vs c.

Re: Rust: Not So Great For Codec Implementing

#210

Post by FrozenVoid »

phkahler wrote: post #39
mrec wrote: post #22

Earlier quoted context omitted.

If anyone's interested, this is the (epic!) discussion thread for "Getting explicit SIMD on stable Rust": https://internals.rust-lang.org/t/getting-explicit-simd-on-s... It still wouldn't compete with really good hand-tuned asm, but it might help reduce the perf/usability tradeoff a bit.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
Post reply on HN