Rust and Go
medium.com
Rust and Go
1–10 of 311 posts
Re: Rust and Go
#2I 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 this way though as there's no evaluation of some of the larger reasons Go exists, like concurrency and and fast compile times. Then again, most people probably don't even need/care about these.
Re: Rust and Go
#3I 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…
Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed).
Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.
Re: Rust and Go
#4I 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…
[deleted]
Re: Rust and Go
#5I really like the idea of testing a language by writing a small command-line utility with it, even one that -- as the author mentioned -- already exists.
Way back when, when I first was learning C, I didn't comprehend it very well. I was OK with it. A friend gave me some CDs with FreeBSD on it, one with the OS, and one with program sources. It was that source code which really opened my eyes, and you could digest small programs (like chmod) and see, you know, this is working, production code, and it's not hard, and you can do this.
Re: Rust and Go
#6I 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…
Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.
I agree that it's great to learn a language, I was thinking of this as more of an exercise to generate a good post, but it's probably more reasonable to assume he really wanted to learn Go :P
Re: Rust and Go
#7Does '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 illustrates it.
Re: Rust and Go
#8I 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.
Re: Rust and Go
#9Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great.
I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big ones I wish Go had were named parameters on functions, and immutable data structures.
It's probably a blub paradox thing, but my ideal language has immutable data structures and named function parameters. Kotlin, Scala, and Swift all kind of nailed these features, but Go has not.
For me, named parameters and a little verbosity goes a long way to allow me to communicate intent in my code. Immutability allows me to have a built in sense of safety that once the data is set, it stays that way.
In my experience, a whole class of problems goes away when you have those two features (alongside the many other features we'd expect form a language like Go).
What I felt from Go is that a year ago when I was playing with it, that they didn't care much about either of those two features, which is fine, but it keeps go from being my ideal language.
Swift I wish was a bit more general purpose, Kotlin and Scala don't compile as fast as Go, and Ruby doesn't have a compiler to do some of the checking I wish it would.
Go's fast compile times with something like Ruby's syntax and a feature set similar to Kotlin/Swift would be darn near perfect.
For me, there is no perfect language.
Re: Rust and Go
#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