Fearless concurrency with Rust • Hacker News Board

Re: Fearless concurrency with Rust

#151

Post by ngrilly » Sat, Apr 11, 2015, 12:37 PM UTC

pcwalton wrote: post #34

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…

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> Thanks to the module system, the Rust compiler never rereads a file more than once.

Are you sure about this? When you use a generic function accepting and/or returning values of type T, I guess the compiler has to generate a version of the function for each instance of T. But the compiler cannot know all the possible use of the generic function without having walked through the whole code first, which implies at least two passes. How does it work?

Re: Fearless concurrency with Rust

#152

Post by alextgordon » Sat, Apr 11, 2015, 12:46 PM UTC

aikah wrote: post #150

dietrichepp wrote: post #80

Earlier quoted context omitted.

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,…

Rust has something that Go does not: Servo.

If Rust had been missing an important feature like generics, the Servo people would have been telling the compiler people "you're being silly, of course we need generics!". And because Servo is the official test-case project for Rust, the compiler people would have listened.

Go has nothing like this. There's no formal effort to ensure practicality.

Re: Fearless concurrency with Rust

#153

Post by dbaupp » Sat, Apr 11, 2015, 12:47 PM UTC

ngrilly wrote: post #151

pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> Thanks to the module system, the Rust compiler never rereads a file more than once. Are you sure about this? When you use a generic function accepting and/or returning values of type T, I guess the compiler has to generate a version of the function for each instance of T. But the compiler cannot know all the possible use of the generic function without having walked through the whole code first, which implies at le…

The compiler reads the source code into an internal AST and manipulates that, never touching the external files again.

Re: Fearless concurrency with Rust

#154

Post by ch » Sat, Apr 11, 2015, 12:49 PM UTC

zzzcpan wrote: post #121

nostrademons wrote: post #116

Earlier quoted context omitted.

Meta-comment: I believe the difference in opinion here (which seems to recur, over and over, and has for decades) is because the job title of "software engineer" actually encompasses many different job duties. For some engineers, their job is to "make it work"; they do not care about the thousand cases where their code is buggy, they care about the one case where it solves a customer's problem that couldn't previousl…

My point was: tools that prevent you from doing things should not do that without explicit permission. Because thinking is hard and any interruption by a tool or a compiler will impose unnecessary cognitive load and will make it even harder, which may lead to a logical mistake. It is much better to deal with the compiler after all the thinking is done, not during.

Yes but tools that you from doing thing you would prefer not to have done in the furst place (but still grant you permission to override this when desired) would be a fairer assessment of what a sting compiler is.

We all agree that a null dereference is a bad thing at runtime. I see no advantage for me as a programmer to be allowed to introduce null dereferences into my code as a side effect of "getting things to work" if then when the code runs it doesn't work right. This increases my cognitive load as a programmer, it does not decrease it.

I would argue that you don't think about the compiler anymore when using a language like haskell than you do when using Python. But you do get more assurances about your program after ghc produces a binary than after Python has finished creating a .pyc -- and that is a win for the programmer.

Re: Fearless concurrency with Rust

#155

Post by [deleted] » Sat, Apr 11, 2015, 1:19 PM UTC

threeseed wrote: post #141

kjksf wrote: post #134

Earlier quoted context omitted.

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.

[deleted]

Re: Fearless concurrency with Rust

#156

Post by aikah » Sat, Apr 11, 2015, 1:45 PM UTC

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…

> Go because it's a good language.

Go fits a niche and is good enough, for now. But Go as a language is seriously flawed, and its flaws will become more and more obvious as the language gets more popular. People can certainly understand Go made the choice of "minimalism". But minimalism doesn't mean the language shouldn't have features people really need. The infamous "You don't need that in Go" sentence will not fly that much longer,especially given how the Go team and community tries to answer Go short comings. The biggest insult to intelligence is that "go generate" feature.It's just embarrassing.

Go for me is a missed opportunity. I still like it but I keep a close eye on alternatives that don't have their core library riddled with "interface{}" like types.

Because there is a need for something simpler and safer than C,that is easily accessible to "script kiddies",that is fast,that has easy concurrency, that compiles to machine code,that has type safety,that isn't tied to windows, in order for people to produce executables that can easily be distributed or concurrent servers.

Whatever language succeeds in that niche will be the biggest language of the next 10/20 years. Mark my words.

Re: Fearless concurrency with Rust

#157

Post by zzzcpan » Sat, Apr 11, 2015, 2:04 PM UTC

aikah wrote: post #156

kjksf wrote: post #134

Earlier quoted context omitted.

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…

> Go because it's a good language. Go fits a niche and is good enough, for now. But Go as a language is seriously flawed, and its flaws will become more and more obvious as the language gets more popular. People can certainly understand Go made the choice of "minimalism". But minimalism doesn't mean the language shouldn't have features people really need. The infamous "You don't need that in Go" sentence will not fly…

> that has type safety

Actually, there is no need for that. Type safety has nothing to do with software being more reliable or more secure. There is, however, a need in language creators, who understand that large standard library with static binaries and cross compilation are super important in a fast moving world where many different operating systems live together on many different architectures.

Re: Fearless concurrency with Rust

#158

Post by ngrilly » Sat, Apr 11, 2015, 2:20 PM UTC

dbaupp wrote: post #153

ngrilly wrote: post #151

Earlier quoted context omitted.

> Thanks to the module system, the Rust compiler never rereads a file more than once. Are you sure about this? When you use a generic function accepting and/or returning values of type T, I guess the compiler has to generate a version of the function for each instance of T. But the compiler cannot know all the possible use of the generic function without having walked through the whole code first, which implies at le…

The compiler reads the source code into an internal AST and manipulates that, never touching the external files again.

Ok, you're right, but we're playing with words here :) I understand the file containing the source code of the generic function is read only once, but I guess the AST of the generic function is processed many times, at least once for each instantiation of the function? And I'd venture in guessing that the biggest cost is in processing the AST and compiling it, not in reading/parsing the source?

Re: Fearless concurrency with Rust

#159

Post by proveanegative » Sat, Apr 11, 2015, 3:55 PM UTC

alextgordon wrote: post #152

aikah wrote: post #150

Earlier quoted context omitted.

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,…

Rust has something that Go does not: Servo. If Rust had been missing an important feature like generics, the Servo people would have been telling the compiler people "you're being silly, of course we need generics!" . And because Servo is the official test-case project for Rust, the compiler people would have listened. Go has nothing like this. There's no formal effort to ensure practicality.

Surely some internal Google projects were developed alongside Go in the language.

Re: Fearless concurrency with Rust

#160

Post by alextgordon » Sat, Apr 11, 2015, 4:11 PM UTC

proveanegative wrote: post #159

alextgordon wrote: post #152

Earlier quoted context omitted.

Rust has something that Go does not: Servo. If Rust had been missing an important feature like generics, the Servo people would have been telling the compiler people "you're being silly, of course we need generics!" . And because Servo is the official test-case project for Rust, the compiler people would have listened. Go has nothing like this. There's no formal effort to ensure practicality.

Surely some internal Google projects were developed alongside Go in the language.

It's not about whether someone is using the language, but about whether the language designers decide to listen to a user above themselves.

It's hard to design a language. Everybody is always trying to give their conflicting opinions. Many language designers react by turning inwards and ignoring everybody else.