News for hackers. Stuff that matters.
Re:Thoughts on replacement languages by pcwalton on Saturday January 10, 2015 @07:30PM (#8868539)
For me, the biggest problem with this essay lies in this one sentence: "Memory safety could qualify as a targeted problem, though historically that’s been a tough sell on its own."

My question is: Who offered memory safety on its own, historically? I think the reason that memory safety has been a tough sell historically is that it always came with performance overhead and lack of low-level control, and people kept using C and C++ for low-level programming as a result. By contrast, Rust tries to go farther than any other industry language in truly providing memory safety on its own—without any of the baggage of JITs, or garbage collection/pervasive reference counting. If you had to sum up the raison d'être for Rust in one sentence, that'd be it.

I think that historically, memory safety "on its own" hasn't been tried, at least to the degree that Rust strives for.

Re:Thoughts on replacement languages by pron on Saturday January 10, 2015 @09:24PM (#8868789)
Not to take away from anything you've said, but in some scenarios, GCs have a lower impact on performance than dynamic allocation (well, if you use dynamic allocation). For one, they provide better throughput -- their overhead is mostly much higher memory usage, and latency (occasional pauses, although "pauseless" collectors -- actually, short pauses of a few milliseconds -- are used in the industry). But their more interesting advantage is in concurrent data structures. Many lock-free data structures (actually, most of the interesting ones) require a GC, or techniques that are less performant, less general, or both, like hazard pointers and user-space RCU.
Re:Thoughts on replacement languages by kyllo on Saturday January 10, 2015 @08:30PM (#8868685)
Yes, a primary stated goal of Rust is "memory safety without garbage collection." I'm not aware of any other language for which this is a top priority.
Re:Thoughts on replacement languages by pcwalton on Saturday January 10, 2015 @08:33PM (#8868690)
It's because it's an extremely delicate balance (considering reference counting a form of GC, which it is): you have to carefully design the entire language around it in order to get the safe expressiveness that Rust provides. It'd be very hard to retrofit onto an existing design and match Rust's expressiveness.
Re:Thoughts on replacement languages by cpeterso on Sunday January 11, 2015 @01:44AM (#8869280)
How does Rust deal with reference cycles?
Re:Thoughts on replacement languages by steveklabnik on Sunday January 11, 2015 @09:24AM (#8870032)
By giving you enough tools that referencing counting isn't what you reach for. If you do need it, though, we use weak and strong pointers.