fizzbatter
Joined 12 years ago
Karma
798
Submissions
350
Member since
Oct 14
Recent submissions
Comment · 10 years ago
Comment · 10 years ago
This is really awesome! You should make a phone app (Android too please :)), i'd happily pay for this to make wallpapers!
Comment · 10 years ago
All i see is black - is that intended? Not sure if that's my color, haha.
Comment · 10 years ago
At the very least Nix would make your Docker builds more reliable. Granted, you could then start making arguments for "why use Docker at all", but i can't answer that.
Comment · 10 years ago
I can't wait for someone to write a great book on Nix. I was so lost in it. I had it running on my home server, and needing to compile my own things because of what Nixpkgs lacked was a constant struggle.
It was a very frustrating experience. A frustration which was led by the fact that i could tell how powerful Nixos was - if only i could grok it.
Comment · 10 years ago
If you need more complex logic, you simply wouldn't use `try!()`. Try! is intended for those `if error then return` checks, just like with Go's `if err != nil { return err }`.
If the error needs to be checked for a specific type (like a timeout) and then retried X times, you don't use the simple `if err != nil {...}`, you hand write something:
let barRes = try!(foo()).bar();
match barRes {
Err(MyError::Timeout(_)) => // .. some retry code
}
edit: Man, the guy (or wo-guy) has a problem and we all pounce :)
Comment · 10 years ago
> plus it can catch things compilers don't, such as null pointer exceptions.
Note, that it depends on the language. In the case of Go, yes. In Rust? Definitely not.
Comment · 10 years ago
> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.
Agreed. It may be safer in the realm of "oops i forgot to free memory", but i've had more panics than i could count in Go.
Comment · 10 years ago
Not only that, but there's simply no guarantees. You can abuse a function in any way you see fit in Python, and the only one that suffers is your runtime sever :(
Optional types in 3.5 look awesome - but i don't want to lose duck typing. I want Go-interfaces in Python.
Comment · 10 years ago
I don't know how, but frankly i'd love to eliminate all simple panics. Nil pointers and channels seem two big culprits, offhand.
Granted, i left out nil pointer/interface panics because it seems unrealistic given how difficult it was for Rust to get rid of nil pointers. I'm not sure Go 2.0 could do it and still be considered Go.
Comment · 10 years ago
Type safety mainly, i think. Performance is a definite concern, but they have a lot of internal applications and the stability of them varies. I offered up that less dynamic languages would provide more speed and reliability to boot.
I know Python got types in 3.5, though i'm not sure if it has Go-like Interfaces (Traits in Rust). If not, i think it really should.
I do firmly believe they'll be quite happy with Go though. Rust, not so much.
Comment · 10 years ago
I had to pick something i was familiar with too. We need this on a shorter timeframe (when is that not true? haha), and evaluating a language is hard.
As it is, this was a partial reason against Rust for me. After my time learning Rust, i'm still not 100% confident in my ability on it. My lack of experience and thusly productivity-hit is a real factor i had to calculate. Moreso with the rest of the team.
With Scala/etc i would be learning it new myself, and it was a gamble i wasn't going to take. Especially because our application is not intensive to specific problems that some languages excel in (concurrency, etc).
I'm sticking my neck out choosing a language, so i wanted to be quite sure i make the right choice for us. Well, as best i can - i am new in this shop after all.. i hope i made the right one :)
Comment · 10 years ago
So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding.
Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they weren't too happy with it.
For weeks (literally) i mulled it over, i really really really wanted to use Rust. Rust gives me a peace of mind that Go never came close to. Unfortunately, Rust does not fit the development speed nor developer experience[1] that this shop has.. and i really felt Go would be the best choice for this place.
My point to this post isn't to make a Rust vs Go comparison.. but rather, a wishlist for the hopefully eventual Go 2.0. I have no idea if/when that will ever be made.. but i hope it will, and i hope they adopt some things from Rust.
1. Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program.
2. Proper error handling. I love error checking - i love it in Rust especially. It's very explicit, and most importantly, very easy to check the type of things. Recently i was reading an article about Go errors[2] and it made me realize how messy Go errors are. There are many (three in that article) ways to design your error usage, and worst of all your design doesn't matter because you have to adapt to the errors returned by others. There is no sane standard in use that accounts for the common needs of error checking.
3. Package management. It's a common complaint, i know. But Rust & Cargo is so excellently crafted.. Go just got it wrong. Recently i've been using Glide, and while it's a great tool, there is only so much it can do. It's a tool built to try and put some sanity in a world where there is next to no standardization. We need a Go package manager.. hell, just copy Cargo.
4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust.
You'll note that i didn't list Generics. I know that's high on peoples list, but not mine. To each their own.. please don't start a holy war. (this is likely due to me using Go for ~4 years. I'm quite comfortable without Generics)
[1]: By experience, i mean what they desire/expect. They're a Python shop after all, i didn't want to make a choice that would cause them to spend weeks/months feeling unproductive. [2]: http://dave.cheney.net/2016/04/27/dont-just-check-errors-han...
edit: minor text fixes.
Unfortunately though, i'm back on Go. I want to be on Rust, but i had to pick a language for work and i can't ask my Team to go through what i did. Rust, despite the safety, is too unnatural for our larger codebase.
Luckily i think Rust has seated itself as the language we will use if the need is truly there. Unfortunately though, not everything.. just the specific things that need it.