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

61–70 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#61

Post by dbaupp »

dreta wrote: post #57
dbaupp wrote: post #55

Earlier quoted context omitted.

I don't think this is a useful point, because by the same logic: - Haskell doesn't eliminate memory safety issues, they happen when using unsafePerformIO (or Foreign.*Ptr, or inside the runtime, your choice), - Python doesn't eliminate memory safety issues, they happen when using ctypes, - JavaScript doesn't eliminate memory safety issues, they happen when calling into the C++ code of the browser, - Java doesn't elim…

I never said i expect Rust to fix any of these problems, i would however expect it to at least try and introduce helpful constructs, instead of the ultimatum approach that every other language takes where you either program as expected or face the consequences.

It does provide a pile of helpful constructs (references, slices, generics, privacy), which, if they don't work 100%, are still brilliant building blocks for creating abstractions that expose safe interfaces, allowing the areas where "program as expected" is required to be concentrated into controlled areas/libraries. (And, all those features still work in the unsafe code, helping the programmer get it correct.)

It works really well in practice, even if it isn't bulletproof... there's nothing to stop a programmer typing 'unsafe' to side-step the safe interfaces in random places, but one quickly learns this is usually just heaping unnecessary debugger work on oneself, to track down little mistakes that the compiler would normally point to directly.

Re: 2016 Rust Commercial User Survey Results

#62

Post by sidlls »

Retra wrote: post #47
sidlls wrote: post #17

Earlier quoted context omitted.

Rust's generics have significant limitations, especially when mixing types, and are cumbersome to use. For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting…

The num crate is an open problem. There's a lot of contention around what it is supposed to support. Mathematicians, scientists, HPC programmers, prototyping programmers, embedded system programmers, pointer-arithmetic-doing programmers... they all want something different from a number crate. That's why it is not in the std library: there's no agreement on what it should do, and iterating toward perfection in the st…

You make an excellent point. I fall into more than one of the buckets you list, and it's definitely the case that there is unlikely a "one size fits all" solution here. However I just have this sense that there is an intersection of basic functionality for using "number types" that neither Rust nor the num crate really supports terribly well. Maybe I'll change my mind as I use it to build out some projects.

Re: 2016 Rust Commercial User Survey Results

#63

Post by dbaupp »

dreta wrote: post #60
dbaupp wrote: post #53

Earlier quoted context omitted.

As I said, a slice can point to any memory, it doesn't matter where it came from: i.e. your allocator/things using it can expose slices instead of just plain pointers. Generics and privacy are definitely language features, and they're core to the ease with which one can create abstractions. Rust is a systems language, it tries to give programmers the power to create their own safe abstractions as needed.

I wasn't talking about that. What i meant was, if i have to implement it myself, that's not a point in favor of Rust. Though the slice does help with rudimentary bounds checking, so that's a start, though i don't see how that differs from a generic accessor method or an overloaded operator.

A programming language can't anticipate every possible thing someone might want to do (or else every program would be one line: doMyThing()), the best it can do is provide tools for building the final product. Rust is pushing hard on making it easy for people to build safe, zero-cost abstractions that are reusable, via generics and especially cargo, so you often don't have to implement things yourself (or: don't have to implement things yourself twice), even if it isn't literally in the language.

> though i don't see how that differs from a generic accessor method or an overloaded operator

Err, it does all the bounds checking automatically? I thought you wanted these features without having to implement them yourself, but apparently writing accessor methods or an overloaded operator is OK too?!?

Re: 2016 Rust Commercial User Survey Results

#64

Post by Manishearth »

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"

Re: 2016 Rust Commercial User Survey Results

#65

Post by nnethercote »

dreta wrote: post #51
dbaupp wrote: post #46

Earlier quoted context omitted.

What's a specific memory safety issue Rust has outside `unsafe` code?

The memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.

Some people say "half a hole is still a hole". To which I reply "but it's a much smaller hole".

Re: 2016 Rust Commercial User Survey Results

#66

Post by sidlls »

Manishearth wrote: post #56
dreta wrote: post #37

Earlier quoted context omitted.

My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.

Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.

> nor does it claim to be.

"It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it.

Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.

Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.

Re: 2016 Rust Commercial User Survey Results

#67

Post by olauzon »

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.

Similar story here. Been using Rust in production for only a couple of weeks for a financial analytics pipeline processing billions of events per day and TBs of data, but absolutely no issues so far. The predictable performance of Rust has been wonderful to observe, compared to GC'ed languages this iteration of the pipeline has replaced (JVM, Go). The type system makes otherwise daring refactorings a joy.

Re: 2016 Rust Commercial User Survey Results

#68

Post by steveklabnik »

papaf wrote: post #36
Animats wrote: post #13

From the article: "...fourteen companies responded to our outreach" That's not a survey, that's a focus group. I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection. But there's a lot about Rust that's unnecessarily weird. - The type system is unusual, and complex. It's hard to do anything without templates. - The template libraries are heavily biased towards clo…

The hacks needed to avoid the need for exceptions are uglier than exceptions. I felt like this when I read the scary documentation: https://doc.rust-lang.org/book/error-handling.html However, in the total 4 hours or so that I have been programming in rust the way of handling errors seems very sensible. - Match expressions instead of "if (error) dosomething()" - Match expressions with destructuring gives the error mes…

The next iteration of the book will have a much more cut-down version of this; this chapter is _so_ thorough, but also gives you the impression that it's more complex than it has to be due to said thouroughness.

Re: 2016 Rust Commercial User Survey Results

#69

Post by shadowmint »

sdegutis wrote: post #3
the_duke wrote: post #2

Great to see Rust gaining a foothold in commercial areas. While by no means a perfect language, I enjoy it much more than writing C++.

Why do you specifically enjoy it more than C++? As far as I know, the main goal of Rust is to be safer than C++, not more enjoyable to write.

It is though.

I don't know about 'main goal' but rust is fun to write. Far more than c++ for me.

Compile times. Traits. Generics that aren't templates. A package manager. Functional constructs. Cross platform. It's got all the shiny toys.

The state of the art in C++ is what? One file drop in headers, no package management and STL hell? Have you read the UE4 engine code base? What are horrific mess.

There are certainly problems with rust (imo tooling and libraries), but I don't think for a moment how enjoyable to write it is, is one of them...

C++ is a bloated language and I hate writing code in it. I hate that the mix of C++14/11/?? You get is different is every project. I despise that my C++ code from QT, UE, win32 is virtually incompatible, and the header/code legacy divide (or not if you happen to be in a system that allows it).

I guess your milage may vary, but I've not talked to many people who didn't like programming in rust... Mostly just people who found it hard, or didn't know why they would bother vs. their current 'good enough' language (eg. C#).

Re: 2016 Rust Commercial User Survey Results

#70

Post by cm3 »

This wasn't one of the question of the survey, but while having the right crowd around, I have to ask.

When will Rust get

1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation

2. support for naturally writing recursive functions

Post reply on HN