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

281–290 of 311 posts

Re: Rust and Go

#281

Post by NateDad »

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…

What is to "implement" in FindValueInArray?

    for _, x := range foo {
        if someCriteria(x) {
            // do something
        }
    }

Re: Rust and Go

#282

Post by waps »

NateDad wrote: post #275
waps wrote: post #271

Earlier quoted context omitted.

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

> One of go's strengths is how easy it is to refactor

Give me a minute to collect my jaw of the floor here. Nope ... need some more time. Unless you mean in the same way as C and pascal are easy to refactor, I disagree in the strongest possible way. I may conceed to a very limited extent. While Go and it's tools don't allow refactoring, due the static nature of Go, it's actually possible, through careful design and constantly putting extra effort in, to make sure that it's reasonably easy to refactor. As long as you stay away from using interfaces, use long and unique enough names for your variables, make sure no variable names are substrings of other variable names, have a convention for polymorphic method names (ie. Matrix.MakeWithFloatArray(), Matrix.MakeWithIntArray(), Matrix.MakeWithZeroes(), ...), ...

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

Yes because that's what refactoring is ... what you're showing here is called "polymorphism", and Go "doesn't support it" (except when it does, like as you point out here, in interfaces, oh and in range, make, new, append, close, copy, delete, imag, len, print, println, real, go, defer, most of which are also generic and polymorphic in really, really bad ways (some have completely unrelated and surprising behavior when passing different types to them), and I doubt I've got all of them).

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

I have tried that tool. It only does a single file. Again that makes it not refactoring. Just so we're clear. Here's the definition of refactoring :

  Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior.
Which is not what those tools do. Change the name of a method ... boom 5 objects don't satisfy the interface they did 5 seconds ago anymore. Change the name of an interface ... doesn't change in all other parts of the code. Change an exported variable ... everything fails to compile.

Next major point of criticism of the go tools. When do you want to do refactoring ? Well, during development. Of course in order to refactor during development, when 2-3 of your program's files don't compile, you obviously cannot use a normal compiler to refactor, since it won't understand the program. While this is not technically part of the definition, it frustrated me to no end the first, and last, time I used gofix to attempt to refactor something. Me and vim are faster at refactoring a 10000 line Go codebases than gofix + cleaning up after it is. Gofix knows a cute trick with symbol tables that is 1% complete (because making it functional will require a full rework of the Go compiler), which is not refactoring (since it doesn't look at the full source tree), and it will require a rework of Go itself (I'm not yet positive, but I think that because Go works with implicit interfaces, it is not actually possible to refactor anything related to object methods or interfaces correctly).

Re: Rust and Go

#283

Post by grey413 »

steveklabnik wrote: post #113
StevePerkins wrote: post #111

Earlier quoted context omitted.

"What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week." Huh? I'm seeing comments in this thread about people using Rust right now in production . How... why... what?!?

There are two big deployments and some smaller ones. The two big ones are OpenDNS and Skylight.io. We don't recommend it currently, but some people are just eager. :)

I would venture to guess that those organizations feel that the pains of working with a prototype is worth the payoff of shaping the final product (not to mention the immediate advantages of rust's already stable safety features).

Re: Rust and Go

#284

Post by jacques_chester »

dbaupp wrote: post #257
jacques_chester wrote: post #208

Earlier quoted context omitted.

Have you rung up the GPU manufacturers to tell them that they're wasting everyone's time?

The synchronisation/set-up overheads are still fairly large (e.g. communicating with the GPU). I find it rather unlikely that e.g. a map over 20 elements will be faster in parallel.

It might not be. But I am happy to ignore the question and leave it to the compiler or runtime to take advantage of easy parallelism. Maps allow that, loops (or any other sequential treatment of data) doesn't.

My personal brand of bigotry is relational databases, so I am accustomed to thinking of sorted / ordered behaviour as the special case. Thinking in sets is very powerful.

It doesn't have to be either/or. Sometimes you need a loop. But it would be nice to have mapping too.

Re: Rust and Go

#285

Post by the_why_of_y »

pjmlp wrote: post #238
coldtea wrote: post #206

Earlier quoted context omitted.

Well, a counter point then can be: and why did those vendors did not insist on Smalltalk? Why weren't Smalltalk more heavily pushed by some big vendor itself? It's not like SUN was the only player in town. IBM pushed Smalltalk IIRC. I think this (from StackOverflow) tells a more comprehensive story): • when Smalltalk was introduced, it was too far ahead of its time in terms of what kind of hardware it really needed •…

I used VisualWorks at the university in 1995, just before Java appeared and there were presentations with broken Java code[1]. Eclipse 1.0 was Visual Age for Smalltalk redone in Java. If Java hadn't appeared in the scene, maybe even with those cat fights, the language would have become mainstream anyway. This just speculation from my part. [1] The famous "private protected" that was accepted in the very first release…

Technically, Eclipse was Visual Age for Java [only implemented in Smalltalk] redone in Java :-)

