Earlier quoted context omitted.
Small note: Swift's ARC and Rust's Arc are different: Rust's Arc is atomic reference counting, while Swift's is automatic reference counting.
The acronyms are different, but at runtime they're pretty much the same: the only difference is the Swift compiler inserts the clones that a Rust programmer has to do manually (that is, Swift retain/releases are atomic too).
Rust in 2018: easier to use
291–300 of 305 posts
Re: Rust in 2018: easier to use
#292Earlier quoted context omitted.
See also https://doc.rust-lang.org/nightly/unstable-book/language-fea...
Even specifying `eh_unwind_resume` as a lang item gives me a linking error in debug builds.
If this happens to be open source, I can take a look at it.
Re: Rust in 2018: easier to use
#293Re: Rust in 2018: easier to use
#294Earlier quoted context omitted.
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 l…
Cool. I haven't read the second version of the book, and I read the first version about two years ago I think. Glad to see this difficulty is now covered. Carry on with the great job Steve :)
Thanks :)
Re: Rust in 2018: easier to use
#295Earlier quoted context omitted.
The thing is, the choice isn't between Rust and JavaScript, rather between Rust and a list of other languages. Having a GC means having easier ergonomics to write data structures and distributed algorithms. I do like a lot Rust's type system, just the ergonimcs aren't quite there yet.
> just the ergonimcs aren't quite there yet You're correct, but "Rust isn't easy to use for purpose X just yet" is substantially different from "Rust is inherently unfit for X"
Re: Rust in 2018: easier to use
#296Earlier quoted context omitted.
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
#297Earlier quoted context omitted.
(I work on F# at MS) Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support…
I was looking at Brahma.FSharp and something else with type providers, both with Nu Get instructions, and I didn’t see how to get it working with VS Code.
Re: Rust in 2018: easier to use
#298Earlier quoted context omitted.
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.
Couldn't agree more. My only wish is more people would use it.
[1] - ziglang.orgRe: Rust in 2018: easier to use
#299This 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.
Re: Rust in 2018: easier to use
#300Earlier quoted context omitted.
Even specifying `eh_unwind_resume` as a lang item gives me a linking error in debug builds.
Did you define them exactly the same way? Every aspect has to be identical; extern, no mangle, function name, arguments, lang item. If this happens to be open source, I can take a look at it.
I'm using rustc 1.25.0-nightly on Ubuntu 17.10
https://gist.github.com/jefftime/d7e96461138b5aa6895550b63ca...