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

161–170 of 311 posts

Re: Rust and Go

#161

Post by pjmlp »

melling wrote: post #102
TheHydroImpulse wrote: post #50

Earlier quoted context omitted.

Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done". "It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But…

Go updates twice a year, which is actually a lot. I don't think a release every 6 weeks for Rust is a good idea. That'll never fly for enterprise software. Heck, for some companies the Java upgrade cycle is too fast.

At Java ONE MongoDB developers mentioned they have clients still running on Java 5, thus they cannot fully embrace Java 8 for the time being.

Re: Rust and Go

#162

Post by jaytaylor »

rdtsc wrote: post #125
tptacek wrote: post #76

Earlier quoted context omitted.

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…

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex?

    func (*Mutex) Lock

    Lock locks m. If the lock is already in use,
    the calling goroutine blocks until the mutex is
    available.
http://golang.org/pkg/sync/

It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

Re: Rust and Go

#163

Post by e12e »

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…

>>(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 might be moving the goal posts a bit here, but I think go's C heritage, and focus on message passing -- possibly coupled with something like protobuf or similar -- encourages breaking large systems into small services. So if you view a system as a "sum of functionality" -- I think one might still use go for "large, yet maintainable systems".

Now, it is of course possible to write micro services both in C++ and java -- but historically it appears at least in the java world, you end up throwing everything into a massive jboss container, exposing yourself to thousands upon thousands of lines of code.

With go, you deploy (relatively) small binaries, and a service can live as 20 binaries on one box, or as 20 binaries (along with some load balancers like haproxy or what not) across 300 machines. Or something in between.

I'd argue that some of the more sane java frameworks and projects also revolve around simplicity and separation of concerns -- typically leading to micro services. But a lot of people seem to end up working with large, poorly architectured beasts. That's probably more of a culture thing, than a language thing -- so I think people will make huge swats of unmaintainable go code as well...

Re: Rust and Go

#164

Post by nostrademons »

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

If you consider C++'s standard toolkit to be Clang, Clang comes with clang-format.

Re: Rust and Go

#165

Post by bjz_ »

yohanatan wrote: post #159
eridius wrote: post #40

Earlier quoted context omitted.

I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I'm hoping that as Swift evolves over time, it will slowly become that sort of language. Right now it's pretty hard to write any rea…

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many oth…

I have definitely heard from multiple people that for them Rust was a good stepping stone to Haskell. Hopefully it will be the same way with Swift.

Re: Rust and Go

#166

Post by hit8run »

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

Just use int and it works fine: http://play.golang.org/p/nZcd3M5aL_

To me golang is readable while even small rust examples don't feel quite right right.

Re: Rust and Go

#167

Post by axaxs »

Jweb_Guru wrote: post #60
tptacek wrote: post #54

Earlier quoted context omitted.

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 gorout…

I feel this is a symptom of people coming from dynamic, higher level languages, who may or may not have ever really learned concepts of CS, "switching" to Go for performance reasons. I don't intend to insult anyone or certainly the authors of the above. Go is type safe but doesn't keep you from shooting yourself in the foot. You NEED to read the spec to understand when sharing memory is generally OK. I'm glad not to be penalized in performance or boilerplate to accomplish this. The downside, of course, are stories like the above. I don't blame the language here, though. They give you the tools to be safe. Getting away from automobile analogies, let's try woodwork. I can give you a drill, a drillbit, a screwdriver, and a screw. Sometimes you should know when to make a pilot hole, and when it's ok to forego this. But folks looking for 'performance' or 'ease of use', or folks who come from languages that just give you a nailgun, will inevitably split the wood a few times.

Re: Rust and Go

#168

Post by nostrademons »

jaekwon wrote: post #97
alkonaut wrote: post #44

Earlier quoted context omitted.

A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc). The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly. E.g this expresses…

Ok, that's a good example. Your one-liner is pretty concise and the intent is clear. I think on a higher level with complex code, you definitely want better abstractions to convey intent, rather than say just having one large function that does everything. I think in many cases map/filter does in fact help with readability of intent, especially if you're not declaring the function body inline, and the functions are c…

Another data point for you (I'm not the grandparent poster):

I prefer to write exploratory code and spec out the design as I go along, and I also prefer map/filter (or list comprehensions) to for-loops.

I suspect it does have to do with coding style, but not in the way you suspect. I like to write very small functions - often one-liners, rarely more than a page - and have each function do one thing and one thing only. I also tend to code mostly bottom-up, figuring out what abstractions I need, writing them, and then writing the functions that use them. So I almost never use an inline lambda for a map, it's usually a function I've already defined.

All of the exploratory scenarios you list are handled by built-in functions in my language of choice (Python). Breaking out early = itertools.takewhile(). Using the index = enumerate(). Inserting the log lines, I'd just insert them in the mapper (although there's also trace).

Re: Rust and Go

#169

Post by rdtsc »

jaytaylor wrote: post #162
rdtsc wrote: post #125

Earlier quoted context omitted.

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…

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex) Lock Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available. http://golang.org/pkg/sync/ It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

> is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex?

Well aside from the deadlock or priority inversion of sorts that should work. Just like it would work in C/C++/Java etc.

The real problem is when the shared data is not controlled by a mutex, but should be.

Re: Rust and Go

#170

Post by Animats »

jaytaylor wrote: post #162
rdtsc wrote: post #125

Earlier quoted context omitted.

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…

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex) Lock Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available. http://golang.org/pkg/sync/ It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

In most languages, the language says nothing about what data is protected by the mutex. Modula and Ada did, and Java has "synchronized" objects, but C/C++/Go lack any syntax for talking about that. This typically becomes a problem as a program is modified over time, and the relationship between mutex and data is forgotten.
Post reply on HN