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

2016 Rust Commercial User Survey Results

internals.rust-lang.org

Post reply on HN
Print view View original

121–130 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#121

Post by Animats »

pcwalton wrote: post #93
throwmeaway11 wrote: post #88

Earlier quoted context omitted.

You speak as if you're so sure of yourself. Not with opinions but apparently presenting facts. Problem is most of your "facts" are wrong. Thankfully the actual experts are patient enough to explain this. But not a single "Oh, sorry, I was wrong about that." Just silence on the things you were called out on, as if you weren't just called out on them. This is the worst side of this place.

I don't mind criticism of Rust. In fact I often upvote it when I see legitimate criticism turn gray.

My real criticism here is that Rust isn't able to wipe C and C++ off the face of the earth. Rust solves the three big problems which C fails to address - "How big is it", "Who owns it", and "Who locks it". We need that, with the endless CERT advisories of buffer overflows. That's the real issue here - memory safety is a big, big security issue. The threat is getting worse, too. It's nation states now, not script kiddies.

Rust usage is very low. It isn't even in the TIOBE Top 20 for 2016.[1] (In the detailed listings, it's at position 46, just above Awk.) Why is market penetration so low? I'm arguing that there's too much gratuitous new stuff for Rust to be acceptable to the C/C++ community.

[1] http://www.tiobe.com/tiobe-index/

Re: 2016 Rust Commercial User Survey Results

#122

Post by burntsushi »

Animats wrote: post #119
burntsushi wrote: post #100

Earlier quoted context omitted.

Interesting. I couldn't disagree more! Combinators are very handy for error handling in Rust. More than that, combinators (and their limits) are essential to understand in order to motivate `try!`. Indeed, in Rust, matching against a Result type explicitly isn't especially common. Instead, one uses `try!`. `try!` abstracts three things at once: case analysis, error conversion and control flow. The chapter actually go…

"try!" has a built-in, hidden function return. It's only useful if the appropriate error action is to immediately bail out of the function. It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur.

> "try!" has a built-in, hidden function return.

Hence the reason I said that it abstracts control flow.

> It's only useful if the appropriate error action is to immediately bail out of the function.

Which is exceptionally common.

> It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur.

None of this is true, and I do log errors when they occur in Rust programs. (See ripgrep.)

`try!` is a convenience. Since errors are plain old values like anything else, you don't actually need to use it if it doesn't fit.

Re: 2016 Rust Commercial User Survey Results

#123

Post by pcwalton »

Animats wrote: post #121
pcwalton wrote: post #93

Earlier quoted context omitted.

I don't mind criticism of Rust. In fact I often upvote it when I see legitimate criticism turn gray.

My real criticism here is that Rust isn't able to wipe C and C++ off the face of the earth. Rust solves the three big problems which C fails to address - "How big is it", "Who owns it", and "Who locks it". We need that, with the endless CERT advisories of buffer overflows. That's the real issue here - memory safety is a big, big security issue. The threat is getting worse, too. It's nation states now, not script kidd…

I agree that I want Rust usage to grow. I disagree that we made technical mistakes that hamper its growth. You've thrown out dozens of reasons over time, none of which were legitimate. Every time you name some feature of Rust you claim is a "gratuitous new thing", we calmly show you why (a) that feature is already in C++ or (more often) (b) that feature is necessary to make lifetimes/ownership/borrowing work.

I think that the simple fact is that ownership, lifetimes, and borrowing are unfamiliar. They have a learning curve, period. We can't expect a language with them to take over the world in a year. Programming languages are a mature market. Progress will be slow.

Rust is doing far better than 95% of new programming languages after a year. Most programming languages are dead after a year.

Re: 2016 Rust Commercial User Survey Results

#124

Post by carols10cents »

papaf wrote: post #99
burntsushi wrote: post #73

Earlier quoted context omitted.

> introduces non-essential craziness without warning. Like what? (Disclaimer: I originally wrote that chapter as a blog post[1], so I'm curious to hear what I could have cut out. I tried to find things to cut, but given my target audience, I couldn't find anything substantial.) [1] - http://blog.burntsushi.net/rust-error-handling/

First, thanks for taking time to write essential blog posts/documentation. Here would be my suggestions, I hope they are useful: 1. Its about error handling. Options are conceptually similar but they're not error handling. Options can go somewhere else, maybe a previous chapter. 2. From what I understand from my almost zero experience of rust, the match/deconstruct with a Result type will do 99% of error handling --…

I wonder if you'd like the error handling chapter in the new book [1]; it started from a base of burntsushi's blog post but we did rearrange quite a bit. Option is in another chapter now.

