|
I am just learning Go and the fact that it gets so many things right are what make the things that seem 'less right' so frustrating. The type system feels like more of a straight jacket than an actual tool. A good type system can be expressive and powerful in addition to just making your code typesafe.
|
#
?
Feb 27, 2015 01:36
|
|
|
|
| # ? Apr 20, 2024 10:49 |
|
|
mdxi posted:It may also be illuminating to remember that it was designed and written by people who are already titans in their field and have absolutely nothing to prove to anyone.
|
|
#
?
Feb 27, 2015 03:08
|
|
|
can we stop with the dumb language wars and get back to dumb programs Sheesh
|
|
#
?
Feb 27, 2015 04:59
|
|
|
Most of my complaints with Go are with the hype surrounding it anyway. It's fairly palpable. Go is not the saviour.
|
|
#
?
Feb 27, 2015 08:24
|
|
|
Bozart posted:can we stop with the dumb language wars and get back to dumb programs Sheesh Nah that's all good, as long as it can be kept to the concrete. For example, I'd really like to hear why you think the type system is bad and how it hinders you in your day-to-day work, and what you propose should have been done instead, and why you'd expect that to improve things, and what other language you consider has done this right. e: and that's "you" in the general sense, not specifically directed at "you" in the specific sense.
|
|
#
?
Feb 27, 2015 08:24
|
|
|
Karate Bastard posted:Nah that's all good, as long as it can be kept to the concrete. For example, I'd really like to hear why you think the type system is bad and how it hinders you in your day-to-day work, and what you propose should have been done instead, and why you'd expect that to improve things, and what other language you consider has done this right. Most go projects I've seen go to type assertions at some point and some even have to resort to using reflect. Moving your type system to the runtime is a pretty good concrete example of it not being expressive enough.
|
|
#
?
Feb 27, 2015 08:39
|
|
|
I could tell you how the type system would hinder me but that's why I'm not using Go for that sort of stuff. But just to pick an example, I'd badly want generic stream resequencing logic and generic stream throttling logic in a project I recently worked on. Also a bunch of stuff for performance reasons (because Go slices and maps would be wrong). C# gets this relatively "right", in particular with respect to boxing.
|
|
#
?
Feb 27, 2015 10:33
|
|
|
Markov Chain Chomp posted:Most go projects I've seen go to type assertions at some point and some even have to resort to using reflect. Moving your type system to the runtime is a pretty good concrete example of it not being expressive enough. What's wrong with type assertions? That's not a strange thing to do when you're using interfaces anyways. I also really doubt many projects have to resort to using reflect unless you're dealing with protocol buffers or something.
|
|
#
?
Feb 27, 2015 18:46
|
|
|
Voted Worst Mom posted:What's wrong with type assertions? They fail at run time, superior type systems don't need them (or even have them), maintaining and accessing type information at run time is prohibitively expensive for some cases.
|
|
#
?
Feb 27, 2015 19:24
|
|
|
What do you catch with asserts that interfaces don't?
|
|
#
?
Feb 27, 2015 20:28
|
|
|
Voted Worst Mom posted:What's wrong with type assertions? That's not a strange thing to do when you're using interfaces anyways. I also really doubt many projects have to resort to using reflect unless you're dealing with protocol buffers or something. It's actually pretty loving strange when all of your type information is known at compile-time. It makes your project more brittle and it's unnecessarily verbose. And gently caress it, why should I have to do it? Why can't it just have a good type system instead?
|
|
#
?
Feb 28, 2015 09:25
|
|
|
MALE SHOEGAZE posted:I am just learning Go and the fact that it gets so many things right are what make the things that seem 'less right' so frustrating. The type system feels like more of a straight jacket than an actual tool. A good type system can be expressive and powerful in addition to just making your code typesafe. 
|
|
#
?
Feb 28, 2015 09:27
|
|
|
why does that movie gif have some random guy's name in the left corner
|
|
#
?
Feb 28, 2015 18:05
|
|
|
the act of putting text over somebody else's work is a very hard and arduous process. it's only natural to take credit
|
|
#
?
Feb 28, 2015 18:11
|
|
|
Suspicious Dish posted:why does that movie gif have some random guy's name in the left corner because tumblr is a thing that exists
|
|
#
?
Mar 1, 2015 06:46
|
|
|
ATM Machine posted:because
|
|
#
?
Mar 1, 2015 07:26
|
|
|
Here is what annoyed me about Go's type system yesterday. I had several types of slice, and for each of them, I wanted to find the index of the element that matched a given player. In other languages I could just write func[T] lookup(elems []T, f func(T)bool) (index int, found bool) { ... }, or actually it would be a utility written for me, but instead I had to rewrite the same for loop several times. And the same again when I wanted to make a new slice with the matched element removed. I guess it doesn't matter though because Go is made by titans in their field, just like Git, a perfect version control system that is also above criticism.
|
|
#
?
Mar 2, 2015 23:09
|
|
|
The lack of function overloading irks me a lot of the time. Like sarehu's post above, you can't just do lookup(whatever []type) int {...} for each type, you'd have to have a different function name for each. It's not like it's a bunch of extra typing, but why the hell did they design a modern language this way? If you won't give me generics at least give me overloading so I can sort of simulate it.
|
|
#
?
Mar 3, 2015 01:48
|
|
|
Overloading or dynamic dispatch or really any number of things. (I don't quite understand the meaning of overloading in a language without classes, though, care to elaborate?) Or like the example here with the linked list: http://yager.io/programming/go.html You can sorta simulate something this with interfaces (I guess?) but now you've lost any meaningful type safety. I dont know why go is this way aside from the compilation speed thing maybe? I'm an idiot so I can only speculate. It's a Bad Type System.
|
|
#
?
Mar 3, 2015 01:50
|
|
|
sarehu posted:Here is what annoyed me about Go's type system yesterday. I had several types of slice, and for each of them, I wanted to find the index of the element that matched a given player. In other languages I could just write func[T] lookup(elems []T, f func(T)bool) (index int, found bool) { ... }, or actually it would be a utility written for me, but instead I had to rewrite the same for loop several times. And the same again when I wanted to make a new slice with the matched element removed. I guess it doesn't matter though because Go is made by titans in their field, just like Git, a perfect version control system that is also above criticism. Just curious, why isn't a map appropriate in this case?
|
|
#
?
Mar 3, 2015 05:34
|
|
|
sarehu posted:Here is what annoyed me about Go's type system yesterday. I had several types of slice, and for each of them, I wanted to find the index of the element that matched a given player. In other languages I could just write func[T] lookup(elems []T, f func(T)bool) (index int, found bool) { ... }, or actually it would be a utility written for me, but instead I had to rewrite the same for loop several times. And the same again when I wanted to make a new slice with the matched element removed. I guess it doesn't matter though because Go is made by titans in their field, just like Git, a perfect version control system that is also above criticism. Don't worry, `go generate` will allow you to fix this by building the world's most simple build system. Any .go file in your repo may bear a `//go:generate` on any line, and go will happily call out to your shell to perform whatever you've put there. Simple!
|
|
#
?
Mar 3, 2015 10:38
|
|
|
Bozart posted:Just curious, why isn't a map appropriate in this case? The order of the slice elements mattered, one represented a waiting list, the other was similar.
|
|
#
?
Mar 3, 2015 21:38
|
|
|
In case anyone runs into this issue, the 1.4.2 msi installer is broken. Use the archive to install instead.
Khorne fucked around with this message at 17:14 on Mar 11, 2015 |
|
#
?
Mar 11, 2015 16:54
|
|
|
Khorne posted:In case anyone runs into this issue, the 1.4.2 msi installer is broken. Use the archive to install instead. I just used it yesterday, no problem.
|
|
#
?
Mar 11, 2015 17:22
|
|
|
Bozart posted:I just used it yesterday, no problem. Google turned up no one else having the issue. edit: I just downloaded and installed it on my laptop and it was doing the same thing. Khorne fucked around with this message at 17:41 on Mar 11, 2015 |
|
#
?
Mar 11, 2015 17:24
|
|
|
Is it just me or do a lot of Go's libraries have utterly garbage documentation. Maybe I'm spoiled by python, but I'm coming across so many libraries that have at best a minimal API documentation and no context at all.
|
|
#
?
Mar 12, 2015 12:48
|
|
|
duck monster posted:Is it just me or do a lot of Go's libraries have utterly garbage documentation. Maybe I'm spoiled by python, but I'm coming across so many libraries that have at best a minimal API documentation and no context at all. I think they're pretty good but assume some familiarity with C. I wasted half an hour the other day trying to get the binary package's thing to pack my int into bytes, but it turns out its packing is set up for protobufs. D'oh!
|
|
#
?
Mar 12, 2015 18:35
|
|
|
I have a question for you Go people. Suppose you write a web application in Go. What do you do to get it running in actual production? Right now I ran it with nohup and proxied it with nginx so that it'd run on port 80 after reading a tutorial. I hope it doesn't go down! But like, seriously, what do you do? This is not really a Go-specific question, sorry that it's in the wrong place.
|
|
#
?
Mar 14, 2015 20:34
|
|
|
sarehu posted:I have a question for you Go people. Suppose you write a web application in Go. What do you do to get it running in actual production? Just throw the binary on your server and run it. Nginx is an option if you need any benefits from a reverse proxy. It doesn't get much easier.
|
|
#
?
Mar 14, 2015 20:55
|
|
|
sarehu posted:I have a question for you Go people. Suppose you write a web application in Go. What do you do to get it running in actual production? Yeah, you don't even need nginx really if you want to give it access to lowports. code:code:Urit fucked around with this message at 03:23 on Mar 15, 2015 |
|
#
?
Mar 15, 2015 03:17
|
|
|
sarehu posted:I have a question for you Go people. Suppose you write a web application in Go. What do you do to get it running in actual production? Running the Go process on a higher, unprivileged port and proxying is the way to do it. Look into something more powerful than nohup for running your code, though. I use daemontools at work and it's fine, but I think supervisor is a bit more reasonable to set up. You want something that will handle stdout/stderr redirection, restarting the process when it crashes, and reporting on process status.
|
|
#
?
Mar 15, 2015 03:36
|
|
|
good jovi posted:Running the Go process on a higher, unprivileged port and proxying is the way to do it. Look into something more powerful than nohup for running your code, though. I use daemontools at work and it's fine, but I think supervisor is a bit more reasonable to set up. You want something that will handle stdout/stderr redirection, restarting the process when it crashes, and reporting on process status. Honcho (A python heroku like thing that does Procfiles and .env files) can export out to supervisord. Its really handy for turning 12 factor type apps into non retarded systemd apps.
|
|
#
?
Mar 16, 2015 07:23
|
|
|
Is there a consensus on the most viable embedded scripting language for Go? I'm writing something that I'd like to allow (friendly - as in written by internal users and stored on disk with the program) arbitrary code execution in. Lua seems to be vaguely incompatible with Go on Windows due to longjmps for error handling which causes straight up crashes, plus it's playing with CGo. Otto looks neat but it's Javascript which no one wants to write, and it's not really fast for string processing. I found a random project on Github called Agora but it hasn't been maintained for a year and it's somone's toy scripting language, though it looks pretty neat.
|
|
#
?
Mar 16, 2015 19:01
|
|
|
go fmt is changing a * b to a*b on me. I'm getting really hatey right now.
|
|
#
?
Apr 6, 2015 07:00
|
|
|
sarehu posted:go fmt is changing a * b to a*b on me. It bundles operators by binding/precedence. It's to make expressions like a * b + c * d easier to read by grouping them as a*b + c*d. It's kind of dumb when it does it on standalone expressions though, yeah.
|
|
#
?
Apr 6, 2015 07:09
|
|
|
No it's dumb in general.
|
|
#
?
Apr 6, 2015 07:11
|
|
|
This is something I'd bikeshed the gently caress out of and I agree with you.
|
|
#
?
Apr 6, 2015 10:42
|
|
|
It doesn't matter what gofmt does because it does it consistently and that's the point. There are some bugs but that's not one of them.
|
|
#
?
Apr 13, 2015 13:02
|
|
|
Urit posted:Is there a consensus on the most viable embedded scripting language for Go? I'm writing something that I'd like to allow (friendly - as in written by internal users and stored on disk with the program) arbitrary code execution in. Lua seems to be vaguely incompatible with Go on Windows due to longjmps for error handling which causes straight up crashes, plus it's playing with CGo. Otto looks neat but it's Javascript which no one wants to write, and it's not really fast for string processing. I found a random project on Github called Agora but it hasn't been maintained for a year and it's somone's toy scripting language, though it looks pretty neat. There's go-lua Which is all native Go so no cgo BS otto V8 JS all in native Go. I've used both of them with great success. Pretty decent in terms of performance for what it is, as well. Pretty much everything else is trash/a toy language that you shouldn't expect users to learn or uses cgo e: If it matters, I prefer otto. It's much easier to interface with. NickPlowswell fucked around with this message at 08:07 on Apr 16, 2015 |
|
#
?
Apr 16, 2015 06:58
|
|
|
|
| # ? Apr 20, 2024 10:49 |
|
|
NickPlowswell posted:There's Awesome, thanks a ton. Those were the two I saw as well but I was seeing if there was something else out there that was better that I just didn't know about. CGo is cool and all but I'm running in a mixed Windows/Linux environment so the cross-compilation of Go is a huge plus for me, and having to hope that MinGW is going to work today and/or the C portion won't segfault is a pain in the rear end.
|
|
#
?
Apr 16, 2015 21:44
|
|