Live data from Hacker News

2016 Rust Commercial User Survey Results

internals.rust-lang.org

101–110 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#101
post #38
post #31

Earlier quoted context omitted.

You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you! No, no, Python like with clauses, for opening files and such.

RAII (i.e. destructors that automatically run on values when leaving a scope) is what lets one avoid manually freeing Box and Vec, so you want to split the world into "destructor resources" (RAII) and "with resources", maybe with some guidelines for when to choose which. Presumably a data type that contains a "with resource" would itself have to be a "with resource" (or else why bother?). This makes "with"-ness abstr…

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 controls.

There are more fancy ways to improve on this, specially if the language also allows for macros.

So I find a bit sad, that the discussions of with/using/try don't focus on the FP way of doing resource management.

Re: 2016 Rust Commercial User Survey Results

#102
post #26

Earlier quoted context omitted.

> The way the Rust compiler works it isn't possible without specifying various bounds on the traits. That's a feature! It works the same way in every language other than C++ or D that implements generics. I much prefer explicitly typed generics to untyped generics as in C++. Not only are the error messages far more comprehensible, but it lets us avoid having to introduce confusing name resolution rules like ADL. > An…

Well "the same way" is pretty broad. Generics in C++ are too loose and I edited my comment to reflect that I appreciate the explicitness required. That doesn't mean it couldn't be revisited for usability. Also, huzzah for specialization. I'll try that out asap. Thanks for the heads up.

Not for much longer I hope, and we already have concepts in gcc 6.0.

Just wait for C++20 and STLv2, you will also get that explicitness everywhere with concepts.

Re: 2016 Rust Commercial User Survey Results

#103
post #22

Earlier quoted context omitted.

Long time C++ programmer here. I specifically like the immutable-by-default, borrow, and move semantics. I can write safe code without bloating up my source with 'const &', std::move, '&& ...' and the like. The safety issue for me is about the least important thing. Touting it as the big reason to use Rust is a distraction from my point of view.

> The safety issue for me is about the least important thing. For real. Rust is a great language, but for the love of god, all you hear is safety safety safety. I give about 2 out of 10 fs about safety. The worst part of C++? Dependency management. Cargo is sick -- hype that up more!

> The worst part of C++?

The worst part is people using it as if it was C with a C++ compiler.

I lost count the amount of times I had to create a nice C++ wrapper for "C++" libraries that are just a pile of C functions and data structures, due to copy-paste compatibility.

And yes, the respective lack of safety by not making use of C++ improved type system and standard library.

Re: 2016 Rust Commercial User Survey Results

#104

Earlier quoted context omitted.

Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. Also rust has some more modern functionalish constructs like lambadas and pattern matching.

> Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. For those times when you have to use C++, SaferCPlusPlus[1] should help. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

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.

Re: 2016 Rust Commercial User Survey Results

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

Game developers, specially AAA studios, are well known for writing messy code, regardless of the language.

I bet you if UE5 would get rewritten in Rust, it would just look as messy.

Re: 2016 Rust Commercial User Survey Results

#106
post #33

Earlier quoted context omitted.

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &…

Supposedly Swift 4 is introducing an optional borrow-checker. Types can opt-in and you get the same kind of lifetime guarantees and semantics as Rust. If you don't opt-in you get copying for value types and reference counts for reference types. I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely h…

> In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.

Check Modula-2, Oberon, Component Pascal, Modula-3, Eiffel, Ada, Delphi...

It was a mistake to have Java and .NET go JIT only on their first days, instead of AOT/JIT from day one.

They are finally steering the boat in the right direction, but it will take a couple of years, assuming they don't loose focus.

Re: 2016 Rust Commercial User Survey Results

#107

> 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 frontends catch up.

We'll start using it in some new projects but I doubt we'll port critical infrastructure for a few years.

Re: 2016 Rust Commercial User Survey Results

#108
post #101
post #38

Earlier quoted context omitted.

RAII (i.e. destructors that automatically run on values when leaving a scope) is what lets one avoid manually freeing Box and Vec, so you want to split the world into "destructor resources" (RAII) and "with resources", maybe with some guidelines for when to choose which. Presumably a data type that contains a "with resource" would itself have to be a "with resource" (or else why bother?). This makes "with"-ness abstr…

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.

Re: 2016 Rust Commercial User Survey Results

#109
post #97
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…

Panic recovery and panics can be disabled, and often are. Libraries are not supposed to rely on their existence. Thus these are not a form of exceptions ; they can't be used as such.

Their purpose is to recover from panics when embedding Rust in code written in other languages, where you don't want the panic to try and cross the ffi boundary (or to stop applications that should never crash from crashing at the toplevel, or for better reporting before a crash). Many FFI-based applications turn panics into aborts anyway. Firefox does.

The unwind-recovery functionality in Rust is just enough to get you these useful features if you need them (zero cost if you don't; turn them into aborts), without needing a full on exception system. The reason Rust avoids an exception system isn't the cost of unwinding, it's because it considers exceptions to be an inferior pattern compared to return value based / monadic error handling.

Rust doesn't have a mailing list anymore. I haven't seen much annoyance with panic recovery. There used to be some with panics in general because in the past they couldn't be turned off or recovered from without a new thread, but this has been addressed for ages with panic=abort and recovery. What the hell are you talking about?

Re: 2016 Rust Commercial User Survey Results

#110
post #104

Earlier quoted context omitted.

> Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. For those times when you have to use C++, SaferCPlusPlus[1] should help. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

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 easiest way to do that is probably by enabling the llvm/gcc sanitizers when compiling. But unfortunately that is often not a practical solution for several reasons[1], not least of which is the performance penalty.

So the more practical solution may be to use SaferCPlusPlus to replace (in a straight-forward but not quite automated manner) all the potentially dangerous C/C++ data types (pointers, arrays, etc.) with safe, fast compatible direct substitutes. Thereby salvaging existing code bases.

Wrt preventing the use of C/C++'s unsafe data types in new code, currently SaferCPlusPlus does not provide any mechanism for such enforcement. But you could imagine the effort required to implement such an enforcement mechanism might be small compared to rewriting some large code bases in, say, Rust. And in the mean time, even existing C++ static analyzers seem to be getting better at flagging potentially unsafe code.

[1] http://duneroadrunner.github.io/SaferCPlusPlus/#safercpluspl...

Post reply on HN