[1] - http://rust-lang.github.io/book/ch09-00-error-handling.html

Re: 2016 Rust Commercial User Survey Results

#125

Post by steveklabnik »

mindcrime wrote: post #120
steveklabnik wrote: post #111

Earlier quoted context omitted.

Which IDEs matter to you? We're actively working on it.

Not the poster you were replying to, but Eclipse here. I'd definitely want a great Rust plugin for Eclipse if I were going to invest heavily in Rust.

Cool! http://rustdt.github.io/ exists but I've never used it.

Re: 2016 Rust Commercial User Survey Results

#126

Post by steveklabnik »

gravypod wrote: post #114
steveklabnik wrote: post #111

Earlier quoted context omitted.

Which IDEs matter to you? We're actively working on it.

Eclipse for Java and PyCharm for Python Eclipse has by far the best autocompletion for Java. PyCharm has the best debugger I've ever used or could dream of.

Cool, thanks. I linked to an eclipse plugin in a sibling. I'll check out PyCharm's debugger, I've never used it.

Re: 2016 Rust Commercial User Survey Results

#127

Post by Animats »

pcwalton wrote: post #123
Animats wrote: post #121

Earlier quoted context omitted.

My real criticism here is that Rust isn't able to wipe C and C++ off the face of the earth. Rust solves the three big problems which C fails to address - "How big is it", "Who owns it", and "Who locks it". We need that, with the endless CERT advisories of buffer overflows. That's the real issue here - memory safety is a big, big security issue. The threat is getting worse, too. It's nation states now, not script kidd…

I agree that I want Rust usage to grow. I disagree that we made technical mistakes that hamper its growth. You've thrown out dozens of reasons over time, none of which were legitimate. Every time you name some feature of Rust you claim is a "gratuitous new thing", we calmly show you why (a) that feature is already in C++ or (more often) (b) that feature is necessary to make lifetimes/ownership/borrowing work. I think…

* I disagree that we made technical mistakes that hamper its growth.*

That's not a decision you make. That's a decision your customers make. Time will tell.

Re: 2016 Rust Commercial User Survey Results

#128

Post by bfrog »

Manishearth wrote: post #64
bfrog wrote: post #35

I'm using it commercially, though wasn't asked in the survey. I've had zero crash causing failures in production with a web interfaced analytics pipeline service I wrote. It just sits there, with its 10's of gigabytes of data running day in day out... handling millions of events every day, crunching business vital numbers. Best thing ever.

Are you listed on http://rust-lang.org/friends.html ? If not, might want to let us know using the link at the bottom of the page :) If you are; sorry you weren't included in the survey. I don't think everyone on the friends page was included, it was more of "everyone we know who uses Rust and we have an easy way of contacting over email"

Will try and get that stuff together, gotta ask my graphics guy for a nice SVG logo

Re: 2016 Rust Commercial User Survey Results

#129

Post by indolering »

pcwalton wrote: post #93
throwmeaway11 wrote: post #88

Earlier quoted context omitted.

You speak as if you're so sure of yourself. Not with opinions but apparently presenting facts. Problem is most of your "facts" are wrong. Thankfully the actual experts are patient enough to explain this. But not a single "Oh, sorry, I was wrong about that." Just silence on the things you were called out on, as if you weren't just called out on them. This is the worst side of this place.

I don't mind criticism of Rust. In fact I often upvote it when I see legitimate criticism turn gray.

Thank you for your impeccable responses, it's one of the reasons I love hn.

FWIW, I think a few explainer pieces would help bring about more enlightened discussions. For example, there is a lot of bikeshedding around Rusts' decision to wrap overflows and potential future improvements. But the rationale and interesting technical challenges each alternative brings is scattered across blog posts, forum threads, and Github issue tickets.

1: http://huonw.github.io/blog/2016/04/myths-and-legends-about-...

Re: 2016 Rust Commercial User Survey Results

#130

Post by alfalfasprout »

steveklabnik wrote: post #111
alfalfasprout wrote: post #107

Earlier quoted context omitted.

This is one of the key things preventing us from moving to Rust. Yeah, I love vim but on a very large codebase an IDE just helps you keep everything much more organized and productive. Moreover, moving to Rust would require investing in ports of some large-ish C++ libraries we use. I think Rust is here to stay. It's a great language without a runtime that should be able to match C++ in performance when the compiler f…

Which IDEs matter to you? We're actively working on it.

having a solid IDEA/CLion plugin would be great.
Post reply on HN