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

Rust and Go

medium.com

Post reply on HN
Print view View original

81–90 of 311 posts

Re: Rust and Go

#81

Post by burntsushi »

Ygg2 wrote: post #57
burntsushi wrote: post #13

> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs

Yeah, that whole part got the me the wrong way. Docopt is as far as I know the best. Also rust comes with a simpler getopt. It is broken now, but with the collection reform landing, what isn't broken.

It was only broken because I merged a PR that updated it to Rust master before the nightly was updated on Travis. :-)

It's passing now that Travis updated to the new nightly.

(But yup, it was collection reform.)

Re: Rust and Go

#82

Post by dragonwriter »

bsaul wrote: post #77
steveklabnik wrote: post #70

Earlier quoted context omitted.

Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.

Ok. I'm not a language designer so correct if i'm wrong, but doing anything remotely looking like actors implies being able to do m:n threading in some way, which rust decided not to do recently. Correct ?

Not really. You can do actor model with 1:N or 1:1 threading. With 1:N you get actor-model concurrency without native-thread overhead per actor, but no parallelism; with 1:1 you get parallelism but you have native thread overhead for each actor. With M:N, you can limit your native thread overhead to whatever is useful given available hardware, while scaling out to as many actors as you need.

OTOH, M:N and 1:N both require you to do more to handle actors in the runtime, which potentially adds overhead to everything, M:N may not always be a win compared to 1:1.

Re: Rust and Go

#83

Post by threeseed »

tptacek wrote: post #54
Animats wrote: post #23

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…

Like you†, I've had the pleasure of working with some fairly large concurrent codebases and the character-building experience of tracking down deadlocks, random memory corruption bugs that turn out to be race conditions, and (my most favorite of all) unexpected serializations that randomly bring programs to a halt. Most of that experience has been in C++, with a little C and a little Java mixed in there. Over & over…

How can you compare the ridiculous amount of Python libraries/code out there (with varying degrees of quality as you would expect from a friendlier language) with Go ? Of course you would find Golang code to be more reliable. The libraries you're relying on are by comparison quite primitive and missing many years of technical debt.

Re: Rust and Go

#84

Post by jacques_chester »

jaekwon wrote: post #32
alkonaut wrote: post #25

Earlier quoted context omitted.

I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.

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. :)

Semantically, loops impose order, maps do not.

A map can be auto-parallelised.

A loop cannot.

It seems to me that for a language aimed at exploiting concurrent features, easy wins for parallelisation would be a feature.

Re: Rust and Go

#85

Post by steveklabnik »

bsaul wrote: post #77
steveklabnik wrote: post #70

Earlier quoted context omitted.

Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.

Ok. I'm not a language designer so correct if i'm wrong, but doing anything remotely looking like actors implies being able to do m:n threading in some way, which rust decided not to do recently. Correct ?

I am not clear that "Actors" directly implies M:N threading. Rust's spawn() makes a 1:1 thread, but you still talk between threads with channels, and you can't get shared memory without going through an Arc> or something similar.

> which rust decided not to do recently.

It's more subtle than this. Rust's I/O libraries are being re-done to remove the M:N stuff, yes, but Rust is low enough that I/O is just a library; anyone can implement alternate I/O stuff, it's not privileged other than coming with Rust. See mio as an example of an in-progress alternative.

Re: Rust and Go

#86

Post by pcwalton »

jaekwon wrote: post #32
alkonaut wrote: post #25

Earlier quoted context omitted.

I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.

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.)

Re: Rust and Go

#87

Post by jaekwon »

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.)

Well this is how I'd write it in Go:

  descending_squares := []uint{}
  for x:=4; 0

Re: Rust and Go

#88

Post by threeseed »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

>(2) large yet maintainable systems

I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of developers.

Go seems perfect for micro services, command line utilities and single purpose applications. Which is where it seems to have gained a lot of traction in companies to date.

Re: Rust and Go

#89

Post by jaekwon »

jacques_chester wrote: post #84
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. :)

Semantically, loops impose order, maps do not. A map can be auto-parallelised. A loop cannot. It seems to me that for a language aimed at exploiting concurrent features, easy wins for parallelisation would be a feature.

There's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.

Re: Rust and Go

#90

Post by pcwalton »

jaekwon wrote: post #87
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.)

Well this is how I'd write it in Go: descending_squares := []uint{} for x:=4; 0

Use unsigned integers for your index and values. That's what makes it hard to use a for loop. (Sure, you could cast a signed integer loop index to unsigned inside the loop to avoid the underflow problem in this specific case, but I'd argue that the functional style is so much clearer than code that has to work around unsigned underflow gotchas.)
Post reply on HN