Live data from Hacker News

Rust in 2018: easier to use

jvns.ca

291–300 of 305 posts

Re: Rust in 2018: easier to use

#291
post #273

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

Yes, I should have elaborated more, thanks :)

Re: Rust in 2018: easier to use

#292

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

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.

Re: Rust in 2018: easier to use

#293
post #43

Earlier quoted context omitted.

Just out of curiosity, how many web framework platform are originally written and compiled in C? CPython, udev, node, v8, ... rust?

IIRC, the rust compiler started out as an OCaml project, but is now self-hosting.

This is true.

Re: Rust in 2018: easier to use

#294

Earlier 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 :)

Ah ha! Yeah, it's quite different.

Thanks :)

Re: Rust in 2018: easier to use

#295
post #264
post #173

Earlier 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"

[deleted]

Re: Rust in 2018: easier to use

#296

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

Couldn't agree more. My only wish is more people would use it.

Re: Rust in 2018: easier to use

#297

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

Ah, yes, this is using Code Quotations to generate code into OpenCL. Useful, but unfortunately, not something that is likely to work on .NET Core for a number of reasons today.

Re: Rust in 2018: easier to use

#298
post #296

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

My wish too! I have no issues with F# on Windows or Linux using .NET Core I use F# as my general high-level language and Zig as my C replacement/Rust alternative for low-level work. I can gradually re-write C stuff in Zig, and be productive.

  [1] - ziglang.org

Re: Rust in 2018: easier to use

#299
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.

Scala Native may sort of fit the bill

Re: Rust in 2018: easier to use

#300

Earlier 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 just whipped this up yesterday to test if I was still having the same issues. Debug fails to build with a linking error "undefined reference to `_Unwind_Resume`". Release build works fine.

I'm using rustc 1.25.0-nightly on Ubuntu 17.10

https://gist.github.com/jefftime/d7e96461138b5aa6895550b63ca...

Post reply on HN