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

171–180 of 311 posts

Re: Rust and Go

#171

Post by masklinn »

Animats wrote: post #170
jaytaylor wrote: post #162

Earlier quoted context omitted.

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex) Lock Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available. http://golang.org/pkg/sync/ It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

In most languages, the language says nothing about what data is protected by the mutex. Modula and Ada did, and Java has "synchronized" objects, but C/C++/Go lack any syntax for talking about that. This typically becomes a problem as a program is modified over time, and the relationship between mutex and data is forgotten.

> In most languages, the language says nothing about what data is protected by the mutex.

Or the other way around, what mutex protects a piece of data (or even that a piece of data should be protected at all), so it's easy to forget it and just manipulate a bit of data without correctly locking it.

I was pleasantly surprised to discover that Rust's sync::Mutex owns the data it protects, so you can only access the data through the mutex (and the relation thus becomes obvious).

Re: Rust and Go

#172

Post by masklinn »

burntsushi wrote: post #158
nightpool wrote: post #153

Earlier quoted context omitted.

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

> But its broken closures

They were "unbroken" in Python 3, though because of the way scoping works in the language it requires marking variables (with `nonlocal`)

Re: Rust and Go

#173

Post by masklinn »

hit8run wrote: post #166
pcwalton wrote: post #106

Earlier quoted context omitted.

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

Just use int and it works fine: http://play.golang.org/p/nZcd3M5aL_ To me golang is readable while even small rust examples don't feel quite right right.

> Just use int and it

is a completely different piece of code.

Re: Rust and Go

#174

Post by alkonaut »

one-more-minute wrote: post #68
theseoafs wrote: post #37

Earlier quoted context omitted.

What an infuriating thread. I guess I'm not the kind of person Go is made for, but the fact that everyone in the thread was so close-minded about what might be helpful about map, filter, and reduce was frankly absurd. I especially enjoyed the demonstration of map would look in Go code, complete with a useless anonymous function: > bar = map(foo, func(e T) { return f(e) }) And this guy who doesn't seem to understand t…

What you're forgetting is that adding one useful feature is a slippery slope towards adding many other useful features, and thereby no longer having a mediocre language.

First class functions is a language feature. I definitely understand omitting it from a language. But go has that already. The issue is that without good higher order functions in the core libs, it's quite a waste!

Re: Rust and Go

#175

Post by MichaelGG »

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…

F# has that. With Mono you can produce static binaries. And the F# compiler can also make statically linked assemblies, including the bits it needs from all its dependencies.

Although I'm not sure if there is an F# code formatter tool. Which is made up for by F# being a vastly more capable language.

Re: Rust and Go

#176

Post by masklinn »

codygman wrote: post #157
jbooth wrote: post #154

Earlier quoted context omitted.

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.

The application in this case is that the mapped operation generally has a fairly low cost and the (sequential) cost of dispatching and resynchronising back into a result are going to dwarf any gain you'd get unless either the collection is huge (and the parallelization is coarsely chunked) and/or the mapped operation is extremely expensive.

Same reason why even though mergesort is fairly trivially parallelizable there's basically no stdlib running parallel mergesorts by default: you need huge collections before you recoup the synchronization overhead.

Re: Rust and Go

#177

Post by ternaryoperator »

yohanatan wrote: post #159
eridius wrote: post #40

Earlier quoted context omitted.

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

I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that. In fact, I would argue just the reverse. People chose the derivative languages b/c they provide things the original does not.

To wit, Lisp never became mainstream despite exerting a huge influence. Likewise Smalltalk.

Re: Rust and Go

#178

Post by masklinn »

Dewie wrote: post #11
jeorgun wrote: post #7

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustra…

> Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. Of course any function can be forced to crash by inserting some crash-inducing code into the function. You can always make a function that assumes that value is of a certain form, and crashes the program if it is not (like unwrap for ext…

> What should that do? Crash the program? If so it should have been renamed to something like `panic!` now

It crashes the current task (thread/process), not the whole program, and has in fact been renamed panic! recently: https://github.com/rust-lang/rust/pull/17894

Re: Rust and Go

#179

Post by gruvector »

twtwtaway wrote: post #66
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. :)

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.

Re: Rust and Go

#180

Post by [deleted] »

twtwtaway wrote: post #66
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. :)

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.

[deleted]
Post reply on HN