Re: Rust and Go

#286

Post by kibwen »

rdtsc wrote: post #258
gnuvince wrote: post #213

Earlier quoted context omitted.

How does Rust's borrow checker cause a slowdown of sequential code? It's a purely compile-time construct and allows for the elimination of a GC, so it's actually a net win in code execution speed.

> How does Rust's borrow checker cause a slowdown of sequential code? It doesn't, it was just grouped with the other two. But immutiblity-by-default could lead to slowdown.

Not at all. In languages that are thoroughly immutable, it's copying, not immutability, that has a runtime cost. Rust has mechanisms for avoiding these costs (moves and mutable references).

Furthermore, since the compiler's knowledge of mutability is directly related to its knowledge of ownership, one could argue that immutability actually makes code faster by dint of providing greater aliasing information (e.g. `restrict` in C) to the optimizer (though the Rust compiler has yet to actually leverage this optimization).

Re: Rust and Go

#287

Post by codezero »

LunaSea wrote: post #188
bad_user wrote: post #30

Earlier quoted context omitted.

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…

By learning new programming languages or frameworks you stand out from the crowd. Guess who's going to get a job: A) The fool who just learned JavaScript and Angular.js B) The university student who only knows Java The answer will be (A) every single time because companies don't have the time to train people for months.

This hasn't been my experience in practice but I guess it depends on what kinds of companies you've worked with.

Everywhere I've worked, they hire engineers based on a lot of factors, and it has been more often the case that they'd go for someone who knows a different stack really well, than someone who knows all the newest stacks.

Re: Rust and Go

#288

Post by steveklabnik »

grey413 wrote: post #283
steveklabnik wrote: post #113

Earlier quoted context omitted.

There are two big deployments and some smaller ones. The two big ones are OpenDNS and Skylight.io. We don't recommend it currently, but some people are just eager. :)

I would venture to guess that those organizations feel that the pains of working with a prototype is worth the payoff of shaping the final product (not to mention the immediate advantages of rust's already stable safety features).

Yup. I know much more about Skylight's case, but this is exactly true.

Re: Rust and Go

#289

Post by yohanatan »

emmanueloga_ wrote: post #266
bjz_ wrote: post #165

Earlier quoted context omitted.

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.

That may be true but I find it curious. Without knowing too much about Rust, it looks like a lower level language than Haskell. I'd have thought that someone would pick the higher level language first, and go to the lower lever when in need of more control.

Rust is not your typical lower-level language though. It supports a lot of the features that functional programmers expect. It is an eagerly evaluated language that lets you drop to 'unsafe' code where necessary but in its natural form, it is surprisingly high level.

Re: Rust and Go

#290

Post by kibwen »

NateDad wrote: post #276
kxo wrote: post #252

Earlier quoted context omitted.

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.

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`"?
Post reply on HN