15 ms·
The Piston image library is now pure Rust
- nercury 10y agoThis is fantastic news! This was the reason I kept using SDL2_image - I had too much trouble compiling Rust image crate on windows.
- mrich 10y agoAny benchmarks?
- lacampbell 10y agoIt's now 120% more fashionable. I have no idea why this is on the front page. If you want us to care about a re-write into a different language, put some effort into it: http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...
- bsaul 10y agoIf only rust had concurrency / parallel programming primitives or library as nice as golang or elixir,i think i'll move to this language right away. For now i'm still holding my breath before developping with it on the server side.
- Ar-Curunir 10y agoIsn't the point of Rust to enable easy concurrency?
- bsaul 10y agoI think it's to enable safe concurrency. The problem is they decided to let others build the primitives for concurrency, on top of the stdlib. Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc..
- pcwalton 10y ago> Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc.. Having the language decide on one method of concurrency would make it useless for lots of people's purposes (including ours).
- stshine 10y agoOn the other hand, since these methods are not compatible it will create certain split in the ecosystem.
- msbarnett 10y agoThose splits are inevitable. There is no One Size Fits All concurrency primitive. Embedded devs and web devs have vastly different requirements. Either the split is "every use-case finds the primitive that works best for it" (Rust), or the split is "here's the blessed primitive, other use-cases can pound sand" (Go)
- Manishearth 10y agoMust it? In fact, I'd expect the reverse -- choosing a model for the language will make the ecosystem tied to that model For example, while tokio is being integrated with hyper, it does not affect the "usual" users of hyper at all, both in terms of API and in terms of what's going on under the hood, cost-wise. Having a blessed solution for async like tokio that is not in the stdlib seems to encourage folks to integrate with it, but not in an irrevocable manner; the core library stays intact and able to support potential other models in the future.
- stshine 10y agoSure, I do hope we can focus on one concurrency primitive, but the possibility that we may have async/await and coroutine at the same time seems kind of unfortunate to me.
- 10y ago
- tupshin 10y agowhile it's still in early days, keep you eye on the tokio project https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio which looks to be the foundation for higher level activity in this area
- bsaul 10y agoI did have a look at it. I think the initiative is great, but i don't like the idea of basing concurrency on async io primitives. I like the idea of actors or coroutine better, because it lets you code in a synchronous manner, and make concurrency block a little coarser and more manageable... Maybe i didn't understand everything on this project though, so please correct me if i'm wrong.
- Manishearth 10y agoRust may eventually get async/await syntax that works with futures so coroutine-based programming would be easy to do, regardless of whether or not it is backed by an event loop like tokio or something else. I'm not sure I get your point here, from other comments it seems like you're annoyed that Rust didn't choose a solution, and when tokio (which is the "chosen" solution for server side async stuff) is talked about you wish it had chosen a different one. As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.
- stymaar 10y ago> As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming. Since he mention Go and Erlang, I think what the gp just wishes Rust had a built-in solution for M:N threading. Whether M:N threading is nicer than async APIs is highly subjective though. (I'm talking about ergonomics here. I think it's widely accepted that async is more efficient when performance really matters)
- Manishearth 10y agoTokio/futures is going to be the "blessed" way of doing async IO (the way its done in server side apps). That should be ready sometime this year. It won't be in the stdlib but it will be integrated with most of the I/O related libraries in the ecosystem and the Rust team is involved in making it happen. It seems like you're talking specifically about async I/O here? Because Rust does have parallel programming primitives both in the stdlib and in the form of libraries like rayon and crossbeam. Rayon, in particular, is amazing for parallel programming.
- ekidd 10y agoI think some of issue here is that when you ask for "concurrency / parallel programming primitives", you're actually talking about more than one problem. We can divide things up as follows: - Data parallelism. This is where you have (for example) a giant array of data to process and want to use as many cores as possible. For this, rayon is gorgeous: https://github.com/nikomatsakis/rayon https://github.com/nikomatsakis/rayon Seriously, I can just not say enough good things about programming with rayon, and how nice Rust's "no mutable aliasing" makes coding. Also at some point, Rust will also need good libraries for talking to the GPU. - I/O concurrency. This is where you have a server that needs to respond quickly to 10,000+ sockets, for example. For this, it looks like everyone is standardizing on futures and tokio: https://github.com/alexcrichton/futures-rs https://github.com/alexcrichton/futures-rs https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio But it seems like you're most interested in Erlang-style actors with M:N green threads? The issue here is that—as best I remember the history of Rust—the Rust maintainers decided that green threads were simply too high a level of abstraction for Rust. I think Rust will eventually move back in that direction, first using futures+tokio+async I/O, and then by eventually adding async/await sugar on top. That way, you'll only pay for coroutines/green threads when you explicitly opt in. But it will take a year or so for all this to start maturing, I think. In the meantime, tokio's method-chaining syntax should actually be somewhat tolerable, especially because Rust has a `#[must_use]` attribute that prevents you from forgetting to use a future. If you're lazy, just run everything through rustfmt to get the indentation right.
- steveklabnik 10y ago> as best I remember the history of Rust There's an RFC for that! https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... (A reminder that this was written in 2014, so statements are about Rust at that time period) > I think Rust will eventually move back in that direction Note that tokio is not "green threads" as they're conventionally thought of, though they are similar if you squint, kinda.
- ekidd 10y ago> Note that tokio is not "green threads" as they're conventionally thought of, though they are similar if you squint, kinda. Well, I'm leaping ahead to the end of the story, here, and speaking far too loosely about technical details. ;-) Futures + tokio + a possible future async/await proposal would provide a reasonable enough syntax for actors/coroutines in Rust, I suspect.
- krzat 10y agoA bit offtopic, but when Rust will have incremental compilation? I just tested Piston's hello world and it takes 4 seconds to recompile. A bit too long for my taste.
- tupshin 10y agoThere is a lot of work already done, and more to do on this topic. The best source is the main tracking issue: https://github.com/rust-lang/rust/issues/2369 https://github.com/rust-lang/rust/issues/2369
- computerphage 10y agoI would recommend this link actually: https://github.com/rust-lang/rust/milestones?state=open https://github.com/rust-lang/rust/milestones?state=open
- a_humean 10y agoIt's a priority for this year with the ground work already completed last year: https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md https://github.com/rust-lang/rfcs/blob/master/text/1774-road... https://blog.rust-lang.org/2016/09/08/incremental.html https://blog.rust-lang.org/2016/09/08/incremental.html
- amelius 10y agoIt would be nice if they exposed these ideas, so that programs written in Rust can themselves become incremental.
- steveklabnik 10y agoWhat would this mean? Rust is AOT compiled, so I'm not quite understanding what it would mean for a program in Rust to become incremental.
- 10y ago
- phkahler 10y agoDoes it support higher bit-depth JPEG? Or just 8?
- wongarsu 10y agoFrom a quick look at the source code it seems only to support grayscale, RGB and CMYK jpegs with 8 bits per channel.
- ape4 10y agoImage libraries are exactly where we need rust-style safe code.
- zzzcpan 10y agoNo, image libraries is exactly where performance always beats safety and where other approaches to secure them actually work, like sandboxes and containers, and kind of have to be used anyway, since memory safety doesn't guarantee that unpacking an image won't DoS the system.
- steveklabnik 10y ago"Performance beats safety" is a dichotomy that Rust is attempting to fundamentally reject. Safety often means you can go faster, not slower, but it depends on context, of course.
- btrask 10y agoRust tightly couples performance and safety. Sandboxing separates out performance and safety, so you can take your pick of languages for performance, and your pick of sandboxes for safety, without conflict.
- Tobu 10y agoContainers provide resource limits but not necessarily safety. The ABI surface is too large. You kind of need the code inside them to be secure.
- zzzcpan 10y agoHmm, what large surface? You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived.
- pcwalton 10y ago> You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived. Not if you're going to take advantage of hardware acceleration.
- LeanderK 10y agowe are chasing more after trends than the fashion industry. The post contains no more info than that the image library is now pure rust. I want to like rust and understand that there are benefits to it, but why is this on the frontpage? What important information does this post contain that justifies this, beside that some project now has their image library in pure-rust (does that even make sense? Not every rewrite is justified, replacing a rock-solid c-lib with a brand new rust-lib may not be a good idea)? I just loosely follow rust and i really don't see how i benefit from reading this. I think we need to step back and realise that while there might be benefits to a certain technology, it's not a miracle drug.
- Ar-Curunir 10y agoC image libraries likr imagemagick are full of dangerous bugs. Using a performant memory safe language for image parsing and manipulation is a big win for security (and stability). If this image handling can be extracted into its own library ( maybe it already has), then it can be used by other projects, and maybe even by C and C++ projects.
- Agathos 10y agoFor example, https://imagetragick.com/ https://imagetragick.com/ "One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images."
- dbaupp 10y ago(FWIW, I don't think any of those bugs are directly addressed by Rust's memory safety guarantee, since they mostly seem to be string injection problems. The strong abstraction power of Rust versus C may help people create APIs that are more resistant, but people can always write bad code. And of course, those are unlikely to be the only bugs in that C code.)
- tinus_hn 10y agoUnfortunately, these bugs will not be prevented by using rust as they are not memory related bugs. If you code a command that reads and then deletes a file on the command line and people allow remote users to invoke that command remotely, the programming language is not going to help you. ImageMagick doesn't have the design that is necessary to be exposed to remote users. So it shouldn't be.
- ftact 10y agoSo it's unsurprising that rust isn't successful outside of HN. Imagine that.
- steveklabnik 10y agoBy what measure? We're seeing a huge uptick in production users. And a lot more who are pretty much waiting on Tokio to deploy more. Many of them read HN, but many of them don't.
- ftact 10y agoSecurity, upward mobility. The entire rust value proposition is based on its vulnerable memory safety. It's days are numbered, as are yours.
- the_mitsuhiko 10y agoThis constant stalking of Steve Klabnik is ridiculously annoying. It's almost impossible to read a Rust post here with not at least two or three individuals leaving useless comments like this.
- ftact 10y agoHe's a fag Edit, If he removed himself from rust and mozilla disavowed him, I'd PR some stuff I've been working on for rustc, including a fix for broken memory safeness. Klabnik will kill rust if not removed, guaranteed
- sctb 10y agoWe've banned this troll account. If you see more behavior like this, please let us know at hn@ycombinator.com.
- steveklabnik 10y ago> It's days are numbered Bugs happen, and they will happen in Rust too. Please file https://www.rust-lang.org/security.html https://www.rust-lang.org/security.html so we can get a CVE if you find one. > as are yours. Not sure what that means, exactly.
- lacampbell 10y ago...and? Is it faster? Is it shorter? Has it fixed bugs? Does it have more functionality? What reason does a user or potential user of this library have to care that it's now written in another language?
- steveklabnik 10y agoThere is already a top-level comment asking this question, with a few replies https://news.ycombinator.com/item?id=13351066 https://news.ycombinator.com/item?id=13351066
- lacampbell 10y agoMy job right now is working on a C# codebase. I'd love to re-write everything in F#. I feel like it's higher level, less prone to error, and would make the codebase much smaller. The thing is - no one is going to be impressed if they hear it's been re-written in F# because I assume doing so is going to make the software easier to maintain, easier to extend and more reliable. Not management, not users, no-one. Now, if I did the re-write and LOC went down by half, or performance improved, or it fixed a lot of bugs, or I was able to add features in much more quickly because abstractions were tighter and easier to create and the compiler was able to check more constraints for me - then people might take notice. There is, however, no inherent value in the source language being changed in itself.
- steveklabnik 10y agoThat's what makes blog posts like this tricky: this post is one for the project itself, which means that its audience is already for people who know what the project is, etc. Someone posted it on HN, and it got upvotes, so it gets to a broader audience, who may not inherently know these kinds of things, or not care. So your point here is valid, that is, "as someone _not_ in that audience, why should I care?" That's what the other thread, with its replies, is getting at. Which is why I pointed to you to it. It's possible as well, of course, that maybe that _still_ means this doesn't matter to you. Which is also expected; nobody is going to like every thread on HN. That's why the guidelines[1] have the section of "Please don't submit comments complaining that a submission is inappropriate for the site." And it gives you something to do instead: " If you think a story is spam or off-topic, flag it by clicking on its 'flag' link." And beyond that, you could just skip this thread and read any of the other 29 posts on the front page. That's how I usually handle posts that I don't have any particular interest in. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- perturbation 10y agoA bit OT, but is there a C API that Piston exports? I.e., could I use Piston from C/C++ (or another language that supports the C ABI)?
- steveklabnik 10y agoI don't believe so; Piston's goals are to make libraries for use in Rust, rather than trying to use Rust to improve other software, as far as I know. I did a quick look through of it and didn't see anything indicating there was, both in the main umbrella "piston" project as well as "image" in particular.
- nox_ 10y agoThe inflate crate is absolutely devoid of tests and full of unsafe code though, so the foundations of all of that are quite weak.