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

Fearless concurrency with Rust

blog.rust-lang.org

Post reply on HN
Print view View original

141–150 of 186 posts

Re: Fearless concurrency with Rust

#141

Post by threeseed »

kjksf wrote: post #134
Pxtl wrote: post #129

Earlier quoted context omitted.

Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.

This meme really should die. It has never been true so there's nothing to forget. The number of full-time Rust people paid by Mozilla is roughly the same as number of Go people paid by Google. Mozilla is a wealthy company and while Google is even more wealthy, it doesn't mean that it spends all its money on Go. Both v8 and Dart are staffed with more people and Dart is not taking off the way Go is. People are trying t…

But it's true. Google's association is a big factor in its success. It's not the only reason nor likely the biggest now but it was important at least at the beginning. The fact is that every week we hear about new programming languages. Almost none of them end up being widely used.

Having someone like Google, Mozilla, Apple, Microsoft etc behind it makes a big difference.

Re: Fearless concurrency with Rust

#142

Post by arielby »

cwzwarich wrote: post #9
steveklabnik wrote: post #7

Earlier quoted context omitted.

We may end up adding linear types, not just affine, to Rust as well: https://github.com/rust-lang/rfcs/issues/814

From the RFC you linked: "First, the `linear` attribute as described here does not create true `linear` types: when unwinding past a `linear` type, the `linear` attribute will be ignored, and a `Finalize` trait could be invoked. Supporting unwinding means that Rust's linear types would in effect still be affine."

Rust always has unwinding, and the finalizer can just call `abort` to make this as linear as you can.

Re: Fearless concurrency with Rust

#143

Post by [deleted] »

cwzwarich wrote: post #9
steveklabnik wrote: post #7

Earlier quoted context omitted.

We may end up adding linear types, not just affine, to Rust as well: https://github.com/rust-lang/rfcs/issues/814

From the RFC you linked: "First, the `linear` attribute as described here does not create true `linear` types: when unwinding past a `linear` type, the `linear` attribute will be ignored, and a `Finalize` trait could be invoked. Supporting unwinding means that Rust's linear types would in effect still be affine."

[deleted]

Re: Fearless concurrency with Rust

#144

Post by unfamiliar »

I'd just like to say that I found the tone of this article so much better than all of the other rust guides I have looked at. It managed to be interesting without being annoyingly cute or overly dry or explaining basic concepts which any programmer will know. It makes me want to go back and have another look at the language because it presents the ideas and upsides in such a pleasant manner. Well done.

Re: Fearless concurrency with Rust

#147

Post by eternalban »

copsarebastards wrote: post #72
chimeracoder wrote: post #29

Earlier quoted context omitted.

First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. > Go code often passes references over channels, which results in shared memory between two threads with no locking Having a complex type system would cut into compile t…

> Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. Oh give this lame argument a rest already. They're both supposedly general-purpose programming languages. Rust shoots for a little lower level than Go, but they can certainly be compared, and the comparisons are valid. > Having a complex type system would cut into compile times (an explicit…

Compile time + Go toolchain add-ons (generate ..) ..

Re: Fearless concurrency with Rust

#148

Post by divs1210 »

divs1210 wrote: post #96

Can someone please write a Clojury lisp that compiles to Rust without immutability (by default) and concurrency primitives, since thread safety is guaranteed by the rust compiler? I love Clojure, but this would be a completely different beast, a crazed DRAGON probably. PS: I want a Dragon

Forgot to say: No GC!

Re: Fearless concurrency with Rust

#149

Post by Supermighty »

vanderZwan wrote: post #139
peterfirefly wrote: post #137

Earlier quoted context omitted.

The biggest factor probably was that Rob Pike had basically been prototyping the language for 20 years. (But google's name certainly helped.)

Not to take anything away from your comment on this being a language that has been brewing for years, but people really should give Robert Griesemer more credit for his influence on the language design. I know he's the least publically visible of the three, but IIRC godoc and gofmt are mostly his babies. After getting used to those I think I miss them more in other languages than I miss the concurrency.

Well said.

Rob Pike is explicit about early Go development; everything that went into Go was agreed upon by Robert, Ken, and Rob. If all three didn't agree it didn't go in.

Re: Fearless concurrency with Rust

#150

Post by aikah »

dietrichepp wrote: post #80
copsarebastards wrote: post #73

Earlier quoted context omitted.

> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Well-understood like code generators (go generate)? Were generics not well-understood enough, so they decided to go with something that's well-understood to be a poor solution to the problem?

Actually, now that you mention it, I think generics are poorly understood in general. C++, Java, and C# have major differences in their approach to generics, but they have similar syntax so most people gloss over the differences. I think doing generics well requires incorporating higher order types, higher kinded types, and other concepts which don't exist at all in the wild west of C++ templates. This clumsy impleme…

You know. As Go get more popular, people will have a critical look at the language and its short comings.That's inevitable.

If the only answer to the issue they raise is "you don't need that in Go", "Use go generate" or "Go isn't for you", Go is going to get a lot of bad rap that will stop the adoption of the language.

If the Go team thinks the language doesn't need generics they are either out of touch(their rights,they don't know owe us anything) or arrogant. Either way, Go will not be the successful language it could have been.

One should never have to resort to interface{} to code anything in Go. Developers want type safety, not write type assertions everywhere. The fact that 1/ Go has generics but you cant create yours(map/slices/arrays) 2/ the core lib is full of these interface{} functions proves the language has a big problem.

Post reply on HN