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

221–230 of 311 posts

Re: Rust and Go

#221

Post by masklinn »

acqq wrote: post #210
dbaupp wrote: post #193

Earlier quoted context omitted.

As you say, detecting the overflow is easy, but efficiently handling it is not. It adds a branch to every single arithmetic operation, and it makes it much harder for the compiler to optimise things e.g. it is hard to vectorise a loop summing an array, if every + has a conditional branch on the overflow flag. (Also, I believe it introduces a lot of data dependencies, getting in the way of the out-of-order execution o…

To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction. Also, modern compilers could optimize the checks away if they aren't used. In effect, implementing overflow checks definitely won't turn your C speed (1s) code in a Python speed (40s) code. I estimate it wouldn't be even two times slower in most of the use cases. It's cert…

> I estimate it wouldn't be even two times slower in most of the use cases.

In his "We Need Hardware Traps for Integer Overflow"[0], Regher quotes 5% to 100% overhead for languages such as JS or Racket, and that a "highly tuned" checker would likely be in the 5% range. Playing with arithmetics-heavy programs and Rust's checked_* (which are backed by LLVM's overflow intrinsics[1]) I got anywhere from 5 to 40% performance loss IIRC.

That's not a lot, but at the same time when you're competing with languages specifically not paying those 5%, a 5% hit on all computations is not going to get you much love.

Which is why Rust currently lets you do that (via num::Checked* and num::Saturating) but uses overflowing default semantics.

[0] http://blog.regehr.org/archives/1154

[1] http://llvm.org/docs/LangRef.html#arithmetic-with-overflow-i...

Re: Rust and Go

#222

Post by zzzcpan »

Dewie wrote: post #219
zzzcpan wrote: post #217

Earlier quoted context omitted.

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

Well, the way I see it has nothing to do with levels of abstractions or flexibility, but everything with reducing amount of brain power required to understand the program. Sometimes abstractions do help, other times they add unnecessary complexities and reduce people's brain power to understand the rest of the code and therefore make mistakes in it. This is all about psychology.

Sorry, if I was rude, I'm just tired of pseudo-scientific language designs.

Re: Rust and Go

#223

Post by masklinn »

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.

> And people make mistakes independent of language features

Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature.

Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-variable use), therefore iterators can indeed reduce bugs.

Re: Rust and Go

#224

Post by masklinn »

carapace wrote: post #137
jaekwon wrote: post #114

Earlier quoted context omitted.

In Go: func isAnagramOfPalindrome(str string) bool { charCounts := map[rune]int{} for _, c := range str { charCounts[c]++ } numOdd := 0 for _, count := range charCounts { if count%2 == 1 { numOdd++ } } return numOdd In this case I think I do prefer the latter. I like how I can name the intermediate objects. :) Also I don't like the practice of groupBy().map(=>_.size()), which hides the performance penalty of creating…

I'll bite. In Python: def odd_count(letters): return lambda ch: letters.count(ch) % 2 def anagram_of_palindrome(letters): return sum(map(odd_count(letters), set(letters))) How's that for some higher-order function action? But really, unless you are deriving programs by doing algebra you are missing the point of things like map() and reduce() (as far as I know no one is actually doing Functional Programing the way Bac…

A more modern take would use collections.Counter(letters) to extract the letter counts, that avoids traversing the string for each letter count:

    def anagram_of_palindrome(letters):
        return sum(c % 2 for c in Counter(letters).itervalues())

Re: Rust and Go

#225

Post by f2f »

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!

"all goroutines are asleep - deadlock".

https://code.google.com/p/go/source/browse/src/runtime/proc....

Re: Rust and Go

#226

Post by masklinn »

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.

I found that attitude much more prevalent in the .Net community: for just about anything added since C# 2.0 (I didn't follow discussions about generics after the 1.0 release though I expect it also happened then), the idea was essentially dismissed as pointless ivory-tower wankery useless to developers in the Real World right until MS announced it for the next version, at which point it became an Obviously Great idea and a good way to trash-talk java.

Re: Rust and Go

#227

Post by zzzcpan »

masklinn wrote: post #223
zzzcpan wrote: post #217

Earlier quoted context omitted.

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

> And people make mistakes independent of language features Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature. Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-var…

  > Therefore you can't make the mistake of unknowingly
  > concatenating a number and a string in Go.
Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.

Re: Rust and Go

#228

Post by ufo »

masklinn wrote: post #207
burntsushi wrote: post #202

Earlier quoted context omitted.

I'm aware. The presence of nonlocal and global still makes them broken to me, even if it's a result of how scoping works. Lua and Javascript both manage to have unbroken closures.

> Lua and Javascript both manage to have unbroken closures. Because they use explicit local declaration (and implicitly declared variables are global in both)…

Yes, and I would say that requiring explicit local declarations is the right thing to do. Having a "default" variable scope is very error prone (typos are treated as new variables and closures don't work right) but at least with "global by default" you can use a linter to enforce that all your globals are explicitly declared. In Python its impossible to do something similar.

Re: Rust and Go

#229

Post by mutation »

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.

It seems that Go's race detector (https://blog.golang.org/race-detector) can do that. see an example: http://pastie.org/9705392

Re: Rust and Go

#230

Post by holoway »

shurcooL wrote: post #133
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…

It seems relatively clear that he's quite new to both languages, with maybe a few weeks worth of familiarity if not less. From his rookie mistake of using path package instead of path/filepath to join system file paths [1], to non idiomatic naming with underscores, and what he describes in general. It's interesting from the perspective of what a fresh perspective on both languages is, but the comments have less value…

I am absolutely quite (completely) new to both languages.
Post reply on HN