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

Four Years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

111–120 of 203 posts

Re: Four Years of Rust

#111

Post by pimeys »

steveklabnik wrote: post #14
alexeldeib wrote: post #12

Earlier quoted context omitted.

I'm interested in Rust and have dabbled but don't follow the community too closely. Why do you say later this year, specifically?

It's not 100% for sure, but it's 99% for sure that async/await will be stable in August. The decision to stabilize is being made in seven days, and if it's decided, it will take that long to make it into its first stable release.

We have the whole team waiting for this to land. We're probably going with nightly already due to the problems fitting Futures 0.1 model to our codebase.

Very nice to hear.

Re: Four Years of Rust

#112

Post by pjmlp »

dpc_pw wrote: post #104
pornel wrote: post #76

Earlier quoted context omitted.

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient]( https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... ). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any impera…

Because having a GC doesn't mean throwing away deterministic destruction.

Many GC enabled system languages do offer both mechanisms.

It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.

Re: Four Years of Rust

#113

Post by pjmlp »

pornel wrote: post #80
thrower123 wrote: post #33

Earlier quoted context omitted.

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

D excluded itself from being C/C++ killer by having a GC. I know they've backtracked on that, and the -betterC subset of D looks interesting, but it's a bit late for that.

Only to the GC hating crowd.

Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

Re: Four Years of Rust

#114

Post by est31 »

wtetzner wrote: post #102
est31 wrote: post #89

Earlier quoted context omitted.

> > However, I think Rust has moved too fast in the language department. ... I'd like the language to stabilize a bit and work on what is currently there > This is actually the major theme of this year! https://blog.rust-lang.org/2019/04/23/roadmap.html Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one…

> Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one year where that change is executed doesn't give you a stable language. Doesn't C++ have exactly this problem? It keeps adding new features, which change the language idioms. It actually seems much worse than Rust in this area, as Rust is mostly re-enfo…

The C++ approach of adding new idioms by making the language fatter is of course not as nice as the Rust approach of having breaking changes and disallowing the old idioms.

But then again, the people behind Rust have made usage of the try! macro harder for a questionably useful keyword that could have been named differently as well. And now it's part of the 2018 edition and you need two more characters to use the try! macro even though there are still cases where it's much better than ? and nothing is being done about it.

Re: Four Years of Rust

#115

Post by wyatwerp »

njepa wrote: post #108
dpc_pw wrote: post #104

Earlier quoted context omitted.

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient]( https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... ). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any impera…

I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.

In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io ).

Re: Four Years of Rust

#116

Post by weberc2 »

msvan wrote: post #86
wtetzner wrote: post #81

Earlier quoted context omitted.

I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project. The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at le…

Esy ( https://esy.sh/ ) has completely solved the first problem, fwiw.

This is a huge step in making OCaml more approachable. I get the feeling that there are quite a few of these modernizations around, but you have to know about them up front in order to hit the happy path. Would be great if there was some sort of "OCaml Happy Path" repo that laid out all of the right tools to use to be successful right off the bat. Sort of on the subject, Reason would be great but last I checked it utterly neglected its native compilation story--it advertised native compilation but every time I ran into an issue the Reason community would tell me that OCaml support was broken and I should use Node. Excited for the improvements to be sure!

Re: Four Years of Rust

#117

Post by weberc2 »

eikenberry wrote: post #82
weberc2 wrote: post #17

Earlier quoted context omitted.

I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Rust, but I rarely can afford to trade off on Go's productivity for Rust's performance and safety.

From the looks of things you'll probably get the Go you want first. The only thing missing from the roadmap are enums and there are a few Go2 proposals for them.

Maybe, albeit I'm concerned that the Go team might ship some broken version of generics or enums that we'll be stuck with for years and years. I think that would be strictly worse than no generics or enums. I hope they think holistically about the problem.

Re: Four Years of Rust

#118

Post by p0nce »

xvilka wrote: post #63
Hermitian909 wrote: post #34

Earlier quoted context omitted.

As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what…

Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).

You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.

Re: Four Years of Rust

#119

Post by DblPlusUngood »

davemp wrote: post #75
sriram_malhar wrote: post #59

Earlier quoted context omitted.

You speak of low latency code and doubly linked lists in the same breath. Personally, I have moved from linked data structures to more cache friendly data structures, which means contiguous spaces. No jumping around. It's very liberating.

Doubly linked lists are used all over for low level programming. For low access, large dynamic data they're a pretty good solution AFAIK.

You are absolutely right. They are used everywhere in the Linux, OpenBSD, and FreeBSD kernels, and likely many other kernels.

Replacing large linked lists with arrays is rarely an actual win. With an array, insertion and deletion become far more expensive, virtual memory is more likely to become fragmented or grow monotonically, and the cache misses avoided are almost certainly irrelevant to total performance.

Re: Four Years of Rust

#120

Post by p0nce »

leshow wrote: post #53
msvan wrote: post #11

I wonder how many Rust users really want linear types and borrow checking, instead of the other stuff Rust brings to the table: modern language design, large and friendly community, nice type system, native compilation, good package ecosystem. Personally I would prefer a well-designed GC'd language with a strong type system and native compilation over Rust, unless I was doing something with specific demands on parall…

That's what I love about Rust, you get all of those things without having to sacrifice performance. i.e. I get a modern language, get to write code at a relatively high level, and still don't even have to use a GC. You learn to love the borrow checker, it's an amazing tool to work with.

Having a GC doesn't "sacrifice performance" in itself
Post reply on HN