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

301–310 of 311 posts

Re: Rust and Go

#301

Post by pcwalton »

NateDad wrote: post #295
kibwen wrote: post #290

Earlier quoted context omitted.

To be fair, the line "And that's why I like go" seems to imply that Go is able to keep you from making errors in untested context-free code snippets. Perhaps you meant "and that's why I like that Go doesn't support operations like `map`"?

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason. The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period…

> Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

Sorry, I don't see the benefit of "preventing errors in code that's never actually executed" as a design goal.

> The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

I just demonstrated a counterexample in this thread.

Re: Rust and Go

#302

Post by sanderjd »

amelius wrote: post #51
sanderjd wrote: post #29

Earlier quoted context omitted.

> Is it in a state ready to replace C++? Nope. That will take many years. But it definitely is in a state where you can start building real things with it, if you don't mind some of the usual costs of being on the bleeding edge, like documentation that's hard to grok, frequent trips to irc, and frequent breaking changes. But breaking changes will be going away very soon, the documentation gets better all the time, an…

How well does the optimizer perform? And do you often encounter nasty, hard to trace, bugs in the compiler output?

I've yet to see a bug that I traced back to the compiler rather than my own code (which doesn't mean they haven't happened, just that if they have, they have been obscure enough that I haven't noticed them).

Re: Rust and Go

#303

Post by NateDad »

kibwen wrote: post #300
NateDad wrote: post #295

Earlier quoted context omitted.

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason. The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period…

> Go does help prevent errors in untested context-free code > snippets... by being really really simple, and not trying > to mash a ton of logic into a single line for no reason. But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop. This isn't an attack on Go (which I respect as a language for having the…

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

Re: Rust and Go

#304

Post by acqq »

masklinn wrote: post #250
masklinn wrote: post #221

Earlier quoted context omitted.

> 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% performa…

OTOH I must note that Swift, on the other hand, has opted to error on overflow and have a second set of overflowing operators: https://developer.apple.com/library/mac/documentation/swift/...

And that's the best approach I can imagine: programmer should be able to control if he wants 5% penalty or speed. It's a win-win.

Re: Rust and Go

#305

Post by kibwen »

NateDad wrote: post #303
kibwen wrote: post #300

Earlier quoted context omitted.

> Go does help prevent errors in untested context-free code > snippets... by being really really simple, and not trying > to mash a ton of logic into a single line for no reason. But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop. This isn't an attack on Go (which I respect as a language for having the…

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

Likewise, forgetting a `.collect()` call in Rust code doesn't happen, because the compiler will tell you without fail when it's given an iterator but expects an array.

Re: Rust and Go

#306

Post by Injunire »

waps wrote: post #272
_bpo wrote: post #138

Earlier quoted context omitted.

You're certainly correct, but if you compare this: http://linux.die.net/man/1/indent with this: https://golang.org/cmd/gofmt/ even just by line count, you'll see the difference in philosophy.

Unfortunately having a code formatter does not make up for basic deficiencies in the language itself when it comes to datatypes. Basic example : http://stackoverflow.com/questions/19946992/sorting-a-map-of... (shortest way to sort an array of a custom datatype in go is around 50 lines of code, and requires you to write a custom sorting class)

First example on that page shows a straightforward solution in under 10 lines of code.

Convert the map values to a slice and then use the stdlib package sort to organize the data.

Re: Rust and Go

#307

Post by pcwalton »

NateDad wrote: post #303
kibwen wrote: post #300

Earlier quoted context omitted.

> Go does help prevent errors in untested context-free code > snippets... by being really really simple, and not trying > to mash a ton of logic into a single line for no reason. But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop. This isn't an attack on Go (which I respect as a language for having the…

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

> Yes and that was a carefully constructed example explicitly to show problems with loops

No, it was an example from my experience and a bug I have had to fix multiple times, as I mentioned. I didn't make it up.

Re: Rust and Go

#308

Post by NateDad »

pcwalton wrote: post #307
NateDad wrote: post #303

Earlier quoted context omitted.

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

> Yes and that was a carefully constructed example explicitly to show problems with loops No, it was an example from my experience and a bug I have had to fix multiple times, as I mentioned. I didn't make it up.

Sorry, yes you mentioned that. Anyway, this is a stupid thing to argue about and I apologize for my part in it.

Re: Rust and Go

#309

Post by nostrademons »

codygman wrote: post #298
nostrademons wrote: post #134

Earlier quoted context omitted.

For me - it's because Go exists in the same uncanny valley as Java. It is a language that manages to get a good number of trade-offs right, balances performance & productivity, and provides a good all-around package. However, it's not the best at anything. If you need super performance and the ability to control the machine directly, you still need C++. If you want super productivity and the ability to quickly try ou…

Do you really think Go is better at concurrency and networking than Erlang?

I said mainstream. Erlang is better at concurrency & networking, but it has some very pragmatic problems (notably, string handling is dog-slow and takes lots of memory) that rule it out for many use-cases. The tooling for Go is also better than that for Erlang, the libraries for things other than telecom & messaging are more extensive, and you're more likely to find enthusiastic developers for it.

Re: Rust and Go

#310

Post by waps »

Injunire wrote: post #306
waps wrote: post #272

Earlier quoted context omitted.

Unfortunately having a code formatter does not make up for basic deficiencies in the language itself when it comes to datatypes. Basic example : http://stackoverflow.com/questions/19946992/sorting-a-map-of... (shortest way to sort an array of a custom datatype in go is around 50 lines of code, and requires you to write a custom sorting class)

First example on that page shows a straightforward solution in under 10 lines of code. Convert the map values to a slice and then use the stdlib package sort to organize the data.

You left out defining a sorting class, like in Turbo Pascal. So, it's 17 lines of code (wrong version provided on stackoverflow) or 21 lines, the correct version :

  type dataSlice []*data

  // Len is part of sort.Interface.
  func (d dataSlice) Len() int {
      return len(d)
  }

  // Swap is part of sort.Interface.
  func (d dataSlice) Swap(i, j int) {
      d[i], d[j] = d[j], d[i]
  }

  // Less is part of sort.Interface. We use count as the value to sort by
  func (d dataSlice) Less(i, j int) bool {
      // WRONG : will crash if there's a nil in the list ...
      return d[i].count
Python version:

  // create list of data in variable s
  s.sort(key=lambda x: x.count)
C++ version:

  // Create Vector in s
  sort(s.begin(), s.end(), [](const Data& d1, const Data& d2) { return d1.count
Java version:

  // Create List in s
  Collections.sort(s, (Data d1, Data d2) -> Integer.compare(d1.count, d2.count));
Let's put it this way. If Java is 16 TIMES more concise than your language, you have a problem. A big problem.
Post reply on HN