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

271–280 of 311 posts

Re: Rust and Go

#271

Post by waps »

e12e wrote: post #163
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…

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

> encourages breaking large systems into small services

That's as much of a curse as it is a blessing. To some extent, small services are handy for dev/ops type folks, as they can quickly see which specific part of an application is misbehaving with memory or cpu or diskspace, so they like it.

But small services means that you lock down the interface between parts of the system by using another language to specify the communications protocol (e.g. protobuf, json, ...) and 2 different codebases have to understand it. And even if you manage to get the code to change, now you have the problem of migrating the running program.

In other words, the interface is now set in stone. Nobody will ever touch it again. This is exactly what you do not want to happen. Small services are the enemy of large, flexible programs.

Contrast this to Java/C# (and, somewhat less perfectly, C++) and their refactoring tools. What a difference. Changing an interface is something that is mainly done by computer code, not by a programmer, and all parts are modified and all problems identified.

There are points where this is not a problem, like a file system interface, or a socket interface, that sort of thing (and even there you may change your mind ...). Places where flexibility is not needed or wanted (I would argue, looking at linux file systems, that the POSIX API is not, in fact, a good API for quite a few file systems, but looking at the kernel I can see why this is not going to change. Of course, half the distributed file systems are user space libraries, partly for this reason). This is exactly the sort of thing C programmers deal with.

Re: Rust and Go

#272

Post by waps »

_bpo wrote: post #138
desdiv wrote: post #135

Earlier quoted context omitted.

indent goes well beyond indentations too, despite the name :)

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)

Re: Rust and Go

#273

Post by waps »

zzzcpan wrote: post #240
Alphasite_ wrote: post #233

Earlier quoted context omitted.

And even Java is getting that.

Too late. Also Java is not as easy to learn and to use as Golang.

Too bad you can't unlearn functional programming. Or generic programming. Or algebraic datatypes. Or having actual useful datatypes. Or ...

Just the basic thing of sorting a list containing a struct. And the suggested solution by the Go team is a 50 line program. WTF.

They actually claim the err = function(); if err != nil {}. This is the reason I originally left C. And those criticisms really apply to Go as well. Firstly nobody sanely checks those errors, often outright ignoring them. Second when they do, they always just pass the error up (in other words: manually implementing exceptions), or worse, they panic on the error (meaning you cannot trust external libraries won't panic on you, negating the single advantage that leaving out exceptions had). Even if you do check those errors they interrupt the train of thought you have. Imagine someone telling you how to open a door in Go : first, put your hand on the handle. If you don't have a hand then go to the hospital. If there is no hospital near you then go to the car. If there is no car then check for a bike. If the door is locked ... wait what was I doing ?

Thirdly functions that might return a variable or might not ... the official Go team's advice is use a pointer. Sigh. The amount of times I've seen people commit Go code into my program that doesn't check for nil-ness ... Grrrr.

If you don't mind living in the dark ages, then yes, Go is great.

Re: Rust and Go

#274

Post by NateDad »

nhaehnle wrote: post #190
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…

Another aspect that makes me hopeful about Rust as a way forward for C++ programmers is that it is designed to play well with the C (if not C++) ecosystem. Go is in this weird place where they insist that you have to be 100% Go or not at all, at least with the official Go package (gccgo is different, but this divergence in the ecosystem doesn't exactly inspire confidence). This is convenient when you have small isola…

Uh... Go plays very well with C and C++.

https://dennisforbes.ca/index.php/2013/07/23/the-most-powerf...

Re: Rust and Go

#275

Post by NateDad »

waps wrote: post #271
e12e wrote: post #163

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

> encourages breaking large systems into small services That's as much of a curse as it is a blessing. To some extent, small services are handy for dev/ops type folks, as they can quickly see which specific part of an application is misbehaving with memory or cpu or diskspace, so they like it. But small services means that you lock down the interface between parts of the system by using another language to specify th…

One of go's strengths is how easy it is to refactor. Implicit interfaces means that you can change a function to take an interface, and the caller who is passing in a concrete type doesn't have to get updated at all.

also, there's a relatively recent tool created called gorename that does 100% type-safe renaming.

Plus there's been gofmt and gofix for forever which you can use to automatically rewrite your code.

Finally, because almost all go code is formatted with gofmt, you can often do simple find and replace changes because all the code is completely regular.

Re: Rust and Go

#276

Post by NateDad »

kxo wrote: post #252
NateDad wrote: post #200

Earlier quoted context omitted.

And that's why I like go. Sorry, that's not really fair. I'm sure the compiler would have caught that when you tried to feed it into something that wanted a vector (or would have not cared if you were just iterating over it). To be honest, I think Rust has a lot going for it. I just think Go has a lot going for it too... they're just different things. Which is fine, because if everything were the same, the world woul…

Are you suggesting the Rust compiler didn't catch that?

No? I don't actually know rust, but I don't think the first thing he typed was invalid code. It just returned an iterator instead of a vector. I was suggesting that when he tried to pass the variable into a function that expected a vector, the compiler would complain. No snark, I just meant what I said.

Re: Rust and Go

#277

Post by NateDad »

alkonaut wrote: post #44
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. :)

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…

Is there a reason you need some built-in map thing and not just user-defined functions? If a loop is too hard to read inline, you slap it in a nicely named function and now it's more clear and more concise. Either way, you have to write the code to do the conversion. select(odd) doesn't work unless you've already written the code behind whatever "odd" is, for example.

I can write go code that makes this line legal:

    odd_ints := parseInts(myStrings).select(odd)
but I'd probably write code so it looked like this:

    odd_ints := odds(parseInts(myStrings))
Is either of these harder to read? Does it matter that parseInts is a "map" and odds is a "filter"? Their function is obvious by their names. If anything, the words "map" and "filter" are extraneous.

Re: Rust and Go

#279

Post by NateDad »

grogers wrote: post #160
zzzcpan wrote: post #72

Earlier quoted context omitted.

There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra. But no matter how I dislike it there is just no other choice today. It all comes down to support, bug fixing, ease to learn and to use, good standard library, built in cross-compilation and a pretty fast one, static binaries, good enough dependency management, reasonable performance and memory usage, espec…

Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things. The other choices are certainly there.

Except for "reasonable memory usage".

Re: Rust and Go

#280

Post by NateDad »

TheHydroImpulse wrote: post #50
andolanra wrote: post #20

Earlier quoted context omitted.

The plan is to release 1.0 around the end of the year. In that sense, Rust isn't done, but it is near done.

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…

The stability guarantee given by rust is what scares me the most about starting up with it. "with a minimum of hassle" is really squishy language that is not at all comforting. Compared to the Go 1.0 promise: Your code will not break, period.
Post reply on HN