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

151–160 of 311 posts

Re: Rust and Go

#151

Post by BrianHV »

pcwalton wrote: post #91
jaekwon wrote: post #89

Earlier quoted context omitted.

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.

The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).

Having just started reading the Rust guides, I'm curious: can the closure type actually ensure it doesn't mutate any externally visible data, or does that only apply to memory? Can declare that a closure doesn't (or shouldn't be allowed to) write to disk or hit a database?

Re: Rust and Go

#152

Post by blt »

pjc50 wrote: post #47
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…

Never underestimate the legacy. I've resolved not to start another C++ project, but I'm learning MFC at the moment for working on a codebase that's 35 years old and was rewritten into C++ at some point in the 90s.

I'm sorry you have to do that.

Re: Rust and Go

#153

Post by nightpool »

tptacek wrote: post #108
nightpool wrote: post #98

Earlier quoted context omitted.

Umm... Am I just interpreting you wrong? Python has map in the builtin namespace: >>> map(lambda x: x*5, range(5)) [0, 5, 10, 15, 20]

Python obviously has those primitives (that's what I meant by the tradeoff between it and Golang) but Guido infamously discourages their use.

Hmm, sorry I didn't see this earlier, but I personally feel that Python supports a healthy mix of imperative, functional and object-oriented styles. (especially with the (over?) use of the "operators" library I tend to see around nowadays...)

Certainly when I picked up a purely functional language (Racket) after mainly having only Python and Java experience before I didn't feel too disoriented or out of touch.

Re: Rust and Go

#154

Post by jbooth »

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.

Amdahl's law says auto-parallelising a map operation is usually a big waste of time.

Re: Rust and Go

#155

Post by codygman »

earlz wrote: post #33
alkonaut wrote: post #17

If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.

Wow that makes me cringe. This specifically: > The power of the map/filter abstraction starts becoming more apparent when you do things like > Filter(someFunc, Map(funcWith3args, vecA, vecB, vecC)) > And you realize you should swap map and filter for your particular app for better performance. met with this reply: > vs > [10 lines of code for two for loops doing the same thing] > Using range makes it obvious that the…

In cases of needing more performance, you only swap map and filter for a loop in languages that don't optimize it.

Re: Rust and Go

#156

Post by codygman »

pcwalton wrote: post #106
jaekwon wrote: post #99

Earlier quoted context omitted.

All I did was take your for-loop code and translated into idiomatic Go code. My point is the for-loop in Go isn't as terrible as the loop example you wrote.

Your version infinite loops: http://play.golang.org/p/uglbTETE6d See why for loops are tricky? :)

I love when arguments are decided by/proven by runnable code examples.

Re: Rust and Go

#157

Post by codygman »

jbooth wrote: post #154
jacques_chester wrote: post #84

Earlier quoted context omitted.

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.

Amdahl's law says auto-parallelising a map operation is usually a big waste of time.

Who is Amdahl, why should I care, and does he expand on this argument or is it your interpretation of a more generalized law?

Going to search for it, but I'd still like to hear your response.

Re: Rust and Go

#158

Post by burntsushi »

nightpool wrote: post #153
tptacek wrote: post #108

Earlier quoted context omitted.

Python obviously has those primitives (that's what I meant by the tradeoff between it and Golang) but Guido infamously discourages their use.

Hmm, sorry I didn't see this earlier, but I personally feel that Python supports a healthy mix of imperative, functional and object-oriented styles. (especially with the (over?) use of the "operators" library I tend to see around nowadays...) Certainly when I picked up a purely functional language (Racket) after mainly having only Python and Java experience before I didn't feel too disoriented or out of touch.

The parent is referring to the fact that Guido van Rossum (the Benevolent Dictator For Life of Python) is pretty down on functional programming in Python. You can read some of the history (from the horse's mouth) here: http://python-history.blogspot.com/2009/04/origins-of-python...

TL;DR - "I have never considered Python to be heavily influenced by functional languages, no matter what people say or think."

Python, IMO, has flutters of functional programming in it. But its broken closures, lack of uncripppled anonymous functions and lack of tail-call optimization are pretty damning strikes against calling Python's support for functional programming similar to its support for imperative or OO paradigms. It just isn't. Yeah, we get `map` and `filter`, big whoop. :-)

Re: Rust and Go

#159

Post by yohanatan »

eridius wrote: post #40
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…

I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I'm hoping that as Swift evolves over time, it will slowly become that sort of language. Right now it's pretty hard to write any rea…

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream.

I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many other mainstream languages and there's only so long that can happen before people just start going directly to the source of the innovations (or one of its direct descendants).

Re: Rust and Go

#160

Post by grogers »

zzzcpan wrote: post #72
alkonaut wrote: post #17

If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.

There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra. But no matter how I dislike it there is just no other choice today. It all comes down to support, bug fixing, ease to learn and to use, good standard library, built in cross-compilation and a pretty fast one, static binaries, good enough dependency management, reasonable performance and memory usage, espec…

Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things.

The other choices are certainly there.

Post reply on HN