Shit said in #go-nuts


 
Ciar Main Page >> TTK's Home Page
 
More quotes: Alaric   Fuz   Sonic   Pie   Izzy   Danny   TTK   Shit Said in Python   Shit Said in Go   mst
 
 
Display quotes in order:     
 [1010] #programming_is_hard
<hfaafb> try converting to string
<hfaafb> via `string(myVar)`
<Frenchiie> so a cast would work?
<hfaafb> if by cast you mean convert, yes
<andlabs> preemptive 'there are no casts in go' comment that's stupid and pointless and doesn't add anything to the conversation
<andlabs> nobody uses casts to mean literal C style casts
<andlabs> they use it to mean anyt ype of type conversion
<ttke> it drives me nuts when people conflate typecasts with type coercion
<Frenchiie> i guess there are different types of casting. Converting from a double to an int or the other type that converts a string to an int or an int to string.
<Frenchiie> or class casting parent/child
<Frenchiie> and then theres that boxing stuff
<mohae_> andlabs: there is a difference between cast and conversion; even if you are against making such a distinction
<andlabs> I'm not against making such a distinction, I'm agianst making a stink about other people who use cast as a generic term
<andlabs> because that's what it has become: a generic term
 
[So if a lot of people are wrong, we should embrace the wrong?  I am dubious of this.  Typecasting and value conversion are -totally- different things, and conflating them like this will only cause confusion and tears.]
 
     #go-nuts, 2015-12-16
 
 
 [1009] #why_would_you_ever_want_to_do_such_a_thing
<JX7P> is Golang available for OS2/eComStation?
<andlabs> no
<andlabs> but you can make a port if you want
<foobaz> heh and i thought the plan 9 port was silly
<andlabs> OS/2 is mmaking a resurgence for some reason among open soruce projects
<andlabs> why? I don't know
<Wintre> bizarre
<andlabs> maybe ecomstation has become popular again
<andlabs> like how we get people who want to run go on RHEL5
<Wintre> oh god
<Wintre> andlabs: Actually, we aren't running on RHEL5
<Wintre> Not Go anyway
<andlabs> RHEL5 is explicitly not supported due to kernel issues
<andlabs> right
<foobaz> i'm glad go is focused on the future and not the past
     #go-nuts, 2015-08-13
 
 
 [1008] #why_would_you_ever_want_to_do_such_a_thing
<steveeJ> is there a generic way to decode a json string of arbitrary structure?
<cgt> No good way
<cgt> A work-around is to beat whoever made such evil JSON with an iron pipe until they agree to properly structure their JSON.
<cespare> steveeJ: is it really arbitrary? Not just one of three things, or something?
<steveeJ> cespare: it's really arbitrary. the code is supposed to work for future structs too
<cespare> lolwat
 
[Note: this is a pretty common use-case for JSON]
 
     #go-nuts, 2015-08-03
 
 
 [1007] #why_would_you_ever_want_to_do_such_a_thing
<hfaafb> I don't believe Go is a good fit for large, monolithic CRUD applications
     #go-nuts, 2015-07-01
 
 
 [1006] #missing_the_point
2015-06-12 11:06:34 <kyrofa> Is anyone familiar with coverage testing here? Is there a way to exempt main since I can't test it?
     #go-nuts, 2015-06-12
 
 
 [1005] #why_would_you_ever_want_to_do_such_a_thing
15:22:33 <NiseVoid> Is it possible to make a function that accepts any kind of struct?
15:23:02 <qeed> and do what to it
15:23:22 <NiseVoid> encode it to json and send it back via http
15:24:00 <taotetek> NiseVoid: you could encode the struct before you pass it to the function and pass []byte instead
15:24:30 <NiseVoid> Would make the function less useful :x
15:24:35 <bhenderson> NiseVoid: json package can encode (almost) anything
15:25:44 <NiseVoid> I know, but I'm trying to make a short function to send json back to the http writer
15:25:58 <NiseVoid> So I don't have to put 2 lines everywhere
15:26:11 <NiseVoid> Something like, SendJson(w, struct)
15:26:23 <taotetek> it sounds like you want a function that can take "any type" - which is a sign that you should probably structure things a bit differently than how you are trying.
15:27:10 <mohae> NiseVoid: why? How is that better than just handling it locally?
 
[..time passes without reply..]
 
     #go-nuts, 2015-05-29
 
 
 [1004] #bloat_happens
16:15:23 <fivetwentysix> wow a hello world binary is 1.6M
16:15:50 <mohae> wow, it's that small?
16:19:05 <fivetwentysix> the source code is 85 bytes lol
16:20:02 <echlebek> If you use os.Stdout.Write for hello world, then your binary will be just under 1M :)
     #go-nuts, 2015-04-29
 
 
 [1003] #funny
13:02:17 <noahz> hello all. I'm trying to use github.com/kr/githubauth but don't understand how to initialize the http session keys, Keys []*[32]byte. any pointers?
13:02:51 <hfaafb> yeah, [32]byte is a pointer
13:03:08 <skelterjohn> *[32]byte is a pointer
13:03:16 <dome> lol
13:03:36 <sztanpet> oh those programmer dad jokes
     #go-nuts, 2015-04-29
 
 
 [1002] #expectations
11:44:44 <daved> cespare: bcrypt is what I'm wrapping.
11:47:19 <cespare> daved: frankly I'd rather find an expert recommendation for bcrypt strength tuning and just hard code it than export the calculation to other other code
11:49:02 <daved> cespare: The "quick" cost is based on the hardware being used.  The strong cost is based on the expected improvements of hardware.  And, again, I will likely add a much higher minimum.
11:54:14 * ttke likes to set a sane-seeming default, and provide an option to override it, but bury it somewhere in a config file where users will never find it unless they actually need to.
11:54:36 <mohae> ttke: like bcrypt's default cost?
11:54:56 <ttke> mohae - yes, exactly like that .. it was what I was thinking of, in fact
11:58:08 <ttke> most security is a tradeoff between convenience (which relates directly to productivity) and risk, and I tend to lean towards the convenience end of things.
11:58:51 <daved> ttke: The "quick" cost I've setup is based on the user hardware, so that a process that may affect user experience can be resolved quickly.  However, the system really should take that same password and process it on the side using the "strong" cost.
11:59:18 <ttke> that sounds reasonable, daved.
11:59:46 <daved> ttke: The failure points, for now, are my lack of testing, and the potential that users only use the quick cost.
12:00:46 <ttke> daved - frankly, I wouldn't worry about it too much.  Just by hashing your passwords and salting your hashes, you're ahead of most companies.
12:01:06 <cespare> ttke: that bar is so low it's meaningless
12:01:53 <ttke> :-) that bar can go pretty low, cespare.  I've seen horrible things in so-called "Enterprise" systems.
     #go-nuts, 2015-04-23
 
 
 [1001] #elitism
