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

11–20 of 311 posts

Re: Rust and Go

#11

Post by Dewie »

jeorgun wrote: post #7

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustra…

> Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given.

Of course any function can be forced to crash by inserting some crash-inducing code into the function. You can always make a function that assumes that value is of a certain form, and crashes the program if it is not (like unwrap for extracting a value from an Option, or crashing if it there is no value). In order to have "code that works if it compiles" (comparatively speaking; often used as an exaggeration), you have to have the discipline to use the facilities that the language provides you.

I guess a language would need some kind of totality checker in order to make sure that you couldn't make function diverge in some way. Like for example Idris has.

Rust also has the `!` type, aka bottom, for marking functions that diverge.

> So far as I know the fail! macro still exists in Rust.

What should that do? Crash the program? If so it should have been renamed to something like `panic!` now, since "fail" now is associated with Error types, while "panic" is associated with crashing the program/exceptions.

Re: Rust and Go

#12

Post by amelius »

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

Re: Rust and Go

#13

Post by burntsushi »

> 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

Re: Rust and Go

#14

Post by sswezey »

jff wrote: post #10

"Where line 9 there just blindly assumes the regex found a match, and causes quite the run-time error message." You blindly assume the regex found a match, because you ignored the part of the docs where they tell you how to check for a match: http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch

The article didn't say there was no way to check, just that the compiler does not enforce checking. Rust's type system requires that all possible paths are accounted for when trying to extract the value from the option.

Re: Rust and Go

#15

Post by curun1r »

jeorgun wrote: post #7

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustra…

I think it means having a proper type system (though perhaps not as complete as the one in Haskell). In the example given, the compiler was able to signal the possibility of an error because the type system could represent None as a possible return.

Go's type system is, by comparison, pretty minimalistic. In the example you mentioned, Go would rely on you learning to write idiomatic Go code to check the value of the returned error. If you skip that step, Go will happily crash and burn as you try to do something with the nil value returned alongside the error.

Re: Rust and Go

#16

Post by crazypyro »

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

From my experience, not even close, if only because the ecosystem around it has to continuously update their own resources/libraries or risk being left behind every new patch because the language is not even at a stable 1.0 point.

Trying to figure out new things tends to be an exercise in reading obsolete code examples and then asking for someone in #rust on irc.mozilla.org to translate. Stuff that gets deprecated isn't well documented in my experience and one of the best resources I came across (Rust by Example) also contains a lot of out of date or deprecated features.

Obviously, this is a side-effect of a rapidly evolving language that is still in pre-1.0 phase, but anyone going into it should be aware of the potential breakage that tends to happen at a fairly high clip at the moment.

Re: Rust and Go

#17

Post by alkonaut »

If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics.

Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...

There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.

Re: Rust and Go

#18

Post by vertex-four »

jeorgun wrote: post #7

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustra…

> Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'?

No, it means there's memory safety and a strong type system. Unless you specifically and explicitly break that, the language prevents you from doing things like accessing undefined memory or returning nulls where you haven't explicitly said you can return nulls, and the strong type system allows libraries to prevent you from accessing closed resources.

People say Haskell prevents lots of classes of errors at compile time, and yet even that has escape hatches. panic!() shouldn't be a part of idiomatic Rust code, it's primarily for use during initialisation, small scripts, and the odd place where an application design would be a pain to deal with if it had to deal with a one-in-a-million chance that something particularly odd happens, and the application can't continue if it does.

Re: Rust and Go

#19

Post by vertex-four »

Dewie wrote: post #11
jeorgun wrote: post #7

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustra…

> Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. Of course any function can be forced to crash by inserting some crash-inducing code into the function. You can always make a function that assumes that value is of a certain form, and crashes the program if it is not (like unwrap for ext…

fail! has been renamed to panic! for much that reason.

Re: Rust and Go

#20

Post by andolanra »

melling wrote: post #8
codezero wrote: post #2

I was worried when I saw "I decided to write a little Rust and, because everyone in my world is seems swoony over it, Go." That's a pretty bad reason for using a language and usually leads to some pretty ridiculous criticism. This post was not that, I think they nailed a lot of the good and bad things about Go, in fact, they could have been a lot more harsh. There is a depth lacking in just checking out a language in…

I'm under the impression that Rust isn't near done and ready for production use. Go has been ready for a couple years. Rust could be 10 times better but I'm not going to touch it until they ship 1.0.

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.
Post reply on HN