Hacker News new | comments | show | ask | jobs | submit login

I've been using Rust more and more for my personal projects. Frankly, I could not give a hoot about the memory management; it's pretty cumbersome to deal with. What I love about Rust is that it's a low overhead language that uses interfaces. I love interfaces! I honestly think that they're the best way to program.

I'm glad you like it :) I'm happy to see more emphasis on the productivity-related aspects of Rust. I talk about memory safety a lot because people ask questions like "what one feature makes you different from C++11?", but the productivity-boosting features like traits and Cargo are just as important in my mind.

The importance of Cargo / crates.io cannot be understated, I think.

I've found myself using Rust for little one-off tools and scripts lately because it's so darn easy to type `$ cargo new --bin foobar` on any of the three operating systems I use daily.

There's already a pretty nice ecosystem of web servers, graphics libraries, crypto libraries, etc. -- Not to mention the bindings to existing libs.

At the end of the day I always end up with wicked fast binaries that I can run on Windows, Mac, or Linux with fairly minimal fuss.


I really haven't found a language that hits this niche the way Rust does, which is really strange to me considering Rust's mission statement.

No shell scripting language is that easily portable barring something like MinGW.

I've never had what I'd call a pleasant experience using Ruby, Python, or Javascript on Windows. Not to mention if the language runtimes / stdlibs don't demand it: many of the 3rd party libraries assume a *nix toolchain to build all the C extensions.

Go and Java probably come the closest to writing easily portable software, but I personally find writing Rust to be a more fulfilling endeavor.


The other day I wrote a tool to deduplicate my image library in Rust. The first binary to compile worked perfectly on both Mac OS and Windows, ran wicked fast (on my SSDs anyways), and it was really a pleasure to write. -- Rust's iterators alone really make for some beautiful code.


This was a really long-winded way of saying I love Rust, and thanks for all the hard work ^^,

I had somewhat of a similar experience setting up a build.rs for a crate.

I wanted to do some pre-build command execution/file moving/etc and was shocked at how little fuss was actually involved.

More work than bash/python? Sure. Worked first time barring logic bugs? Hell yes.

Also +1 on Rust iterators, they're a sublime mix of ownership semantics and functional constructs.

I've actually found python3 to be surprisingly pleasant on windows (10), while go has been just ok. I think it is mostly a culture thing: python has a long history of cross-platform, and I think the odds are better that some utility written in/ported to python3 will use the various facilities python provides for "just working" cross platform. It also helps that python3 made virtualenvs part of the standard library.

With go, I think it's easier to accidentally end up with some kind of not-quite-portable thing, despite the fact that go is a new language.

Interesting (and good!) that you have such a pleasant experience with Rust too.

> The other day I wrote a tool to deduplicate my image library in Rust.

Hm, did you by any chance share that somewhere? I'm planning to do some reinstalls and consolidation of storage, partly from having several machines, and partially from dual-booting (having extra file-systems). I'll probably figure it out with find and xargs or what-not, but a Rust-binary would be a welcome change of pace :-)

> No shell scripting language is that easily portable barring something like MinGW.

> I've never had what I'd call a pleasant experience using Ruby, Python, or Javascript on Windows.

Perl is probably the tool you are looking for. There are official technet articles about how to use Perl on Windows. Older, now that powershell exists, but they're there.

If you're already familiar with Ruby I imagine it's not too hard to pick up most most of what you would want to know (except context! Probably the most important thing in Perl to grasp coming from other languages).

Out of curiosity, what methods did you use for image dedupes? Simple file hash, or something more complex to find e.g. watermark vs no, different crops/scales, etc.?

At the moment it is just hash based, which actually remedied most of my immediate problem. (I have 8 drives in my workstation. Many of them are donors from computers long gone. [Portions of] my image library have just been copied around many times without much rhyme or reason. Now it's centralized and properly backed up.)

I did think about comparing images by similarity but ultimately tabled it for a later evening because:

- I quickly realized I had a lot of reading to do

- Resolving "similar images" conflicts is a fuzzier, more time intensive process since: (a) maybe the comparison is just plain wrong?, (b) maybe it's not strictly a worse crop, but rather two common aspect ratios which you'd like to keep, (c) maybe it's not actually "watermark" text but rather it's a meme or image macro, etc.

- Personally: my real problem with images of varying sizes is that I download thumbnails by mistake. That's just PEBKAC and no amount of software can fix that.

(Now that I think about it: it might be nice to have a script which iterates over low resolution images and tries to find a large resolution version w/ Google Image Search.)

This has been one of the biggest things I've enjoyed about it as well! Building cross-platform applications is generally a nightmare. In C++ you have to figure out a build system and dependencies on your own, and also you're writing C++ which is terrible. In scripting languages you either have to require users to install the runtime or you have to use packaging tools that are of variable quality. Being able to write cross-platform code with sane package management and compile down to native binaries takes away a huge headache!

Also, the ability to add template specifiers to implementations is probably the most powerful restricted generic programming technique I've seen. For example, it fills me with joy to be able write lines like this:

    // Colliders are bi-directional
    impl<T, K> Collider<T> for K where T: Collider<K> {
       fn intersect(&self, other: &T) -> Option(Contact) {

As a professional C++ developer, this makes me jealous ;) Waiting for Concepts has become a Duke Nukem meme.

What do you mean by that? Is it different than what you can do in C++ with inheritance (leaving out implementation inheritance)? I'm sure it is probably a little less verbose as the syntax in C++ is odd. C++ 11 adds 'override' which helps.

No, it is not. Pure virtual classes are the same as interfaces. But I only use pure virtual functions, so why mix in non-pure virtual classes?

One difference is that you can implement a new trait for someone else's type.

Aka why Rust is FP gateway drug :P.

Don't think I agree. Rust compromises between FP and OO, and I think it's awesome for it. You get the best of both worlds.

I don't want just FP, personally I find it too restrictive.

Ok ok, the actual truth is that there is no such thing as "functional languages". Rust is a good demonstration that languages that offer the ability to statically prevent bullshit are the best---and does so with a familiar syntax, familiar mutation, etc so as not to trip people's buttons.

There is no such thing as OO either, and trait objects are not super common in idiomatic Rust anyways.

I would say that it compromises between ML/Haskell-style FP and procedural. It doesn't have much to do with OO, bar trait objects, and the dot operator (which is almost entirely syntactic sugar).

It's a gateway drug to ML/Haskell-style FP because it eases you into expressive type systems, pattern matching, higher order functions, and pervasive use expressions over statements. Many people have told me that it was much easier to learn Haskell or Ocaml, etc. after learning Rust.

Ah, you beat me to it :).

Yeah, there's "FP" and there's "FP-style," and having FP-style usually gets you 80% of the way to what you want.

All I ask of a language (other things are nice but not required) is no "runtime type errors" and no data races. Haskell, Rust, OCaml give me these things.

[Slightly more formally, the first can be rephrased as "no omnipresent non-obvious partiality excluding that from non-termination".]

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact