#go-nuts

/

      • cespare
      • print out all functions with the number of params
      • in the go source, all the functions with a huge number of params are syscalls
      • jordanorelli has quit
      • gishuel has quit
      • the exported non-test function call with the most params is time.Date
      • jordanorelli joined the channel
      • cyberdelia joined the channel
      • monkeycoder joined the channel
      • moraes joined the channel
      • (not including syscalls)
      • actually debug/dwarf:New is 8 params as well
      • remy_on7 joined the channel
      • remy_o7 has quit
      • sl joined the channel
      • haha just ran it on my $GOPATH and the top ~80 functions are in github.com/BurntSushi/xgb
      • other offenders are banthar/gl and jteeuwen/glfw. Turns out gui lib bindings are pretty gross
      • angasule has quit
      • angasule joined the channel
      • monkeyco_ joined the channel
      • monkeycoder has quit
      • derferman joined the channel
      • Nisstyre-laptop has quit
      • mechnik118 has quit
      • angasule has quit
      • dmarkham_ joined the channel
      • sschlesier joined the channel
      • hfaafb joined the channel
      • fatih has quit
      • ajhager has quit
      • ttilley has quit
      • sschlesier has quit
      • basso has quit
      • kr has quit
      • pnielsen
        cespare: interesting!
      • sschlesier joined the channel
      • mechnik118 joined the channel
      • pcdummy joined the channel
      • pcdummy has quit
      • pcdummy joined the channel
      • monkeycoder joined the channel
      • dsal
        I've got a test that can't pass without some code panicking, but gocov is claiming no coverage on the panic suddenly. That's inconvenient.
      • monkeyco_ has quit
      • pcdummy has quit
      • moraes has quit
      • Oh. My test is racy.
      • Wait. This test can't be racy. What's this thing doing?
      • jordanorelli has quit
      • Ah, it's the *wrong* panic.
      • neurogeek joined the channel
      • neurogeek has quit
      • neurogeek joined the channel
      • cyberdelia has quit
      • sschlesier has quit
      • valgrind is now known as Guest32887
      • monkeyco_ joined the channel
      • monkeycoder has quit
      • sschlesier joined the channel
      • nfa106 has quit
      • That's great. Coverage saves the day again. There was a real bug not picked up by another test case because it was *slightly* different and this one appeared to work because it was expecting a crash, but crashed before it got to the right part.
      • ttilley joined the channel
      • ...but this sucks. You can't call methods on a nil interface, I guess.
      • Namegduf
        You can call methods on an non-nil interface value containing a nil concrete value of some type
      • You can't call method on a nil interface, because there's nothing to tell it which concrete type's methods to call
      • Basically, a nil interface value has a nil itable and a nil concrete value, and a nil concrete value in a non-nil interface type has a valid itable pointer and a nil concrete value.
      • hagna joined the channel
      • dsal
        Yeah. It's one of those cases where what I want is obvious, but I have no idea how I'd tell go what the obvious answer is.
      • tobier has quit
      • nil.getSomething() -> nil
      • Namegduf
        Cast the nil to the right type
      • Das_Wasser
        so I finished up my program now, but my python version runs considerably faster that my go version. would it just be because my go code is likely shitty or would the go version run slower for another reason?
      • dsal
        It's not any easier to just say if x == nil return nil
      • monkeycoder joined the channel
      • er, than to. It's equally awkward.
      • Namegduf
        interfaceValue = (*someType)(nil) will call methods successfully, using the methods on *someType
      • These methods, of course, will promptly die if they assume their method receiver is non-nil
      • But if they don't it will work
      • dsal
        I've defined "get a thing from nil" to mean return nil, but I can't say that at the interface.
      • Namegduf
        interfaceValue = nil will fail to call methods at all.
      • How to structure it is more problematic; I don't fully understand how you wound up in this situation.
      • But something will turn up if you understand what the language does and think about it, I hope. XD
      • dsal
        I just made an interface out of a concrete struct pointer thing and one of my tests was calling ptr.getSomething() and this worked before.
      • Namegduf
        At some point, the interface is being set to nil instead of (*concreteType)(nil)
      • monkeyco_ has quit
      • dsal
        Yes. The interface is contained within a struct.
      • I know what's happening, but I still raise my fist at it.
      • Namegduf
        Ah, I see. And previously the default value was legal and now it isn't.
      • dsal
        Yes.
      • And my test was passing incorrectly, but the coverage report pointed out my bug.
      • Chryson has quit
      • Namegduf
        Well, changing it from a concrete type to an interface is basically letting you swap out the method set on the pointer.
      • So you need to change stuff so that whenever the struct is used the method set is specified, somewhere.
      • That could be done with a NewFoo(), or some other way.
      • cespare
        Das_Wasser: could be any number of reasons :)
      • Das_Wasser: you'll have to give us more specifics (say, the code) for us to give you useful info
      • bytbox has quit
      • Das_Wasser
        cespare, alrighty, figured as much. the first version of the python code ran in 0.5 seconds
      • now it runs in 0.05 seconds
      • dsal
        Yeah. This may not happen outside of tests. I'd really like to be able to add "defaults" for an interface. Can't imagine what the syntax for that would even look like.
      • kr joined the channel
      • Das_Wasser: If you make the go version do the same thing the python one does, it'll probably be faster.
      • Das_Wasser
        go version runs in 0.22 seconds, so still off to a better start than i was with python version
      • Namegduf
        A kind of default method set to use if a nil value of that interface has methods called on it?
      • dsal
        Namegduf: Yeah. It'd probably almost always be used this way... if nil -> nil
      • Namegduf
        Das_Wasser: There's not any general language limitations which would mean you'd expect a Go implementation to be slower than a Python one, so likely it's some specific optimisation issue
      • Das_Wasser
        ah i just thought of a good way to test . this only thing i can think of that would really make it run slow is maybe if the hex.Encode() and hex.Decode() in go is slower than it is in python
      • Namegduf
        Das_Wasser: Or you're leaning heavily on library functions, spending most of your time in them, and Python has a library implemented in fast optimised C and the Go one is less mature
      • Das_Wasser
        if it's not that
      • Namegduf
        Das_Wasser: It could be; Go's stdlib is written in Go, Python's stdlib is written in C
      • Das_Wasser
        then i'd say I just optimized poorly, which was same problem i had with first version of python
      • Namegduf
        But it also might not be that.
      • Das_Wasser
        i'll work on concurrency and using pointers, since i haven't used any pointers
      • dsal
        You could also use another go implementation. The plan9 compiler isn't optimized as heavily.
      • No reason in general to say "C is faster than go" except in a few cases where more copies are required or the allocator can get in the way.
      • bytbox joined the channel
      • Namegduf
        dsal: It is generally true that an optimised C implementation of a thing will beat the Go stdlib at present in speed, and GC is a part of that, but the stdlib is also not all that optimised.
      • wubino joined the channel
      • dsal
        Yeah, but that's too many variables. :)
      • It's not that C is faster than go, it's more that you can likely find a faster C something than a go something for certain classes of things.
      • racycfo joined the channel
      • It's also possible to find a faster python something than go something, but that becomes less likely.
      • darkgray
        C is faster than Go, what are you talking about?
      • neurogeek has quit
      • It's inevitable, since Go has training wheels.
      • Namegduf
        The point was that the odds of it being an algorithm issue of theirs was lower if they were using the stdlib for most of the heaviy lifting, because the C version they were likely to find in this case, would be faster than the Go version in the stdlib, aa significant amount of the time, if only because the Go stdlib is not all that optimised
      • darkgray
        It's more a question of whether it's an issue or not. :)
      • racycfo
        Das_Wasser, post your code. The code of yours that I saw a couple of days ago looked a little ... how do I say this politely .... rough???
      • Namegduf
        The other big case where Go being slower than many other things is expected is regexes, because Go by default chooses to be slower on average but safe from abusive regexes.
      • Feature rather than bug.
      • And the thing to look into there after a cursory check over your own code is an alternative regex library than the stdlib one if you know what you're doing and want to make that tradeoff the other way.
      • dsal
        regex is a horrible example of such things. There are many implementations that vary in different ways.
      • racycfo
        Das_Wasser, also share the command you use to run the code.
      • darkgray
        I wrote a program that concatenated tons of strings, which was very fast in Python, but turned out incredibly slow in Go. Clear case of failure to understand how to do things, mind.
      • sschlesier has quit
      • (I guess "very fast" and "incredibly slow" is exaggerating, but still)
      • Namegduf
        dsal: Regexes are very atypical- thus why I name them as a special case exception where this behaviour is expected
      • darkgray
        There's no Atoi equivalent in the bytes lib, is there?
      • meatballhat joined the channel
      • racycfo
        darkgray, not here is not.
      • but easy to write
      • darkgray
        It'd still be nice.
      • felixge has quit
      • dsal
        Namegduf: makes sense. There were similar complaints in java's vs. perl's.
      • mechnik118 has quit
      • jlouis
        It is a myth in general that GC makes a programming language slow. Especially Go, where allocation is controlled
      • dsal likes how autocorrect fixed perl -> perp
      • dsal
        jlouis: There are things I can do when there's not a GC that will far exceed what I can do with one. And vice versa.
      • racycfo
        dkargray, Yes, it would be nice. If the stdlib had the bytes parser, then things like http://code.google.com/p/go/source/browse/src/p... could be eliminated.
      • Namegduf
        dsal: Basically for compute work Go should not be slower than Python and it indicates your program is probably doing something suboptimal somewhere; something the optimiser in Python is fixing but Go's optimiser isn't, like the string example.
      • dsal
        I haven't seen the string example, but I can imagine it.