Rust and Go • Hacker News Board

Re: Rust and Go

#211

Post by gokr » Sat, Nov 08, 2014, 2:18 PM UTC

dbaupp wrote: post #192

gokr wrote: post #187

Earlier quoted context omitted.

Regarding the parts where I link to out of date docs: 1. I will fix it later today/tomorrow, busy right now 2. I did actually search quite a bit, but that was what I as an outsider found. Consider this an "issue" to fix :) I think the issue was that the words I was searching for are not the words used to describe these mechanisms. Anyway, if you can give me a proper link to the canonical place where error/exception h…

Re 2. as my comment states, we have tried to fix it, but we cannot: the administrator of that server is powerless. Error handling is mainly via types, mainly `Result`: http://doc.rust-lang.org/nightly/std/result/ . That part of your article will need changing because it is completely different to the condition system (that is, just swapping the link would be useless). Also, it's a little unfortunate that you entirely…

What I meant with "issue to fix" - add a section in the documentation that has some kind of words that outsiders connect with "error handling": Error, Exception etc

Perhaps I didn't search hard enough - but the next person will probably not search harder either. "Result" is not typically a word one would search for.

Re: Rust and Go

#212

Post by gokr » Sat, Nov 08, 2014, 2:22 PM UTC

dbaupp wrote: post #192

gokr wrote: post #187

Earlier quoted context omitted.

Regarding the parts where I link to out of date docs: 1. I will fix it later today/tomorrow, busy right now 2. I did actually search quite a bit, but that was what I as an outsider found. Consider this an "issue" to fix :) I think the issue was that the words I was searching for are not the words used to describe these mechanisms. Anyway, if you can give me a proper link to the canonical place where error/exception h…

Re 2. as my comment states, we have tried to fix it, but we cannot: the administrator of that server is powerless. Error handling is mainly via types, mainly `Result`: http://doc.rust-lang.org/nightly/std/result/ . That part of your article will need changing because it is completely different to the condition system (that is, just swapping the link would be useless). Also, it's a little unfortunate that you entirely…

Regarding "ignoring the major difference", I explicitly tried to not compare them too much - because I know too little of both. Now I know more about Nim, but not Rust.

Regarding GC, its not fully "required" in Nim either, but yes, the GC is a big differentiator and probably one of the things making someone prefer one over the other.

Re: Rust and Go

#213

Post by gnuvince » Sat, Nov 08, 2014, 2:35 PM UTC

rdtsc wrote: post #125

tptacek wrote: post #76

Earlier quoted context omitted.

Distributed systems programming is its own special concurrency problem, and distributed systems also exhibit deadlock, races, and serialization, no matter what language they're implemented in. I'm not sure what finding a race condition in a distributed commit implementation says about a language; at the very least, it's nothing you couldn't say about Rust as well, which is also not a language that solves distributed…

It is not a black and white situation probably. Golang is better because it has built-in channels and encourages users to take advantage of them. It also has garbage collection. So those 2 things right of the bat help. But there are better things out there -- isolated heaps (Erlang), borrow checkers (Rust), stronger type systems and immutability (Haskell) etc. There are no magic unicorns so those things often come at…

How does Rust's borrow checker cause a slowdown of sequential code? It's a purely compile-time construct and allows for the elimination of a GC, so it's actually a net win in code execution speed.

Re: Rust and Go

#214

Post by pcwalton » Sat, Nov 08, 2014, 2:46 PM UTC

NateDad wrote: post #199

pcwalton wrote: post #86

Earlier quoted context omitted.

let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect(); versus: let mut descending_squares = Vec::new(); let mut i = 4u; loop { descending_squares.push(i * i); if i == 0 { break } i -= 1 } (Note that if you try to use a for loop here you will infinite loop due to unsigned underflow.)

Go is not the language for you if you care about mashing as much logic into a single line as you can. Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. Which is not to say that the declarative isn't nice, just saying that the example of the infinite loop is not exactly compelling.

> Go is not the language for you if you care about mashing as much logic into a single line as you can.

The point here is that iterators can reduce bugs, independent of aesthetic concerns.

> Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never.

I like to give that example because it was something I actually hit and a bug that I actually had to fix.

In fact I just hit that again yesterday when iterating over a list in reverse order (painting order for CSS box-shadow).

Re: Rust and Go

#215

Post by malkia » Sat, Nov 08, 2014, 2:48 PM UTC

NateDad wrote: post #195

rdtsc wrote: post #129

Earlier quoted context omitted.

> show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something. You mean file a bug like "issue #1935 -- stop sharing memory between goroutines" (I just made it up to be silly there is no such bug report) In other words, they have explicitly designed in the ability to share memory between goroutines. You can certainly file an issue or bug report…

If all goroutines deadlock, then the runtime will panic and you'll get stack traces for everything. But yes, you can obviously deadlock one or more goroutines trivially. A simple select{} will just block one goroutine forever, for example. And no, there's no tools currently that will detect deadlocks, AFAIK.

