NateDad

60 ms·

571.
by NateDad 12y ago
I think you'd do better making the stages into plain functions that take an interface... why do the stages need to be structs at all?
572.
by NateDad 12y ago
This is honestly kind of a dumb question, because the answer depends on who is asking the question. Object oriented has become such an overused and little understood term, that you can't just give an answer without trying to discern w
573.
by NateDad 12y ago
For some things. For many things they are pretty equivalent. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... And Java uses a lot more memory, which is what the article was talking about adversely imp
574.
by NateDad 12y ago
You couldn't write a generic tree that packs the ints closely together, no. But you could write a non-generic tree that does. Also, Dave was talking about Lists, which you certainly can have packed with ints trivially in Go. And ever
575.
by NateDad 12y ago
For pure processing speed, Go is pretty comparable to Java for code that does not heavily rely on generics. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... What Dave's presentation mentions is the
576.
by NateDad 12y ago
Except that the caller can't tell what failed - was it file.Open, or was it callFunctionThatMightErrorOut? They both just cause the same FailedToReadConfigFileException, so you've made it impossible for the caller to react differ
577.
by NateDad 12y ago
I have never ever had to request a chargeback from my credit card company. I have, however, returned many items which were voluntarily refunded by the merchant, even those items paid with cash or cash equivalent. But then again, I also do
578.
by NateDad 12y ago
I've read a ton about bitcoin and own some and have mined some... and this is the first I've heard of it. Keep in mind, there are a few different types of people interested in bitcoin: 1.) Get Rich Quick types 2.) Techies 3.) Craz
579.
by NateDad 12y ago
OK, so I don't think we're disagreeing at all then, except possibly about the difficulty / commonality of writing the correct exception handling code.
580.
by NateDad 12y ago
The whole point is that exception handling code, when written robustly, looks almost like Go error handling code. That or you need to write a TON of magic cleanup classes which take a lot of time, are even more error prone, and less flexib
581.
by NateDad 12y ago
Haha, fair enough. But I was trying to write standard code that you'd see in many popular languages, whose proponents often complain about Go's error handling.
582.
by NateDad 12y ago
"Good exception handling style in languages with sane exceptions normally means almost never catching exceptions except for high level orchestration routines; reacting to unwinding by cleaning up resources; and generally taking a trans
583.
by NateDad 12y ago
There are a lot of error handling libraries out there. On Juju, we're working on one right now. This is the preliminary version: https://github.com/juju/errgo Basically you just call a function every time you wo
584.
by NateDad 12y ago
RAII can get rid of that one try/finally, that's true. I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches. Here's what you get if you have some magic RAII file-close
585.
by NateDad 12y ago
This is true, you can drop all return values. However, a lot of functions return a value and an error. If you want to access the value, you need to assign the error to something too. And if you don't then use that error, the compile
586.
by NateDad 12y ago
I'm saying that most people who complain about Go's verbosity do not take resource cleanup into consideration. They think they can let exceptions fly without any try/catch or try/finally and everything will be fine, whic
587.
by NateDad 12y ago
That's a very good point, actually. It's tricky, because always requiring the latter format is burdensome, especially if the zero value of the map is an ok value for you...
588.
by NateDad 12y ago
Here's why Go's errors are better than exceptions: Multithreaded environments make exception handling next to impossible to do correctly. The stack trace only shows a single thread which is often useless without more context. Ex
589.
by NateDad 12y ago
Saying exceptions are for exceptional situations is an old fallacy (one I used to believe in). Exceptions are errors. Errors happen all the time. They are not exceptional.
590.
by NateDad 12y ago
So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged. There are linters which will tell you when you forget to check an error code. You say that unhandled errors can cause data corru
591.
by NateDad 12y ago
"In order to ignore error codes in go, you must do so explicitly". - FTFY
592.
by NateDad 12y ago
For tiny programs you use yourself "blowing up" is fine. For code in production, it's probably not. Thinking about what can go wrong and writing code to handle it ahead of time is a large part of software engineering. If th
593.
by NateDad 12y ago
I don't know what codebases this covers, but GOOD Go code does not panic.
594.
by NateDad 12y ago
Don't panic in the middle of your code. You can occasionally use panic during init() when it indicates a programmer error. Otherwise, just return an error.
595.
by NateDad 12y ago
Yes, we're saying the fundamental core of Java is an anti-pattern. Exceptions are dangerous. At any point in a function, you can suddenly jump out of that function due to an exception. It's certainly possible to write correct
596.
by NateDad 12y ago
I've seen many projects outsourced. Exactly zero were successful. In fact, all of them required a total rewrite after getting the final product back.
597.
by NateDad 12y ago
You should use Go for a while. It's very productive. Lean and mean and gets out of the way of the developer. People call it a lowest common demoninator language as a way to dismiss it, but it's actually incredibly well thought ou
598.
by NateDad 12y ago
Getting the modules and making the tree is easy. Making the code work is hard. Yes, sometimes this will work... but if A passes an object from v1 into B and B passes that object into v1.1... that can blow up. If v1 and v1.1 both use any g
599.
by NateDad 12y ago
Then you're narrowing your hiring pool. Hiring is hard. Hiring really good people is really hard. Removing the requirement of "has 10 years of $LANGUAGE" is pretty awesome. It means we can hire someone because they'r
600.
by NateDad 12y ago
I know that, and you know that, but do they? In my experience, no. And also, does the SEC know that? Possibly not. There's a lot of laws about this stuff where if you screw it up, people can go to actual prison.

More ›