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

111–120 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#111

Post by steveklabnik »

alfalfasprout wrote: post #107
gravypod wrote: post #59

> We received a resounding response to continue investing in building strong IDE tools. IDE tools in a commercial setting help teams coordinate their efforts by making it easier to navigate unfamiliar code, on-board new users, and streamline the development process. I cannot wait. I cannot wait until this happens. Rust will become my main language.

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.

Re: 2016 Rust Commercial User Survey Results

#112

Post by pjmlp »

duneroadrunner wrote: post #110
pjmlp wrote: post #104

Earlier quoted context omitted.

How does it help to make everyone on the team play ball to not use C style coding or the quality of third party libraries? If the answer is code review, it will never work.

I can certainly appreciate the sentiment that one of the most valuable features a language can have is the ability to make your co-workers write better code :) And it's hard to compete with Rust in that sense. That is, if you're starting a brand new project. But in other circumstances, another valuable feature would be to be able to make your co-workers' (and predecessors') existing code retroactively safer. The easi…

The main reason I only have fun using C++ on private projects, while using JVM and .NET languages at work is exactly the way most people use the language on the enterprise.

The majority of C++ programmers I meet at enterprise projects don't even know what is CppCon.

Re: 2016 Rust Commercial User Survey Results

#113

Post by pjmlp »

dbaupp wrote: post #108
pjmlp wrote: post #101

Earlier quoted context omitted.

Not necessarily. On languages that support currying, or leaving the last parameter out of the call if it is a lambda, you can create high-order-functions for resource management. The effort is no different than implementing RAII classes. withDBConnection { r = db.execute ("SELECT....") } Here the function withDBConnection calls the lambda, providing it an implicit parameter for the db connection, which it fully contr…

That has both of the problems I mentioned even if it isn't a full language level construct.

I fail to see how.

The resources are only available via the lambda parameters, so the wrapper function controls the lifetime, arena style.

Last expression in the block is the return value.

Re: 2016 Rust Commercial User Survey Results

#114

Post by gravypod »

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.

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.

Re: 2016 Rust Commercial User Survey Results

#115

Post by dman »

shadowmint wrote: post #69
sdegutis wrote: post #3

Earlier quoted context omitted.

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 certainl…

People havent had enough time to write huge messy codebases in Rust. Irrespective of language, I suspect that people hate reading source code and would much prefer to write code rather than read code. Ten years from now, I am hoping that Rust becomes the defacto systems language, but I strongly suspect that people will have similarly bad things to say about large Rust codebases then as they do about C++ codebases now.

Re: 2016 Rust Commercial User Survey Results

#116

Post by dbaupp »

pjmlp wrote: post #113
dbaupp wrote: post #108

Earlier quoted context omitted.

That has both of the problems I mentioned even if it isn't a full language level construct.

I fail to see how. The resources are only available via the lambda parameters, so the wrapper function controls the lifetime, arena style. Last expression in the block is the return value.

The wrapper function controlling the lifetime is exactly why that scheme has both of the problems I mentioned.

It all comes down to: how do you write a fn connection() -> DB? You can't (or, at least, it doesn't make sense to) return the parameter from withDBConnection: the whole point is the wrapper function does the clean-up when it is done, invalidating the connection object. The only way to pass the value along is to have `connection` also take a closure, i.e. manual continuation passing style/node.js's "closure-hell". This can, in some cases, be addressed with async/await style sugar, but there's still semantic (mainly around composition) and performance issues with it.

Anyways, going back to the data type: if one has a type Foo with a constructor like fn create() -> Foo, and Foo is updated to contain a database connection, that constructor no longer works, and needs to also be converted to use CPS. That is, the interface of the Foo object has be infected by "private" details, meaning needs to to preemptively decide whether there is any chance of each datatype needing to hold one of these CPS objects.

(Of course, the code you suggest works fine in Rust now, and is even used for certain special cases, but that is very different to baking it into the language as a whole new syntactic construct.)

Re: 2016 Rust Commercial User Survey Results

#117

Post by pcwalton »

Animats wrote: post #97
papaf wrote: post #36

Earlier quoted context omitted.

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…

Rust now has not just "panic", but "panic::recover", with unwinding. That's an exception system. It's just one with weak syntax and semantics. Go went down this route, too. In the beginning, Go errors were fatal. Then the Go crowd added "recover". With unwinding. Both languages now have the heavy machinery for exceptions without full language support for them. The discussions of this on Rust mailing lists show much u…

Panics can be turned into aborts, and a lot of Rust apps do this. It is therefore poor practice, and unfriendly to your users, to publish a library that relies on unwinding. No popular library I know of relies on it.

Re: 2016 Rust Commercial User Survey Results

#118

Post by vardump »

Retra wrote: post #52
dreta wrote: post #29

Earlier quoted context omitted.

The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no. I never said that const is like anything, i just used it as an example.

What does malloc have to do with anything? Returning a pointer to the stack is just as likely to break everything if done improperly. Moving or copying a struct that points at itself is also going to break. In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things…

>Returning a pointer to the stack is just as likely to break everything if done improperly.

How's returning a pointer to stack ever safe?

Re: 2016 Rust Commercial User Survey Results

#119

Post by Animats »

burntsushi wrote: post #100
papaf wrote: post #99

Earlier quoted context omitted.

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 --…

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.

Re: 2016 Rust Commercial User Survey Results

#120

Post by mindcrime »

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.

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.
Post reply on HN