11–20 of 60 posts
I hate this. I don't know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap. Not every program needs to be golfed down to one line.
Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
People who prefer golang use it _because_ it is verbose. Nothing is implicit and that makes good easy to read.
I don't prefer Go because it is verbose, error as values without constructs to manage them is a pain in the ass.
I'd use go over language X,Y or Z because of its standard library and ease of deployment. The language itself has great things but is verbosity, mainly when it comes to dealing with error C style, its absolutely not a feature.
Now that we have generics, things will get more interesting.
> Nothing is implicit and that makes good easy to read.
I mean this is a language with garbage collection, that thing certainly is implicit.
Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
I hate this. I don't know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap. Not every program needs to be golfed down to one line.
Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
>Are there people with experience in a wide variety of languages that prefer Go? Other than Go, I have varying levels of experience in C, C#, Common Lisp, Python, (embedded) assembler, Fortran, Tcl, PHP, and maybe a few other languages I screwed around with for fun. At first I really really liked Go, and I grew to loathe it. I still think Go probably excels in large software development shops where some of its design…
One of the main reasons we went with go for a particular project was the ease of distribution and being able to build it for all platforms. The "all platforms" part isn't actually easy at all. It's a relatively simple app but does use GTK which is a nightmare to get working correctly on Windows, and a bigger nightmare to get working with our CI system that expects builds to be dockerized. In my opinion, it's not worth it.
At least it's fast when it does run, which isn't 100% of the time since sometimes it was just exiting with no output until we set up Sentry inside the app.
I feel like it's similar to Java, where the "write once, run anywhere" thing doesn't actually apply in practice. Combine with how GTK wants root stuff handled (TL;DR you have the app that runs in the background do the actual work that requires elevated privs and run the GUI as a separate app then do IPC / expose an API) and how different platforms have different ways of running a persistent daemon + how that complicated distribution (we're at the point now where we have an MSI for InTune for Windows and a JAMF package for Mac + the binary itself just works on Linux and we can push that with Salt) and...if it had been my decision, I would have just used python or node.
As a bonus, none of the libs for accessing our $BIGCO internal services are ported to go, so for some things we can use GRPC but other stuff just sucks to integrate with. It's so so so so so much easier to just use the most-supported or at least a well-supported language within a $BIGCO for the network effect.
Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
A great example is this .map().filter().reduce() joke we're looking at today.
Well-written Go is absolutely sublime.
Now that generics are in beta, here's a library for those who want ergonomic slice/map wrappers that make chainable operations easy. Or, a gateway drug for ECMAscripters who can't drop their `.map(x => y).filter(x => y).reduce(x => y)` habit.
Are there people with experience in a wide variety of languages that prefer Go? I've only used it in passing, but everytime I see examples they're verbose and look clunky. For example, the chainable methods are nice, but comparing to JS looks more like ES5 than modern code. Do you find Go preferable to other languages for solo projects?
To me it feels like C with some extra features, kind of like Objective-C. If you need to do some C-like things but can afford the small latency etc overhead introduced by Go, what Go provides (GC, large standard library, green threads, package management, etc) feels like absolute luxury compared to using C. C# is another GC language with the ability to go lower level, but the syntax can also be pretty verbose.
Hmm. Implemented on a custom type that wraps []T, so you have to create a List to get the methods, meaning more boilerplate (a common theme in Go); eager, like JavaScript’s Array methods rather than like the iterator methods in Rust or most/all functional programming languages; and since methods can’t have generics (which really surprised me in the Go generics proposal), Map() can only work on the same type (T → T, r…
Now that generics are in beta, here's a library for those who want ergonomic slice/map wrappers that make chainable operations easy. Or, a gateway drug for ECMAscripters who can't drop their `.map(x => y).filter(x => y).reduce(x => y)` habit.
That habit makes zero sense. Reduce already is a map and filter and one, why do you need to loop it 3 times? Reduce itself is awful to begin with. https://twitter.com/jaffathecake/status/1213077702300852224
Still, if you know you’ll have a small working set, and you don't what the extra deependency, there's lots of cases where bet readability, composability, and maintainability wins over efficiency.