17:32:50 <mixedCase> Hey everyone. Python dev here freaking out. Is there a way I can modularize my program without having to place all my modules in my gopath? I just want to organize my modules in folders and import just like I did in Python.
17:33:18 <Tv`> mixedCase: wat
17:33:49 <jmoiron> go is not python
17:34:17 <mixedCase> Tv`: In python, if I had a folder in my root application with modules inside them, I could import them with import folder.module_name
17:34:31 <cronos> mixedCase: so you want relative imports?
17:34:40 <mixedCase> cronos: Yes! That's the term.
17:34:42 <Tv`> mixedCase: and Go made an explicit choice to have absolute imports, and it is good
17:34:44 <dozn> mixedCase, try "./fileName" in your import.
17:34:51 <Tv`> dozn: don't
17:34:52 <cronos> dozn: please don't
17:35:11 <dozn> I'm answering his question.
17:35:11 <cronos> mixedCase: just use absolute import paths
17:35:56 <mixedCase> cronos: I'll try it out, but it feels disgusting to include all my projects in the same workspace.
17:36:06 <Tv`> dozn: you're giving bad advice; being factually correct is not enough, advocating bank robbery to a friend who can't pay his rent is bad advice
17:36:08 <cronos> it works well enough
17:36:21 <mixedCase> dozn: Thanks for the workaround though. I will use it if I feel the "go way" is not mine.
17:36:32 <dozn> Tv`, it's not bad advice, he clearly understood how the gopath worked, and wanted to avoid using it. I answered that.
17:36:34 <Tv`> mixedCase: i'd rather you stopped using go, frankly
17:36:43 <Tv`> mixedCase: please try to do what the community does
17:36:58 <dozn> mixedCase, you'll run into issues when importing other libraries if you don't use your gopath correctly, so try to avoid it.
17:37:01 <Tv`> mixedCase: if you feel that offends your sensibilities, then you really won't like Go
17:37:17 <Tv`> dozn: bad advice and bad reasoning
17:37:23 <dozn> Tv`, too bad.
17:38:40 <mohae> mixedCase: it's better to learn how to use the language you are learning instead of trying to mold it into what you are familiar with
17:39:40 <cronos> mixedCase: but give the "go way" a try first
17:39:47 <cronos> it might not be as bad as you imagine it
17:45:38 <ttke> I'm confused.  You say Go decided to go with absolute paths for imports, but the documentation I'm finding for GOPATH makes it sound like imports can be relative to any of the paths listed in GOPATH.
17:45:49 * ttke digs deeper
17:46:03 <Tv`> ttke: import "github.com/jdoe/foo"
17:46:12 <mixedCase> ttke: There seems to be a way to use relative imports, but apparently it's not idiomatic.
17:46:39 <mohae> ttke: do relative imports, commit your code, have someone else pull it to work on it and see what happens. Have fun!
17:47:14 <mixedCase> mohae: I fail to see the problem of relative imports when it's program specific modules.
17:47:27 <mixedCase> mohae: I get it that it's a terrible idea for shared modules... but that's about it.
17:47:28 <cronos> ttke: absolute paths are not enforced by the go toolchain.
17:47:39 <ttke> thanks for the explanations
17:47:48 <cronos> mixedCase: what's the problem with absolute imports?
17:48:05 <Wessie> I believe the core team called them a mistake some time ago, relative imports that is
17:48:13 <mixedCase> cronos: Unnecessary verbosity.
17:48:17 <Tv`> things that are in Go that are there only to make the compiler/stdlib easier to implement: relative imports, println(), syscall
17:48:20 <mohae> mixedCase: it's terrible for team development or any situation where more than 1 person may work on the code. If you are working on hobby code to never be shared, fine.
17:48:51 <mixedCase> mohae: It works on Python for large teams.
17:48:59 <Wessie> Tv`: does the stdlib actually use relative imports?
17:49:12 <Tv`> Wessie: i understand the bootstrap phase of the compiler does
17:49:29 <Tv`> never chased that one down
17:49:35 <mohae> mixedCase: Go isn't python. The roman alphabet works fine for english. Good luck using it for an asian language.
17:50:12 <Tv`> ttke: maybe this: go import paths are not file paths
17:50:13 <ttke> mohae - GOPATH is a list of paths, though, so presumaby if an import fails to resolve relative to the relative path, it will look for it at one of the absolute paths.
17:50:15 <mohae> mixedCase: If you insist on using Go like Python, instead of learning the conventions of Go, then Go probably isn't for you
17:50:33 <mixedCase> mohae: That sounds like elitism.
17:50:48 <mohae> ttke: I don't see what that has to do with someone not having the code in your relative import on their machine
17:50:56 <cronos> we are quite an elitist bunch, that's true
17:51:03 <mohae> Go's way is vcs friendly, portable, and consistent.
17:51:07 <Tv`> learning is hard if you don't want to change anything
17:51:15 <ttke> mohae - that would be a broken condition, yes
17:51:25 <mohae> ttke: that's why it isn't done
17:51:39 <cronos> i'd rather have fewer people adopt go than more bad code and inconsistency introduced in ecosystem
17:51:48 <Tv`> cronos: too late :(
17:51:53 <mohae> mixedCase: Would you expect to structure sentences in French the same way you do in English? Different language, different ways
17:52:02 <ttke> mohae - but I disbelieve that every case of using a relative import corresponds to someone not having the code somewhere resolvable via GOPATH on their machines.
17:52:02 * Tv` <-- elitist systems programmer
17:52:41 <mohae> ttke: it's a bad habit to get into. If you don't mind that, go ahead. Just don't expect the community to use your packages
17:53:22 <Tv`> ttke: and there are some println() calls that are for debugging the "fmt" package. that doesn't mean you should use it.
17:53:53 <mixedCase> mohae: That sounds like a faulty analogy.
17:53:56 <mohae> ttke: just because something can be done doesn't mean it should
17:54:31 <mohae> mixedCase: no, languages are different. Expecting to use Python the same way you use Ruby would lead to pain too
17:54:45 <ttke> mohae - here, it's common practice to stuff "./lib" at the top of @INC (which is like GOPATH) so that developers can run things from the project directory and not have to have the project's libraries installed in the system.  It jfw for everyone else (non-devs) because when they install the project, the libraries are installed to the standard locations and get resolved via @INC
17:55:05 <mohae> ttke: I'm glad I'm not there
17:55:05 <ttke> it's a totally benign use of relative paths
17:55:13 <ttke> it breaks nothing, ever
17:55:33 <Tv`> @INC -> Perl -> nothing will shock me
17:55:53 <Tv`> *desperate for actual Go conversation*
17:55:54 <ttke> heh, okay Tv`, bowing out now :-) sorry for crossing the line
     #go-nuts, 2015-04-17
 
 
 
 
    Ciar Main Page >> TTK's Home Page