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

71–80 of 203 posts

Re: Four Years of Rust

#71

Post by pcwalton »

bitwalker wrote: post #66
amelius wrote: post #45

Earlier quoted context omitted.

What do you mean by: > Its (thread-local) memory heap is GC'd by default. What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

The typical approach here as far as I'm aware is to use a deallocation queue - frees of an object that was allocated on another thread are freed by putting that object in the original thread's deallocation queue. When that thread gets an opportunity, it frees everything in its deallocation queue to reclaim that memory.

Manually, or automatically?

Re: Four Years of Rust

#72

Post by pcwalton »

jnordwick wrote: post #41

I really want to like Rust, and I've made a few attempts in the past to get involved - I wrote a database driver for a time series database (KDB) in pure Rust among a few other things. I've even done a couple deep dives into rustc to figure out the cause of some iterator slowness (it wasn't giving proper hinting in the LLVM IM). However, I keep having to step back. And in this short time Rust has progressed a lot (an…

Well, async I/O is important to get early. Otherwise we're going to have an entire ecosystem of synchronous networking code, and there's no going back from that. You can look at languages like Ruby for what happens if you don't get an async I/O story before the package ecosystem develops.

Re: Four Years of Rust

#73

Post by foldr »

estebank wrote: post #70
foldr wrote: post #61

Earlier quoted context omitted.

Doubly linked lists are perhaps not the best example, but there are lots of practical data structures that aren't compatible with the single ownership restriction. It's possible to implement them in safe Rust using various techniques, but it's not ideal. Then there is the fact that mutation makes things even harder. So for example, you can easily implement a tree using Box to hold pointers to child nodes, but you'll…

And that should be fine . unsafe is not something to be forbidden, it is a marker for "here-be-dragons, as the compiler can't check that all invariants are correct when you dereference a raw pointer or modify a mutable static variable". In reality I've found the need for unsafe to be minimal, either when doing something that is actually forbidden for good reason or interacting with C libraries.

Yes, the OP said explicitly that he decided to use unsafe to deal with these cases.

>I decided this time I should just ignore all the dislike of `unsafe` and just use it as much as I need to. I think I was making life more difficult on myself by trying to avoid it so much, but when you have a lot of pointers that have multiple refereces between then, you kind of have to. Doulble linked and mutually linked structures - where any pointer chance can lead to a mutation - are Rust's achillies heel.

Sriram_malhar pointed out that doubly linked lists are usually not a good data structure to use anyway. I was pointing out that there are lots of more useful data structures that raise similar issues in Rust.

I don't think that using unsafe is "fine", necessarily. It is much better to implement a data structure on top of safe Rust if at all possible.

Re: Four Years of Rust

#74

Post by amelius »

UnpossibleJim wrote: post #47
yawn wrote: post #22

Earlier quoted context omitted.

This is exactly how I feel. I'd be all about Rust if it was GC'd. Go is close enough that it's what I reach for for personal projects, but not having ADTs and pattern matching is super frustrating for modeling data.

Not to be the nay sayer here, but garbage collection kind of goes against the premise of Rust, as stated by the mission statement. I'm a fan of Rust, but I also like Python, but they are different tools for different problems. Go seems like the tool for your specific problems. I'm not trying to be offensive towards you, or anything, but Rusts mission statement was written pretty clearly and the reasons against a garb…

If this is true then Rust is the wrong tool for many projects in which it is currently used. Most of those projects are not an OS or driver and are far from the metal.

Even the compiler itself would not fit your description.

Re: Four Years of Rust

#75

Post by davemp »

sriram_malhar wrote: post #59
jnordwick wrote: post #41

I really want to like Rust, and I've made a few attempts in the past to get involved - I wrote a database driver for a time series database (KDB) in pure Rust among a few other things. I've even done a couple deep dives into rustc to figure out the cause of some iterator slowness (it wasn't giving proper hinting in the LLVM IM). However, I keep having to step back. And in this short time Rust has progressed a lot (an…

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.

Re: Four Years of Rust

#76

Post by pornel »

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…

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-like level of control, performance and low-level compatibility there are very few alternatives, and if you want non-crash-prone parallelism on top of that, there's nothing but Rust.

Re: Four Years of Rust

#77

Post by wyatwerp »

amelius wrote: post #45
wyatwerp wrote: post #24

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

What do you mean by: > Its (thread-local) memory heap is GC'd by default. What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

Do you mean "thread local passed to another thread by mistake"? There is an option to make data global instead. Unless it is a Unix pipeline kind of design, independent threads can populate their working set (from file/socket/whatever) into thread-local memory.

It depends on whether shared-memory is a design requirement or an implementation artifact (Erlang does just fine with a largely shared-nothing model).

It also depends on whether a program runs for a short time, or for a long time. If you are running for a short time, why not just avoid the GC entirely; "manage" memory manually by malloc-ing and never free-ing (free-ing too takes time, and doesn't make memory available to other processes anyway).

Re: Four Years of Rust

#78

Post by lostmsu »

ummonk wrote: post #68
UnpossibleJim wrote: post #47

Earlier quoted context omitted.

Not to be the nay sayer here, but garbage collection kind of goes against the premise of Rust, as stated by the mission statement. I'm a fan of Rust, but I also like Python, but they are different tools for different problems. Go seems like the tool for your specific problems. I'm not trying to be offensive towards you, or anything, but Rusts mission statement was written pretty clearly and the reasons against a garb…

You're missing the point. Go is not the tool for their specific problems because it's a crappy language that lacks generics, algebraic data types, etc. In contrast, a language very much like Rust, but with GC, would be the right tool for their problems.

How about Scala?

Re: Four Years of Rust

#79

Post by [deleted] »

the_mitsuhiko wrote: post #55
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…

> 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. I think there are probably more users that would love this but they are not users of the language to begin with. The community that actually forms around Rust is the type of…

[deleted]

Re: Four Years of Rust

#80

Post by pornel »

thrower123 wrote: post #33
wyatwerp wrote: post #24

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

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.
Post reply on HN