4 ms·

If something is supposed to work 100% of the time, it won't have an error return value. Otherwise there's a nonzero chance it'll fail. The time you spend writi

• oelmekki 12y ago
  > The time you spend writing a simple "network configuration file must exist" is way less than you'd spend trying to read a stack trace when your application crashes with "filenotfound: foo.json". Well, stacktrace and enforcing meaningful message error where they are generated is fine with me, but I see what you mean. Certainly, if we were to think of custom message everywhere a problem may happen, it will be easier to debug. But does it really worth it ? > If Go is 1/5th as productive as Ruby [...] All assertions probably apply :) I began to learn and use ruby (even if not professionally at first) before rails was a thing, so I'm quite used to it. On the contrary, I've began to use go only a few weeks ago. It took me a week during a week off (with the slow pace it implies) to learn the language and re-implement that task I thought was a perfect fit. So yeah, that's indeed very productive, and that's what I was attracted by in the first place. I also probably have done horrible mistakes that would have make this time shorter, since I'm still learning the language. But let not underestimate ruby here, and more importantly : its ecosystem. Certainly, if I had to use only ruby standard library, it wouldn't have been that fast. But with the help of activerecord and activesupport, things suddenly get really fast. After learning to use database/sql, I've searched for something allowing me to save time, and switched to coocood/qbs. It helped a lot (especially on managing connection pool to postgres, since I was parallilizing queries), but of course it can't compare with something that mature than activerecord. That's not intrinsic value of the language, but it clearly affects what it means to write a feature using the language in term of time. > I honestly don't understand how you can only care about 10% of errors Well, I guess it depends on what kind of software you're writing. If I were to design a public facing server app, certainly, the last thing I would like to happen would be it to panic and quit. In my previous case, I was rewriting a non-destructive data processing background job, called by cron. If it fails, cron will mail me with details and try again later ; that's perfectly fine. But let not be mistaken on what I mean by "I care about 10% of errors". It does not mean I don't want to know there were errors the rest of the time. It means that I don't want some specially crafted logic handling it to ensure data / runtime state. Having the program interrupted and a report made with error message and stacktrace is ok most of the time (for the rare occasions when it happens). Let take some actual examples. A table in my database has an hstore field, which represents in application what we would call in go a `map[int] int`. Except that in hstore, all is string, actually. So in my go code, I have : key, err := strconv.Atoi( hkey ) I can understand why this function generates error, and that's a good thing, conversion to int may fail. But in my case, I know for sure I have a numeric string. So yeah, certainly, someone may introduce a bug somewhere sometime that will put a non numeric key in the hstore. But the low degree of probability for this makes me ok to deal with a message like "can't convert 'foo' to integer" with a stacktrace showing the line number when it happens (and indeed, once again, this instruction is followed by `if err != nil { panic( err ) }`). An other example is database query functions. They all return an error, in order to relay database errors and connection to database errors. That is fine, this is information I want. But do I really need to add chunks of logic testing for those after every single query I make ? Again, having a default "raise and die" handling, with a few chunks of logic to ensure data integrity where it's at risk (on writings, for example) would be enough.