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

51–60 of 311 posts

Re: Rust and Go

#51

Post by amelius »

sanderjd wrote: post #29
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...

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

Re: Rust and Go

#52

Post by exacube »

freyr wrote: post #34
exacube wrote: post #27

I think to properly write a language comparison, you need to have extensively used both languages and with multiple use cases. For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issu…

I'm confused by your comment. Does it take extensive experience and multiple use cases to assess a language? Or a couple hours writing a small service?

The former. I'm not arguing that I have extensive experience or had multiple use cases (I had neither), but I am saying these very serious issues started to pop up just a couple of hours in. I'm surprised there is nothing here about these seemingly oft-occurring issues in this article, and makes me feel like the author hasn't used the language enough (again, not that I have).

Re: Rust and Go

#53

Post by alkonaut »

exacube wrote: post #27

I think to properly write a language comparison, you need to have extensively used both languages and with multiple use cases. For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issu…

True, but you can assess how approachable a language is by simply approaching it. This is useful information. You could even argue that experience would disqualify you from reviewing using that angle!

Re: Rust and Go

#54

Post by tptacek »

Animats wrote: post #23

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…

Like you†, I've had the pleasure of working with some fairly large concurrent codebases and the character-building experience of tracking down deadlocks, random memory corruption bugs that turn out to be race conditions, and (my most favorite of all) unexpected serializations that randomly bring programs to a halt. Most of that experience has been in C++, with a little C and a little Java mixed in there.

Over & over I see language aficionados ding Golang for not taking advantage of immutability and for allowing shared data --- or, in your case, going a step further and reducing all communication among processes in Golang to instances of synchronized sharing.

What I'd like to know is: why don't all those hundreds of thousands of lines of concurrent Golang code out there, including all the library code I can just "go get" and whose authors have been encouraged by Rob Pike to use, basically, threads with near total abandon (watch his video about designing a lexer!) --- why don't all those libraries and programs randomly deadlock and corrupt themselves all the time?

Because my experience is that Golang code is quite a bit more reliable than, for instance, Python code.

What am I missing? The "share by communicating" model in Golang seems to work pretty darn well, especially given the extent to which Golang begs programmers to make programs concurrent.

† OK probably you more than me but still.

Re: Rust and Go

#55

Post by freyr »

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 apologize, "still" came off as pejorative. My post became a little muddled there, but had my thoughts been clearer, I would have focused on just one group: programmers who currently use C++ even though they would prefer to switch to another language. My interest pertains to them -- what requirements have prevented them from switching, and does Go satisfy those requirements?

>> [C++ is] still evolving and has produced many innovations

You're absolutely right, those features extend beyond performance/control.

>> Go looks like an update of C that has ignored all the good innovations of C++.

Yes, Go feels much more like an updated C to me too. And it makes it all the more surprising they expected C++ programmers to jump on board. I double-checked the quote, and actually C wasn't mentioned at all.

Re: Rust and Go

#56

Post by twtwtaway »

Comparing Go and Rust doesn't feel right. They are obviously designed for solving different kind of problems. Go is a simple language, maybe even too simple for my taste. But simplicity is its greatest strength. And I can understand people who would prefer Go as their go-to language for dealing with specific kind of problems. Go is a boring language but gets you where you want to be in a short time and without much suprises. Rust, on the other hand is designed for systems programming. It's got some nice features but it's also a lot more complex language than Go. I don't want to fight compiler all the time. Sometimes I don't need that kind of safety.

Re: Rust and Go

#57

Post by Ygg2 »

burntsushi wrote: post #13

> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs

Yeah, that whole part got the me the wrong way. Docopt is as far as I know the best. Also rust comes with a simpler getopt.

It is broken now, but with the collection reform landing, what isn't broken.

Re: Rust and Go

#58

Post by carllerche »

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?

Rust uses LLVM for all code generation and optimization. So, in that respect, it is very mature and I personally have never hit an issue.

Re: Rust and Go

#59

Post by [deleted] »

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?

[deleted]

Re: Rust and Go

#60

Post by Jweb_Guru »

tptacek wrote: post #54
Animats wrote: post #23

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…

Like you†, I've had the pleasure of working with some fairly large concurrent codebases and the character-building experience of tracking down deadlocks, random memory corruption bugs that turn out to be race conditions, and (my most favorite of all) unexpected serializations that randomly bring programs to a halt. Most of that experience has been in C++, with a little C and a little Java mixed in there. Over & over…

> 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 goroutines were supposed to make concurrency issues a thing of the past).

I am not saying that Go channels don't help the situation at all--and the inclusion of a race detector doesn't hurt either--but you still have plenty of ways to shoot yourself in the foot. The thing that probably helps most is that GOMAXPROCS is 1 by default, since data races are a multicore phenomenon in Go.

Post reply on HN