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

Rust means never having to close a socket

blog.skylight.io

Post reply on HN
Print view View original

141–150 of 165 posts

Re: Rust means never having to close a socket

#141

Post by kibwen »

shadowmint wrote: post #134
dbaupp wrote: post #130

Earlier quoted context omitted.

> The misconception is that if you're using rust you're safe from the bugs that other programmers may have made... which is not true. Of course it's not true, but the libraries you're using will (hopefully, for the most part) be written in Rust, which increases the level of trust. > There's a trust chain involved; if you depend on a library you trust it's bug free and won't delete your harddisk and crash your program…

> It is nonsense to say that "libraries can have bugs so you might as well use C++". My argument is that if you assert 'rust is 100% safe' then you must assert, all your dependencies are bug free. If you can somehow magically assert 'all my code is bug free', that would be great... but if so, you wouldn't need the borrow checker at all would you? (I'm certainly not endorsing using C++ :P I'm specifically talking to t…

  > 'rust is magical and can never crash' turns up in blog 
  > posts a lot
The next time that you see someone doing this, please correct them. Misinformation does none of us any favors.

Re: Rust means never having to close a socket

#142

Post by dbaupp »

shadowmint wrote: post #140
dbaupp wrote: post #129

Earlier quoted context omitted.

> No it's not. > What's happening is some of the run time overhead is being reduced. I believe wycats was responding specifically to > Rust uses 'drop flags', which are extra bytes at the end of struct instances in memroy , to track objects and keep meta information about them to determine if they should be dropped. And these are being eliminated. That is the drop flag will be entirely separate to the struct instance…

Whatever, there are still drop flags (on the stack instead, sure), and still dynamic runtime checks for drops. The points I was making is that 'zero cost' memory management isn't 100% zero cost. The drop checker does incur some basic dynamic runtime costs. To be 'zero cost' drop behaviour would be determined at compile time.

The behaviour is determined at compile time, with runtime cost only introduced if it is absolutely needed (when one branch drops, and another doesn't), and, even then, it can be avoided, by manually forcing a drop of the value in every branch.

Re: Rust means never having to close a socket

#143

Post by hrjet »

ben0x539 wrote: post #44
hrjet wrote: post #30

Earlier quoted context omitted.

Curious to know why `drop` isn't called automatically by the compiler as soon as possible (since the type system already seems to know it is safe). Is there a trade-off involved here?

One reason is probably emulating the way RAII works in C++, and allowing "low level" code to use idioms like { let _lock = acquire_lock(); use_resource(); } // lock is released here, whether use_resource() returned or caused stack unwinding

Makes a lot of sense: reduces generated code duplication. Just needs one "release" block per scope.

Re: Rust means never having to close a socket

#144

Post by Roboprog »

phunge wrote: post #63
wycats wrote: post #27

Earlier quoted context omitted.

What happens if there's a cycle? It will get closed when the cycle is finally collected. You can rely on a GC (and refcounting + a cycle collector is absolutely a GC) to finalize your resources for you, but it is quite difficult to reason about when the file will eventually be closed. Also, the reference counting semantics of CPython are implementation-specific. From the PEP that introduced `with`: > Note that we're…

Props to Rust for tackling this head on, more languages should provide resource allocation that's deterministic, predictable and syntactically convenient. CPython's behavior is nice, but it seems to me it came about by accident. Big heavy resources use refcounting because everything uses refcounting. Plus, if CPython had true concurrency, across-the-board refcounting probably wouldn't have lasted nearly as long (reas…

Re: threads uber ref-counting.

Hit one of my hot-buttons: Threads have got to be one of the most massive WOMBAT boondoggles of the last few decades.

Pro) none of this slow inter-process-communication stuff!

Con) EVERYTHING is now dangerous. (not quite, but close)

But the industry (?) decided "TOTALLY worth it!"

I forgot to mention that threads start a little faster than processes (well, quite a bit faster on a particular shitty OS in widespread use), but not so much faster that you won't need to pool and re-use the threads anyway. I think this is one area where Erlang (actor pattern), for instance, gets it right: pretend tasks run in their own process, and use an IPC proxy to send messages between the tasks/sub-programs, even if implemented with threads instead of OS level processes.

Re: Rust means never having to close a socket

#145

Post by pjmlp »

chetanahuja wrote: post #113
kibwen wrote: post #85

Earlier quoted context omitted.

