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

111–120 of 311 posts

Re: Rust and Go

#111

Post by StevePerkins »

grayrest wrote: post #28
amelius wrote: post #12

How mature is Rust and its compiler actually at this moment? Is it in a state ready to replace C++? Edit: Also, I missed a good overview of features in one language and lacking in the other. In that respect, I find the wikipedia page [1] deeply broken, but that aside. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_langu...

Depends on what you mean by solid. It uses LLVM for all the codegen and perf is generally in line with C++. The core ideas around traits/borrowing/inference/mutablility have been stable for a while. What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works…

"What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week."

Huh? I'm seeing comments in this thread about people using Rust right now in production. How... why... what?!?

Re: Rust and Go

#112

Post by Dewie »

jfb wrote: post #109
Dewie wrote: post #63

Earlier quoted context omitted.

I liked Rob Pike's driveby comment - programmers these days...

... have come to expect some advances in programming languages from the last 50 years of research?

Programming Language Research is Irrelevant, or at least in Pike's world.

Re: Rust and Go

#113

Post by steveklabnik »

StevePerkins wrote: post #111
grayrest wrote: post #28

Earlier quoted context omitted.

Depends on what you mean by solid. It uses LLVM for all the codegen and perf is generally in line with C++. The core ideas around traits/borrowing/inference/mutablility have been stable for a while. What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works…

"What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week." Huh? I'm seeing comments in this thread about people using Rust right now in production . How... why... what?!?

There are two big deployments and some smaller ones. The two big ones are OpenDNS and Skylight.io.

We don't recommend it currently, but some people are just eager. :)

Re: Rust and Go

#114

Post by jaekwon »

rybosome wrote: post #103
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. :)

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 arrays. I'm sure a better compiler can do better, but I'd have to know the compiler to assume that.

Re: Rust and Go

#115

Post by Dewie »

StevePerkins wrote: post #111
grayrest wrote: post #28

Earlier quoted context omitted.

Depends on what you mean by solid. It uses LLVM for all the codegen and perf is generally in line with C++. The core ideas around traits/borrowing/inference/mutablility have been stable for a while. What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works…

"What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week." Huh? I'm seeing comments in this thread about people using Rust right now in production . How... why... what?!?

Some people like to live dangerously.

Re: Rust and Go

#116

Post by mattnewport »

agwa wrote: post #41
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…

> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas: I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many inno…

I definitely share this perspective, I think C++14 it's a great language and nothing I've seen about go has given me any interest in considering switching to it. Rust on the other hand looks really promising and has a bunch of neat innovations that make it seem pretty exciting to me and I'm definitely interested in learning more even though I'm by no means dissatisfied with modern C++.

The only other language I currently do any meaningful amount of coding in is F# and for me that replaces any need for a scripting language like Python or Ruby. I've used and liked Python but I really missed static typing.

Re: Rust and Go

#117

Post by Rapzid »

exacube wrote: post #62
kyrra wrote: post #22

Earlier quoted context omitted.

There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.

I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on langua…

A thousand times this. If somebody were to go through the process of actually trying to implement a generic map function in the current Go they would get a good sense of just what the issues are. Unfortunately you need a good grasp of the type system and this just isn't something most of the commenters on this subject have; the Go community is much more qualified. I've done this and generics are the first road block but after consigning to working around that you run into a lot of Go implementation details around interface{} and type assertion so that what you end up with is actually quite verbose in practise and no more desirable than the alternative.. I decided that for me, for loops aren't so bad.

So it does just come back around to generics but people are solving this with code generation, like gen which looks very interesting, and I imagine that is quite acceptable for the time being, for those who really want it.

Re: Rust and Go

#118

Post by tptfreak »

tptacek wrote: post #79
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.

Let me save the reader of this comment a long and unproductive session of reading tea leaves out of mailing list posts: * Golang doesn't have generics. This comes up so often on the mailing list that it's in the FAQ: http://golang.org/doc/faq#generics * Golang has a similar attitude to idiomatic functional programming tools as Python; it doesn't have map() and it's not easy to write a general-purpose map. (I'll take…

Question.. do you do anything else in your life other than commenting on HN 24/7?

Re: Rust and Go

#119

Post by tptacek »

tptfreak wrote: post #118
tptacek wrote: post #79

Earlier quoted context omitted.

Let me save the reader of this comment a long and unproductive session of reading tea leaves out of mailing list posts: * Golang doesn't have generics. This comes up so often on the mailing list that it's in the FAQ: http://golang.org/doc/faq#generics * Golang has a similar attitude to idiomatic functional programming tools as Python; it doesn't have map() and it's not easy to write a general-purpose map. (I'll take…

Question.. do you do anything else in your life other than commenting on HN 24/7?

Yes, I also scrapbook.

Re: Rust and Go

#120

Post by gorhill »

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

> functional style is so much clearer

There is something that makes me uncomfortable in there:

> let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect();

The overhead. I wonder about it. I am unable to get a sense of what it is. With a simple for-loop, it's rather easy to see it, but with the version above I have no idea. So "much clearer" is not what I see with the piece of code above. I see what it does, but what is not so clear is what code will be generated, something which matters when trying to write efficient code.

Post reply on HN