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

Wuffs’ PNG image decoder

nigeltao.github.io

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Wuffs’ PNG image decoder

#71

Post by kbenson »

quotemstr wrote: post #38
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

All of Windows (including the NT kernel) is written using the same basic proof model that Wuffs uses, except that the constraints are specified as annotations on top of C and C++ instead of as a new programming language. I prefer the annotation approach, TBH, but I'm glad to see people working on safety. Specifically, Wuffs (like Rust) has this problem where it tries to fill the same niche as C and C++ and improve on…

> I'm a big believer in technical continuity. IMHO, a lot of recent language developments should have instead been extensions of C, C++, Java, or Python.

If that's what you really wanted, and if we always did that, then you would probably want extensions to Perl instead of Python, since it predated it slightly and was much more popular much earlier.

Instead, I think what you're really asking for is language extensions to the things you are familiar with. Those happen to be things a lot of other people are also familiar with, but that doesn't change that the same strategy results in Perl still getting the lion's share of attention. I, for one, would be perfectly happy with that, as I love Perl, but many people would not, and possibly not for any real technical reason.

Anyone that thinks the case for Rust or D is better served by extensions to C or C++ but thinks that Python is objectively a better language than Perl should probably look deeply at exactly why they hold those views.

P.S. That's not really to say you hold those views. Consider this comment less a critique of your specific statement than slight tangent spurred by it.

Re: Wuffs’ PNG image decoder

#72

Post by marius_k »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

As I understand wuffs goal is to be good enough for parsers coders decoders. It looks like they can still achieve that by sacrificing some of the nice features of other languages.

Re: Wuffs’ PNG image decoder

#73

Post by bgwhn »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

> Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect.

Isn't that pretty much what `#![no_std]` is for? You can still use an allocator with no_std, but you have to explicitly import it.

https://docs.rust-embedded.org/book/intro/no-std.html

Re: Wuffs’ PNG image decoder

#74

Post by nynx »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Rust already has a "mode" that forbids allocations: no-std without the alloc crate.

Re: Wuffs’ PNG image decoder

#75

Post by michaelcampbell »

ivoras wrote: post #52

Surprisingly, Go's png decoder is half as slow as the default libpng :( https://nigeltao.github.io/blog/2021/fastest-safest-png-deco...

Ugh, what does "half as slow" mean? Twice as fast? Half the speed?

Any comparison to "slow" is generally the wrong direction.

Re: Wuffs’ PNG image decoder

#76

Post by the8472 »

nyanpasu64 wrote: post #65
NickPollard wrote: post #63

Earlier quoted context omitted.

I've not been following recent Rust development as closely, can you elaborate on what limited form of dependent types Rust is adding?

Functions and types can take integers as monomorphization-time template parameters (const generics). It would be nice if you could pass (n, t) where n is supplied at runtime, the type of t depends on the value of n, and the compiler only lets you use t if your code is valid for all reachable values of n. eg. fn(n: usize, arr1: &[i32; n], arr2: &[i32, n]) allowed the function body to assume the two slices can be zippe…

> eg. fn(n: usize, arr1: &[i32; n], arr2: &[i32, n]) allowed the function body to assume the two slices can be zipped without losing elements.

Often you can wrangle the optimizer into eliminating all but one bounds check by passing slices instead and then slicing one of the inputs in terms of length of the other. The Zip iterator adapter also has optimizations for the case of two slices where iteration will only require two length queries at the beginning and no further bounds checks.

Re: Wuffs’ PNG image decoder

#77

Post by WalterBright »

quotemstr wrote: post #38
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

All of Windows (including the NT kernel) is written using the same basic proof model that Wuffs uses, except that the constraints are specified as annotations on top of C and C++ instead of as a new programming language. I prefer the annotation approach, TBH, but I'm glad to see people working on safety. Specifically, Wuffs (like Rust) has this problem where it tries to fill the same niche as C and C++ and improve on…

> I'm a big believer in technical continuity.

So am I. D is designed to be an easy transition from C and C-With-Classes. For example, here is some code in C that was translated to D (it's part of the Digital Mars C++ compiler):

C:

https://github.com/DigitalMars/Compiler/blob/dmc-cxx/dm/src/...

D:

https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...

They look pretty much the same. The code generated is the same. In those repositories you can also see how I translated the C versions to D with plenty of examples.

The biggest impediment is the C preprocessor. You wouldn't really want to carry that forward.

After removing dependency on the C preprocessor, most of the work is global search/replacing things like `->` to `.`.

Re: Wuffs’ PNG image decoder

#78

Post by [deleted] »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

[deleted]

Re: Wuffs’ PNG image decoder

#79

Post by amelius »

andrepd wrote: post #64
mleonhard wrote: post #61

Earlier quoted context omitted.

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Isn't that stupidly limiting?

After NoSQL, now we also have NoAlloc :)

Re: Wuffs’ PNG image decoder

#80

Post by [deleted] »

nynx wrote: post #74
mleonhard wrote: post #61

Earlier quoted context omitted.

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Rust already has a "mode" that forbids allocations: no-std without the alloc crate.

[deleted]
Post reply on HN