|
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 |
|
|
# ¿ May 3, 2024 05:24 |
|
ATM Machine posted:because
|
# ¿ Mar 1, 2015 07:26 |
|
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 |
|
Sub Par posted:Edit: nevermind, I'm just going to do this in JS. Go everyone!
|
# ¿ Jan 19, 2016 03:41 |
|
Go really needs function overloading, imo. It makes the clutter from not having generics that much worse, because now add(foo_type) has to be written to add_foo_type(foo_type) which is annoying. After spending time with the language, I stopped caring about that because I started accepting go's thesis re: simplicity and lack of indirection. My main complain about go these days is that the community is full of luddites who are hostile towards both useful language features and anyone introducing a new library that attempts to do...anything. My main experiences are on the golang reddit, though, which is no longer an official community. So maybe it's not representative of the real go community.
|
# ¿ Dec 12, 2016 17:35 |
|
Coffee Mugshot posted:The debugger is delve and delve is good but not sufficient IMO. Derek Parker doesn't have enough real life time to make it much better, either, unfortunately. If only Golang had a large corporate backer with the resources and motivation to develop a functional go debugger. And of course, if Google were to release one, it would be balked at by the Go community as "over complicated." This would be followed by blog posts explaining why printf debugging is actually good, because it's easy to understand, and debuggers are bad because no one can understand how they work.
|
# ¿ Dec 18, 2016 21:28 |
|
Ghost of Reagan Past posted:I'm writing a lovely, bare-bones NES emulator for shits and giggles. What's a good library for graphics for someone who doesn't do graphics? I honestly wouldn't use go for this. Go is great for keeping poo poo simple but if you want to abstract over anything, go use a language with actual features.
|
# ¿ Dec 22, 2017 05:54 |
|
bonds0097 posted:Why the move away from serverless? Performance? in my experience, lamdas / microservices are a function that maps simple problems to complex distributed systems problems DONT THREAD ON ME fucked around with this message at 12:04 on Feb 27, 2018 |
# ¿ Feb 27, 2018 12:02 |
|
Khorne posted:Go is good tool for web services and similar applications. I've used it off and on since 2014 and as long as you don't venture too far from that realm it's truly well designed. It's also not bad for command-line/one-off programs that most people would probably reach for Python/bash/perl/whatever to make. Its portability, single day learning curve, ease of developing in, and ease of setting up its environment are all great. It has similar level performance to pretty much anything for web stuff. It's not slow and carrying five tons of baggage like lots of the common web backend languages, and it doesn't require significant developer investment like C++ or functional languages. It also doesn't require consuming a bloated corpse like the JVM languages. Can't quote this hard enough.
|
# ¿ Aug 12, 2018 14:36 |
|
Helicity posted:I personally disagree with the "web services" part unless you're only responsible for a small API footprint. Serialization/deserialization feels tedious to me for a few reasons, and web services are one of the best places to lean heavily on functional programming ideas and patterns since the whole request/response pipeline is essentially a mapreduce. any such library would need to lean heavily on interface{}. in a typed language you need generics if you want a library like lodash. i agree though, go can really only support certain kinds of web services, ones that don’t stray much into business domains.
|
# ¿ Aug 12, 2018 20:58 |
|
|
# ¿ May 3, 2024 05:24 |
|
here we go: https://blog.golang.org/go2draft https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md DONT THREAD ON ME fucked around with this message at 17:41 on Aug 28, 2018 |
# ¿ Aug 28, 2018 17:35 |