- "I'm an intermediate programmer" - "I'm writing a profiler" - "I wrote a mini-OS" - "I had a talk at RustConf" Other than that, it's really good to see Rust improving.
Intermediate Rust user. Obviously she excels at coding.
Rust in 2018: easier to use
271–280 of 305 posts
Re: Rust in 2018: easier to use
#272Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…
Looks like we found the javatarian! I had to look up on Wikipedia when Rust was conceived: 2010. It took me another moment to realize that it's already been 8 years. We should be flying in spaceships programmed with Rust by now. This is ridiculous.
It was changing on a near-daily basis until May of 2015. It was extremely hard to build big projects in it until that point.
Re: Rust in 2018: easier to use
#273Earlier quoted context omitted.
If Arc counts, then it juste sounds like Rust actually ;).
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).
Re: Rust in 2018: easier to use
#274Earlier quoted context omitted.
Panics are recoverable though
They’re not guaranteed to be, so you can’t rely on it. You can say that you do, but then you may cut yourself off from the rest of the ecosystem. Libraries generally can’t rely on either behavior, applications choose.
And that's why I think the Rust has a worst-of-both-worlds error handling strategy.
Re: Rust in 2018: easier to use
#275Earlier 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…
> 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, but we're quite close to finishing that. Is there a viable cross platform ui option for f# on core?
Check out https://github.com/AvaloniaUI/Avalonia
Re: Rust in 2018: easier to use
#276Earlier quoted context omitted.
I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]` before `panic_fmt` should fix it. [0] https://github.com/rust-lang/rust/issues/38281
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.
Re: Rust in 2018: easier to use
#277This 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.
rust at one point had garbage-collected references. And there's still Rc/Arc types for reference counting. I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?
Not all that familiar with Rust's history or anything but why would he leave to work on Swift at Apple? He creates a language which is getting a huge amount momentum and praise around it, and decides to do something else? Must have been a lot more money, because a situation like that don't come up very often.
Re: Rust in 2018: easier to use
#278Earlier quoted context omitted.
I am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !
The main problem of Scala is that it brings in the whole JVM. That's awesome for certain kinds of apps, but not so great for other things like small tools. I have high hopes on scala-native, though!
Java 9 / Jigsaw should make small self-contained executables possible. Startup time could be an issue, though.
Re: Rust in 2018: easier to use
#279Earlier quoted context omitted.
This sounds like Swift :) (ARC, not tracing GC, but still.)
If Arc counts, then it juste sounds like Rust actually ;).
ARC, not Arc.
ARC is automatic reference counting. Arc is Atomic reference counting.
In Rust you still have to manually .clone() to addref an Arc. In swift you don't. This is a major difference ergonomics-wise.
Re: Rust in 2018: easier to use
#280This 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.
[deleted]