I haven't looked into that (or googled), but how does one detect that everything has deadlocked - is it some kind of profiling/sampling being done, or is it something more system specific? Any pointers? Thanks!

Re: Rust and Go

#216

Post by grey-area » Sat, Nov 08, 2014, 3:05 PM UTC

gruvector wrote: post #179

twtwtaway wrote: post #66

Earlier quoted context omitted.

I also agree with the Go team. Although I am a big fan of functional language constructs like map & filter, adding them to Go does not feel right. One of the great things about Go is that it's simple but it does not hide much from you. You still know exactly what is going on (concurrency& channels being an exception). That's why I find it easy to read Go code.

The go community reminds me of the java community. Blind faith in the design decisions of the language. Any feature it doesn't have is passionately defended as a good decision because the clumsy old way is subjectively clearer, up until the day it gets added.

That sort of behaviour is in no way unique to Go or Java, and I think it's unfair to judge a language or community by some posts from an online newsgroup - most people are too busy to post or lurk on lists like golang-nuts.

Re: Rust and Go

#217

Post by zzzcpan » Sat, Nov 08, 2014, 3:09 PM UTC

pcwalton wrote: post #214

NateDad wrote: post #199

Earlier quoted context omitted.

Go is not the language for you if you care about mashing as much logic into a single line as you can. Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. Which is not to say that the declarative isn't nice, just saying that the example of the infinite loop is not exactly compelling.

> Go is not the language for you if you care about mashing as much logic into a single line as you can. The point here is that iterators can reduce bugs, independent of aesthetic concerns. > Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. I like to give that example because it was something…

  > The point here is that iterators can reduce 
  > bugs, independent of aesthetic concerns.

Iterators can reduce bugs, really? This is a very flawed point. Bugs are not caused by lack of language features, they are caused by people. And people make mistakes independent of language features and sometimes because of language features causing cognitive overload or require them to make assumptions.

Re: Rust and Go

#218

Post by gorhill » Sat, Nov 08, 2014, 3:40 PM UTC

dbaupp wrote: post #140

gorhill wrote: post #120

Earlier quoted context omitted.

> functional style is so much clearer There is something that makes me uncomfortable in there: > let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect(); The overhead. I wonder about it. I am unable to get a sense of what it is. With a simple for-loop, it's rather easy to see it, but with the version above I have no idea. So "much clearer" is not what I see with the piece of code above. I see what it do…

There is not much overhead with Rust iterators at all. They are essentially concrete versions of the deforestation that Haskell can do to avoid constructing intermediate lists, and compile to code that is close to the equivalent C (the functionality is all statically dispatched, so the compiler can inline and optimise the calls). This is a case of having experience with and trusting one's tools. I wrote a blog post a…

I am definitely going to have to look more into Rust.

Re: Rust and Go

#219

Post by Dewie » Sat, Nov 08, 2014, 4:01 PM UTC

zzzcpan wrote: post #217

pcwalton wrote: post #214

Earlier quoted context omitted.

> Go is not the language for you if you care about mashing as much logic into a single line as you can. The point here is that iterators can reduce bugs, independent of aesthetic concerns. > Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. I like to give that example because it was something…

> The point here is that iterators can reduce > bugs, independent of aesthetic concerns. Iterators can reduce bugs, really? This is a very flawed point. Bugs are not caused by lack of language features, they are caused by people. And people make mistakes independent of language features and sometimes because of language features causing cognitive overload or require them to make assumptions.

The way I see it is that you can reduce bugs by increasing the level of abstraction, which in this case means to use things that are more straightforward and less flexible: the ultimate looping-construct is arguably the while-loop, by using a counter to index into the array (if you're working with an array, anyway). But with that flexibility comes more room for error: maybe your increment is wrong, maybe your while-condition is wrong, maybe you inadvertently change the index inside the loop without meaning to, etc. A step over that is to explicitly just say that you want to iterate over each element in the array. You don't get to choose how, but you probably wanted to iterate over it from start to finish anyway. The highest level is a function that encapsulates exactly what you want without having to bother with explicitly iterating over the collection yourself. Now you can't even mess up how you use each member of the array, because that is already handled by the function.

A higher level of abstraction means less flexibility, which means fewer potential things that you can screw up. I don't see how that is a flawed point.

Re: Rust and Go

#220

Post by tspiteri » Sat, Nov 08, 2014, 4:20 PM UTC

pcwalton wrote: post #86

jaekwon wrote: post #32

Earlier quoted context omitted.

I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)

let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect(); versus: let mut descending_squares = Vec::new(); let mut i = 4u; loop { descending_squares.push(i * i); if i == 0 { break } i -= 1 } (Note that if you try to use a for loop here you will infinite loop due to unsigned underflow.)

That's the only place in C where I use the postfix decrement operator.

    for (u = 5; u-- > 0; ) {