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

261–270 of 311 posts

Re: Rust and Go

#261

Post by z0r »

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

The discussion here has been good, and the thread is already old, but I can't help myself!

Maps, filters, folds provide a vocabulary for manipulating entire collections. They allow you to write code for transforming the individual items of a collection without mixing it with code that deals with the shape of your collection. Maps, folds, and filters exist for trees and all kinds of other structures with interesting shapes that are more challenging to traverse and reason about than a simple array or list. Languages with first class support for these operations provide a common vocabulary for processing collections of any shape. This alone is a good enough reason for me to prefer such languages, even without bringing readability into the mix.

I also think that it is usually possible to write code with maps and filters that is at least as readable as its for loop equivalent, especially with the comprehension sugar commonly found in many functional languages.

Re: Rust and Go

#262

Post by zzzcpan »

dbaupp wrote: post #256
zzzcpan wrote: post #239

Earlier quoted context omitted.

No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say. Having separate concatenation operator with implicit conversion could reduce that overhead: a := "foo" ~ "bar" ~ 123 Instead of: import "strconv" a := "foo" + "bar" + strconv.Itoa(123) But this is not how Golang guys make decisions. And I'm fine wit…

The interesting code for this example is: c := a + b There's no indication from that line of code what a and b are, a type system that doesn't do implicit conversions will tell you "error: adding string and int" and so the programmer can address the problem (e.g. maybe they meant to parse an integer from the string `a`, maybe they meant to format the integer `b` into a string). Using literals is not a useful comparis…

My bad, I thought it was obvious from having separate operator for concatenation that '+' operator also has only one intent. So in your case it will parse an integer from a string if operand is a string.

Re: Rust and Go

#263

Post by jesstaa »

malkia wrote: post #215
NateDad wrote: post #195

Earlier quoted context omitted.

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!

http://golang.org/pkg/runtime/pprof/#Profile Provides a "blocking profile" that tells you what things blocked and for how long they blocked for. You can use it to find places where you've deadlocked as well as places where adding buffered channels might help performance.

Re: Rust and Go

#264

Post by jksmith »

pcwalton wrote: post #90
jaekwon wrote: post #87

Earlier quoted context omitted.

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

Or if Go and Rust had a FOR loop guaranteed to stop at 0, as with a Wirthian language, no?

Re: Rust and Go

#265

Post by emmanueloga_ »

legulere wrote: post #194
yohanatan wrote: post #159

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 don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many oth…

Even worse than the problem of uncommon concepts as monads is that Haskell's memory footprint is extremely hard to reason about. A few years ago it was impossible with the http libraries to download a file without the program consuming several times as much memory as the downloaded file.

A common recipe people quote for good software is "a) first make it work, b) then make it fast".

Haskell is very good at a), and not bad at all at b). With the help of the profiler it shouldn't be that hard to determine a program's bottlenecks/leaks and fix them, as with any other language.

BTW, since you mention http, I have this reading on my back burner [1] but from skimming it found that for certain payloads a haskell http server may perform better than nginx (1.4, circa 2013?), which is an impressive feat.

1: http://aosabook.org/en/posa/warp.html

Re: Rust and Go

#266

Post by emmanueloga_ »

bjz_ wrote: post #165
yohanatan wrote: post #159

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 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 have definitely heard from multiple people that for them Rust was a good stepping stone to Haskell. Hopefully it will be the same way with Swift.

That may be true but I find it curious. Without knowing too much about Rust, it looks like a lower level language than Haskell.

I'd have thought that someone would pick the higher level language first, and go to the lower lever when in need of more control.

Re: Rust and Go

#267

Post by emmanueloga_ »

programminggeek wrote: post #9

Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big o…

There is no perfect language but from what you write seems like you may enjoy Crystal [1]. It is probably not ready for prime time yet but it is making good progress!

1: http://crystal-lang.org/

Re: Rust and Go

#268

Post by fanf2 »

Dewie wrote: post #249
gokr wrote: post #211

Earlier quoted context omitted.

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.

> "Result" is not typically a word one would search for. It was renamed from the more generic (type-wise) "Either", because the two tags (Left and Right) didn't feel very descriptive when it was used as a error-or-value type. But "Either" at least hints at the concept of "either this or that": "Result" is even more of a generic name. I don't know why they settled on a name like that. (The two tags, Ok and Err are mor…

The mnemonic for how Either fits into the exception monad in Haskell is the result is either Right (correct) or Left (sinister). It is tainted by the old prejudice against left-handed people.

Re: Rust and Go

#269

Post by yohanatan »

eridius wrote: post #259
dbaupp wrote: post #254

Earlier quoted context omitted.

"Lisp" is a family of languages and Clojure is one member of this family.

Technically true, but I don't think it makes sense to consider Clojure to be the same thing as Lisp in the context of ternaryoperator's statement (though I obviously can't speak for him). Notably, Clojure's tight integration with Java is the primary reason for its relative popularity, and what most sets it apart from the rest of the Lisp family. It is disingenuous to claim Clojure means Lisp has gone mainstream when…

There are several languages targeting the JVM these days. And, what obviously sets Clojure apart from other JVM languages is its Lispiness (i.e., the JVM is constant across JVM languages).

Clojure is not married to the JVM either-- in fact, it has been hinted that it would jump ship if something better comes along or the current situation becomes less viable. Furthermore we already have a dialect of Clojure called ClojureScript which targets JavaScript/node/V8.

And, I look at the JVM as really merely a library/API/runtime. C++ has STL and stdio and such and they are not part of the language proper but rather merely libraries for interacting with the underlying operating system (in a platform independent way). The same is true for the JVM with respect to Clojure and Scala et al.

Re: Rust and Go

#270

Post by Dewie »

fanf2 wrote: post #268
Dewie wrote: post #249

Earlier quoted context omitted.

> "Result" is not typically a word one would search for. It was renamed from the more generic (type-wise) "Either", because the two tags (Left and Right) didn't feel very descriptive when it was used as a error-or-value type. But "Either" at least hints at the concept of "either this or that": "Result" is even more of a generic name. I don't know why they settled on a name like that. (The two tags, Ok and Err are mor…

The mnemonic for how Either fits into the exception monad in Haskell is the result is either Right (correct) or Left (sinister). It is tainted by the old prejudice against left-handed people.

I know, but in Rust's case it was more straightforward to call it Ok/Err since that was the majority use-case. Personally I prefer Either, since then you have a more generic sum type, just like the tuple type is a more generic product type (and if I'm using the terminology correctly).
Post reply on HN