Rust and Go

Post by _bpo » Sat, Nov 08, 2014, 2:26 AM UTC

desdiv wrote: post #124

_bpo wrote: post #121

Earlier quoted context omitted.

A big problem in large-scale systems is dependency management. One of the significant decisions that Go makes in its design is its approach to package management. Its approach isn't perfect, but is simple, making it a breath of fresh air compared to C++ or JVM-based languages... e.g. how many hours have been spent tweaking Maven or debugging discrepancies between classpaths referencing different copies of commons-log…

Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. How is that different from the 40 years old Unix utility indent? Pretty much every single non-trivial programming language has its own code formatter. Auto code formatting is…

Post by shurcooL » Sat, Nov 08, 2014, 2:39 AM UTC

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…

Post by desdiv » Sat, Nov 08, 2014, 3:05 AM UTC

_bpo wrote: post #131

desdiv wrote: post #124

Earlier quoted context omitted.

Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python. How is that different from the 40 years old Unix utility indent? Pretty much every single non-trivial programming language has its own code formatter. Auto code formatting is…

I didn't mean to imply Go invented automatic formatting :) It's unique among the popular language that I know in that the formatter is built into the standard toolkit. It also goes well beyond indentation. I've never seen a discussion of the format of go code outside the discussion of how `go fmt` should work - this I consider a benefit.

Post by carapace » Sat, Nov 08, 2014, 3:14 AM UTC

jaekwon wrote: post #114

rybosome wrote: post #103

Earlier quoted context omitted.

Let's take the example interview question: given a string, how do you determine if it is an anagram of a palindrome? The answer is that, for any given character, at most 1 should appear in the string an odd number of times. Here is an implementation in Scala, with higher-order functions: def isAnagramOfPalindrome(s: String): Boolean = s.groupBy { c => c } .map { case(key, value) => value.size() } .filter { n => n % 2…

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…

    def odd_count(letters):
        return lambda ch: letters.count(ch) % 2

    def anagram_of_palindrome(letters):
        return sum(map(odd_count(letters), set(letters)))