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

221–230 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#221

Post by _5ysi »

Sharlin wrote: post #216
_5ysi wrote: post #196

Earlier quoted context omitted.

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.

I think that the point was more that heap allocation is not a standard language primitive in C. And indeed, it would be ludicruous to require dynamic allocation support from freestanding implementations (no standard library because typically your platform doesn't even have an OS).

Ah sorry camgunz I interpreted the counter example as claiming malloc() was a dependency. referencing the wrong subject!

Re: Rust: Not So Great For Codec Implementing

#222

Post by littlestymaar »

kbenson wrote: post #106
pcwalton wrote: post #76

Earlier quoted context omitted.

But you're bound by the license even if you copy and paste the code into your project instead of using Cargo.

I think this is where reality meets theory. In reality, the developers are probably just taking the code as if they had written it, and the people that may know, such as immediate supervisors, don't care to point it out for the same reason the developers are stealing it, it's much easier than the alternative. The code vetting team is just left in the dark. Employees take shortcuts around bureaucracy all the time. Som…

> and the people that may know, such as immediate supervisors, don't care to point it out for the same reason the developers are stealing it, it's much easier than the alternative.

If your company gets aquired one day, the code will probably be audited during the due diligence process. If licence violations related to copy-pasting is found, your team will be asked to remove the infringing code and your supervisor may be fired. This happened to my team in the first company I worked for (not the firing part though) : we had a lot of code which was just copy-pasted from lodash and the audit found it.

Re: Rust: Not So Great For Codec Implementing

#223

Post by pjmlp »

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…

Sorry but on my little corner of the planet, in the Iberian Peninsula, everyone was using Turbo Basic and Turbo Pascal, when not coding in Assembly for MS-DOS.

On the PC, C and C++ only started to be widely adopted as we started to code for Windows 3.x, due to the APIs being available as C instead of interrupts.

At the technical school I was attending, I was the outlier by having had the opportunity to get hold of Borland's Turbo C++ 1.0 for MS-DOS, everyone else couldn't care less.

Most Portuguese and Spanish magazines of the 80's and early 90's were full all imaginable programming languages for C64, ZX Spectrum, Amiga, Atari and MS-DOS. C didn't had a better spot on those articles than the other languages, quite the contrary.

Fellow Iberian HNers are free to correct my experience of those years.

Re: Rust: Not So Great For Codec Implementing

#224

Post by pjmlp »

WalterBright wrote: post #202
WalterBright wrote: post #201

Earlier quoted context omitted.

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.

The majority of them unknown or impossible to buy in the 1983's reality of Portugal and Spain, as I mention in another comment.

Re: Rust: Not So Great For Codec Implementing

#225

Post by Manishearth »

mook wrote: post #139
steveklabnik wrote: post #2

A lot of good comments on Reddit, with answers/solutions/discussion of the points brought up here: https://www.reddit.com/r/rust/comments/6qv2s5/rust_not_so_gr... These kinds of experience reports are so valuable. (I've been following the whole series and they're very interesting.) Even if solutions to these issues do exist, if people can't find them, well that's a problem too.

Seems like (from that Reddit thread) a lot of the things are in progress in the nightlies. I wonder if that means the nightlies are holding Rust back (because it relieves the pressure to actually ship features for use by normal developers).

I think that was a minority of the points; the majority of the points was in the space of the author not realizing something was possible in Rust.

Out of these points they were all for features which are steadily on their way to stable (or future things which are actively being worked on right now).

Very few folks use nightly -- many use it locally for improved developer tooling, but mostly everyone wants their crate to work on stable.

So I wouldn't say it relieves pressure that way.

Re: Rust: Not So Great For Codec Implementing

#226

Post by pjmlp »

barrkel wrote: post #192
glandium wrote: post #186

Earlier quoted context omitted.

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

TP's OOP was modelled after Apple's Object Pascal. It was an awkward ugly implementation that had e.g. slicing problems and weird initialization syntax, and was fairly quickly deprecated when Delphi came around.

I loved Object Pascal, and it was my introduction to OOP, literally.

As I had to give a class on OOP to fellow students at the technical school as exchange for having access to Turbo Pascal 5.5.

Never was a big fan of some of the Object Pascal changes made by Delphi's class model, specially the fact that it was a kind of lost the opportunity to introduce RC alongside those changes.

Which eventually lead to the schizophrenic model that RC would only exist for COM based classes, but not others.

Re: Rust: Not So Great For Codec Implementing

#227

Post by pjmlp »

cryptonector wrote: post #81
davemp wrote: post #58

> And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean) Honestly after a ~1yr of embedded C co-op/intership experience, I'm familiar enough but not too entrenched to say that C is not that great for embedded/systems. When you're dealing at the hardware architecture level you need more detail tha…

"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…

> Really, that's all. If it was possible to build C++ classes in C or assembly, it would be done.

IBM's mainframe OS/400, nowadays known as IBM i supports OO Assembly.

MASM also used to have OO Macros.

Re: Rust: Not So Great For Codec Implementing

#228

Post by pjmlp »

adrianratnapala wrote: post #150
cryptonector wrote: post #146

Earlier quoted context omitted.

I'm not surprised. But you'll note I said "C++ classes", and I did that for a reason: it's not possible to write C++ classes in C because there's no stable, public ABI for one to write to. (Well, for some compilers there may be a public ABI, and some might even be stable, but even so, it's a mess.)

On particular platforms they have nailed down the C++ layout enough to make this possible. I think windows did it for COM (or DCOM?). But in general you are right. On of the most infuriating things about fancy languages is the way they all have their own ABIs. I mean it's nice that they support special features through those ABIs, but standardized vtables and dictionaries would take us a long way. And Kudos to Micros…

> And Kudos to Microsoft for having a second crack at getting that right with .Net.

IBM did it first with TIMI for AS/400.

Also Microsoft is now in their third crack at getting it right with UWP (based on COM).

Re: Rust: Not So Great For Codec Implementing

#229

Post by eddyb »

binarycrusader wrote: post #205
pcwalton wrote: post #124

Earlier quoted context omitted.

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

FWIW `cargo vendor` already exists, just not part of Cargo itself, but rather a tool by one of the core devs.

It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and the compiler.

Re: Rust: Not So Great For Codec Implementing

#230

Post by pjmlp »

davemp wrote: post #162
adrianratnapala wrote: post #151

Earlier quoted context omitted.

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…

Thinking about hardware is definitely the move when writing C. This is the major struggle with abstraction. We want to remove the burden of knowing the ins and outs of the target architecture. Inevitably, we create trouble and fall on our faces when it turns out that the hardware is still in fact there and doesn't like when we ignore it. It's really an impossible problem. One can't account for every architecture when…

Easy check the family of Algol, Xerox PARC, Wirth languages.

Where safety is more relevant than maximum portability.

Everything that isn't really portable is marked as explicit language extension or unsafe construct.

One might complain that it leads to language dialects, but the same is true for C, where certain semantics depend on the compiler and even change between versions.

Post reply on HN