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

Rust in 2018: easier to use

jvns.ca

Post reply on HN
Print view View original

231–240 of 305 posts

Re: Rust in 2018: easier to use

#231

Post by steveklabnik »

littlestymaar wrote: post #118
red75prime wrote: post #7

Earlier quoted context omitted.

Read the books, write code. When you'll encounter lifetimes, it's good to remember that lifetime annotations are descriptive and not prescriptive. You can't change lifetime of a variable by adding lifetime annotations. For example, local variables of a function get destroyed on function exit no matter what and you can't prevent it by adding lifetime annotation to a local variable reference you are trying to return. T…

You summarized it so well ! It was also a huge source of confusion for me in the beginning. Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?

While it doesn't have this literal text, it already does have the equivalent: https://doc.rust-lang.org/book/second-edition/ch10-03-lifeti...

> Lifetime annotations don’t change how long any of the references involved live. In the same way that functions can accept any type when the signature specifies a generic type parameter, functions can accept references with any lifetime when the signature specifies a generic lifetime parameter. What lifetime annotations do is relate the lifetimes of multiple references to each other.

Re: Rust in 2018: easier to use

#233

Post by grayrest »

lobster_johnson wrote: post #220
bjz_ wrote: post #156

Earlier quoted context omitted.

> [1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not. I'd prefer a systems-y, zero-cost take on algebraic effects, similar to what OCaml is going to get. Could be much more extensible, and open things up to annotating whether functions panic or not,…

Is there a paper or writeup anywhere on what the algebraic effects system coming to OCaml is going to be like? (Does it have a name that can be googled?)

It's part of the Multicore OCaml [1] effort.

[1] https://github.com/ocamllabs/ocaml-multicore/wiki

Re: Rust in 2018: easier to use

#234

Post by steveklabnik »

TillE wrote: post #219
cesarb wrote: post #172

Earlier quoted context omitted.

Yeah, people with C++ experience have an advantage when learning Rust, since they're used to these concepts, and the Rust compiler enforces things they already know to be careful with (like not mutating a container while there's a live iterator to it). On the other hand, Rust lacks some things C++ has like being generic over values instead of just over types, so for instance implementing a trait for every fixed-size…

As someone who's extremely comfortable with C++, I've tried Rust multiple times but keep bouncing off. Ultimately my problem is just that it doesn't have enough exciting features to lure me away, especially with C++ improving every few years. Compiler-enforced safety and a built-in package manager are really nice, but it doesn't quite make up for the loss of a lot of handy C++ features.

Which features do you miss the most?

Re: Rust in 2018: easier to use

#235

Post by [deleted] »

pimeys wrote: post #217
Thaxll wrote: post #182

Earlier quoted context omitted.

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

I don't buy this claim. I've written many services with Rust and I'm not slower with it that I am with GC'd languages I also need in my work, such as Clojure, Scala or Python. Please explain me where is this idea of slow development time coming from? Is it only because people try Rust for two weeks, cannot get the lifetimes and decide the development speed is slow?

[deleted]

Re: Rust in 2018: easier to use

#237

Post by weberc2 »

pjmlp wrote: post #90
continuational wrote: post #52

Earlier quoted context omitted.

Many languages handle this internally; essentially all functional languages and all dynamically typed languages.

And many others handle this externally, including some functional languages, in case you want a list, I can provide it.

I'm interested in functional languages with a C/C++-like distinction between values and pointers!

Re: Rust in 2018: easier to use

#238

Post by duneroadrunner »

raverbashing wrote: post #160
civility wrote: post #86

Earlier quoted context omitted.

Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.

Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.

C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: Rust in 2018: easier to use

#239

Post by andendau »

Nelkins wrote: post #192
yen223 wrote: post #12

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.

F# sounds like it fits the bill. ADT, pattern matching, performant, great tooling (multiple amazing IDEs, a REPL, etc.), and a huge ecosystem of software packages to use with it (all of .NET). It's my favorite general purpose programming language (can be used for frontend programming, server, mobile apps, etc.).

F# has hit a huge sweet spot for me in productivity, strong typing, inferred typing, multi-paradigm and syntactic sugar. The tooling just gets better and better. I struggle to think of a language that's so well rounded.

Re: Rust in 2018: easier to use

#240

Post by pjmlp »

foldr wrote: post #229
pjmlp wrote: post #141

Earlier quoted context omitted.

No, I am just stating that the goals of having the language designed for such target audience, can have that as side effect. Just like it happened with Java.

Your responses to K0nserv and singhrac suggested that you were defending the claim that golang was "designed for" outsourcing. If you're making the weaker claim that Go's design "can" have the effect of triggering outsourcing, then that's speculative and consequently rather difficult to refute. But you haven't provided a single piece of evidence that this has actually occurred, so far as I can see.

I was making the claim that can be a side effect of its design and the way the community is against common features in modern languages, deemed too complex.

Lets see how it looks a few years from now, given that it is becoming a mainstream language thanks to Docker and K8s adoption.

Post reply on HN