I agree that refcounting is a great and usable compromise in this space, but your own comment flirts with why I don't think modern languages are chomping at the bit to base resource management on it: concurrency. Granted, I have no idea how much overhead is imposed by atomic operations vs. a stop-the-world or concurrent GC (if anyone has some data, I'd love to see it!). But given how it's become de rigeur for new lan…

"Granted, I have no idea how much overhead is imposed by atomic operations vs. a stop-the-world or concurrent GC." An atomic read/write/increment/decrement is a non-blocking (from the point of the view of a user code running on the CPU) CPU operation. The CAS operations required to do atomic inc/dec are relatively expensive compared to normal memory read/writes of course but nowhere near the scale of stop-the-world G…

That is an implementation issue.

There are plenty of JVMs to choose from, even pauseless ones.

Re: Rust means never having to close a socket

#146

Post by eddyb »

wycats wrote: post #72
krig wrote: post #68

Earlier quoted context omitted.

It sounds like they are talking about a semi-space collector, which I can imagine might in theory be faster than scoped allocation since allocation is a simple pointer bump (just like stack allocation) but when garbage collecting you only have to traverse the live set. However, semi-space collectors can't collect non-memory resources without additional metadata, and they have a memory overhead of at least 2x the maxi…

In Rust, you often use stack allocation, which, as you pointed out, is much more efficient. There's some heap allocation in Rust, but in my experience it's actually a minority of all allocations. Rust also has an Arena library ( http://doc.rust-lang.org/0.11.0/arena/index.html ), which can be used for cases where you know that you have enough memory for a given operation and are willing to throw out the entire thing…

That link is outdated, see http://doc.rust-lang.org/arena/.

Re: Rust means never having to close a socket

#147

Post by walrus »

kolev wrote: post #137

I love Rust, but really can't use it at work until it has a fully-featured AWS API. I had similar issues trying to use D and Dart in the past. Go doesn't have an official SDK either and although goamz isn't complete, the situation there is much better.

You could start writing it.

Re: Rust means never having to close a socket

#148

Post by bsaul »

steveklabnik wrote: post #91
mwcampbell wrote: post #81

Earlier quoted context omitted.

I know Rust has RC pointers. But I'm guessing a Rust programmer would still have to understand ownership and borrowing, since the standard library and third-party libraries use those concepts. I think what I'd really like is something like C# and the .NET base class library, but AOT compiled to native code and using automatic reference counting, with some way to indicate weak references. I know that neither GC nor re…

That's true, you can't totally avoid knowing about these things. But if you don't want to think about them in your code, and are okay with the price, you can. It sounds like Swift may be close to what you want, yeah?

It looks to me that swift is the only language that can compete with rust if it were open sourced, or at least available for general purpose usage.

Anyone familiar to swift internals here to say whether server-side swift is at least theorically feasible ?

Re: Rust means never having to close a socket

#149

Post by akavel »

shadowmint wrote: post #127
wycats wrote: post #122

Earlier quoted context omitted.

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a…

I'm not arguing any of these points. I'm just saying there are these two misconceptions: - if you write safe rust code, your code can't segfault This isn't true if your code path contains any unsafe code. - Rust code can't segfault This isn't true at all . Sure, if it does segfault its a bug in the c code / unsafe code. You're absolutely correct. ...but bugs aren't deliberate. Obviously no one is going to deliberatel…

I don't understand -1s to the parent post; it's important to remember and be aware of limitations and dangerous areas in a language (or any other tool). And shadowmint tries to describe them in very civilized and calmly assertive way. I find his posts, as well as the counterarguments (like those from pcwalton and wycats), massively educative and informative. I absolutely can't understand why someone would like to see them fade out and disappear. I see the thread as exactly a kind of educated, professional argument that is so valuable on HN. And in such, being partially wrong or incorrect in some aspect is not something "bad" and "requiring censorship", but rather opportunity for straightening by others with a side effect of educating the larger community, isn't it?

Re: Rust means never having to close a socket

#150

Post by kolev »

walrus wrote: post #147
kolev wrote: post #137

I love Rust, but really can't use it at work until it has a fully-featured AWS API. I had similar issues trying to use D and Dart in the past. Go doesn't have an official SDK either and although goamz isn't complete, the situation there is much better.

You could start writing it.

Maybe in a parallel universe where I have time for these kind of things... It shouldn't be too hard to reverse-engineer botocore, use the these JSONs here [1], and generate code based on them.

[1] https://github.com/boto/botocore/tree/develop/services

Post reply on HN