Rust and Go • Hacker News Board

Re: Rust and Go

#121

Post by _bpo » Sat, Nov 08, 2014, 1:54 AM UTC

threeseed wrote: post #88

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…

>(2) large yet maintainable systems I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of develo…

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-logging?

Speaking of Maven - `go build` normalizes build systems so there is less time twiddling builds. It's not a silver bullet, but it's specifically intended for large systems.

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.

Go isn't perfect, but it's certainly designed for large-scale systems.

I agree with you that the JVM languages have better large-scale system support currently (20 years does give you something) -- but Go's goal is not dissimilar to the one Java eventually settled on after the applet craze.

Contrary to what you've seen, Go seems (to me) to be a go-to language for new companies principally concerned with distributed systems / cloud infrastructure (particularly those that once might have hired a hybrid of C and scripting language devs). One of the trends in those communities is toward microservices / SOA / etc, but the total codebases managed are certainly enterprise-scale.

All that said I have absolutely no significant opinions on Go vs Rust :) Just had to take issue with the "go is not enterprise scale" idea.

Re: Rust and Go

#122

Post by mattnewport » Sat, Nov 08, 2014, 1:56 AM UTC

humanrebar wrote: post #45

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…

who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most ob…

Games developers are also overwhelmingly C++ developers (at least AAA console game developers, things are a bit different in the mobile and indie space where other languages have made inroads). Performance is a major reason for us too but large legacy code bases and the platform and library ecosystems we work with are also major factors.

Plus some of us actually really like C++ and/or C :)

Re: Rust and Go

#123

Post by jaekwon » Sat, Nov 08, 2014, 1:58 AM UTC

pcwalton wrote: post #106

jaekwon wrote: post #99

Earlier quoted context omitted.

All I did was take your for-loop code and translated into idiomatic Go code. My point is the for-loop in Go isn't as terrible as the loop example you wrote.

Your version infinite loops: http://play.golang.org/p/uglbTETE6d See why for loops are tricky? :)

Doh! I fell straight in :)

Overflows in general are tricky. How does Rust deal with it?

Re: Rust and Go

#124

Post by desdiv » Sat, Nov 08, 2014, 2:15 AM UTC

_bpo wrote: post #121

threeseed wrote: post #88

Earlier quoted context omitted.

>(2) large yet maintainable systems I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of develo…

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 neither novel nor unique to Go.

Re: Rust and Go

#125

Post by rdtsc » Sat, Nov 08, 2014, 2:16 AM UTC

tptacek wrote: post #76

Jweb_Guru wrote: post #60

Earlier quoted context omitted.

> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…

Distributed systems programming is its own special concurrency problem, and distributed systems also exhibit deadlock, races, and serialization, no matter what language they're implemented in. I'm not sure what finding a race condition in a distributed commit implementation says about a language; at the very least, it's nothing you couldn't say about Rust as well, which is also not a language that solves distributed…

It is not a black and white situation probably. Golang is better because it has built-in channels and encourages users to take advantage of them. It also has garbage collection. So those 2 things right of the bat help.

But there are better things out there -- isolated heaps (Erlang), borrow checkers (Rust), stronger type systems and immutability (Haskell) etc. There are no magic unicorns so those things often come at a price -- sequential code slowdown.

Getting back to go. One can of course say, "Oh, send only messages. We are all adults here. Let's just agree to be nice. Stop sharing mutable memory between goroutines!" But all it takes is "that guy" or "that library", doing it "that one time" and then there are crashes during a customer demo or during some critical mission. It crashes and then good luck trying to reproduce it. Setting watchpoints in gdb (or the equivalent Go tool), asking customers "Can you tell me exactly what you did that day. Think harder!" and so on.

Also, as others have pointed, with Golang though, often it is run with just one OS thread backing all the concurrency. So many potential races could be just be hidden.

There is also some confirmation bias involved. When something is broken, often authors don't write blogs about it, don't advertise. They fix it, and move on. So maybe a lot of programs are full of concurrency bugs but just nobody is blogging about it. They've invested time and energy into learning a new ecosystem and now they have to blog about its flaws and so on. That is hard to do.

Another observation is that when spending a lot of time debugging and handling segfaults, pointer errors, user-after free errors, concurrency issues, that becomes the default and expected view of how programming works. It becomes hard to imagine how it could work another way. It becomes obvious that weeks would be spent tracking one concurrency bug or having to add cron jobs to watch for crashed programs and restart them because the system is so complex and non-deterministic, replicating the bug is too hard.

Re: Rust and Go

#126

Post by [deleted] » Sat, Nov 08, 2014, 2:16 AM UTC

tptacek wrote: post #76

Jweb_Guru wrote: post #60

Earlier quoted context omitted.

> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…

Distributed systems programming is its own special concurrency problem, and distributed systems also exhibit deadlock, races, and serialization, no matter what language they're implemented in. I'm not sure what finding a race condition in a distributed commit implementation says about a language; at the very least, it's nothing you couldn't say about Rust as well, which is also not a language that solves distributed…

[deleted]

Re: Rust and Go

#127

Post by ChrisGaudreau » Sat, Nov 08, 2014, 2:18 AM UTC

bad_user wrote: post #30

ryandvm wrote: post #3

Earlier quoted context omitted.

Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.

Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. You can't possibly find a worse reason for learning a new language. On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hi…

Personally, I like to learn any language, regardless of how popular it is. It's just fun.

Re: Rust and Go

#128

Post by pcwalton » Sat, Nov 08, 2014, 2:20 AM UTC

jaekwon wrote: post #123

pcwalton wrote: post #106

Earlier quoted context omitted.

Your version infinite loops: http://play.golang.org/p/uglbTETE6d See why for loops are tricky? :)

Doh! I fell straight in :) Overflows in general are tricky. How does Rust deal with it?

We have special checked types you can use if you want checked arithmetic. The default is to not check, because CPUs currently make it expensive to check (although I would love it if that could change--we need hardware support though).

Re: Rust and Go

#129

Post by rdtsc » Sat, Nov 08, 2014, 2:23 AM UTC

twtwtaway wrote: post #74

Jweb_Guru wrote: post #60

Earlier quoted context omitted.

> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…

Were there any code examples provided that 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.

> 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 about, somehow I doubt that will lead to much but being kickout and laughed at.

One can also just have 2 goroutines wait on each for results and that's a deadlock. Maybe there is a tool to detect that would be nice. Do you know of one?

Re: Rust and Go

#130

Post by dbaupp » Sat, Nov 08, 2014, 2:24 AM UTC

Cyther606 wrote: post #80

humanrebar wrote: post #45

Earlier quoted context omitted.

who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most ob…

Nim performance compares favorably to C++. It features a Pythonic syntax, optional soft real-time GC, optional manual memory management. Porting an elliptic curve implementation over to Nim from Python was a cinch: elliptic.nim: https://github.com/def-/bigints/blob/master/examples/ellipti... elliptic.py: https://github.com/wobine/blackboard101/blob/master/Elliptic... Others have reported success converting Python cod…

The Rust vs Nim comparison is tainted by very out of date documentation hosted on some MIT servers (the condition system is entirely gone). It's unfortunate and we have contacted the web master but there's not much they can do to remove or change how it appears in search engine rankings.

For reference, doc.rust-lang.org is the only place to look for documentation for the standard libraries; any other hosting of those docs is likely to be out-of-date.