111–120 of 297 posts
Earlier quoted context omitted.
My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
To be fair that's generally good practice since it eliminates a branch in the code, depending on the type of v and overhead of assignment.
Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like la…
> Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fix…
If you go with most languages definition of "slice", that would be pretty horrible just by itself.
But, as you said, Go's definition is different (what is also bad, just not much):
> Slices are backed by arrays, and if you append to a slice whose backing array is full, it will "grow" by allocating a bigger array elsewhere and copying the original data into it
What would be pretty much like Java's ArrayList, or Python's list if it was designed on a sane way. So, just the name would be non-standard... But the container actually migrates when it is reallocated! That's a broken design in any language.
Earlier quoted context omitted.
I don't know, I'll go and read up on it more. The feature leaves me 'meh'. I don't find slices as awesome as everyone is always saying, especially without negative indices. I guess part of it it that it isn't always clear to me when you're dealing with a slice, or an array, or whatever. I know, when it's confusing, there's always some reasonable sounding explanation after the fact, sure, but the whole thing feels lik…
Do you know any other systems languages, like C or C++? This kind of thing makes a lot more sense when you have some surrounding context.
I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…
Earlier quoted context omitted.
Can't say I got that feeling at all. Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different intege…
> You can pass functions but not return them. #include char *f(void) { return "Yes, you can..."; } char *(*g(void))(void) { return f; } int main() { puts(g()()); return 0; }
It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right".
It'll be open sourced by June 20.
[0]: https://vlang.io
I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…
After a long stint in enterprise Java land, Go was a really big adjustment. Mostly about letting go of unnecessary complexity. I didn't realize how much I didn't miss that complexity until I recently went back into Java. If you learn the golang way of doing things, the issues this guy mentions really are not something you run into.
From a lot of what I've seen, that is a useful description.
Earlier quoted context omitted.
One of the praised functions in Scala 2.8 was postfix operators, allowing things like: Seq(1, 2) map _ + 100 They are getting rid of it: https://contributors.scala-lang.org/t/lets-drop-postfix-oper... Unit functions were a thing, just write: def A() { ... } This is inalid since 2.13. You have to specify its a unit: def A(): Unit = { ... } Most of the ideas in scala were to remove boilerplate, but they backfired. The…
To me this is more of an issue with not understanding some of the conventions the language pushes you towards. An example of this common stylistic mistake is when some repos will have a `lib` package with a large number of utility functions spread across different files. It runs into the author's issue of function and constant collisions. The solution is to group together utility functions into many small packages, which has the added benefit of changing the code at the call site from something like this:
lib.NewUUID()
uuid.New()
However, if the Go compiler is going to enforce these rules, maybe it could be more helpful by suggesting the design tweaks that would help to avoid them, rather than forcing developers new to Golang to go through a kind of trial and error process.
Earlier quoted context omitted.
> You can pass functions but not return them. #include char *f(void) { return "Yes, you can..."; } char *(*g(void))(void) { return f; } int main() { puts(g()()); return 0; }
Technically passing and returning function pointers is very different from passing and returning functions. This has implications for things like closures.
EDIT: At least last I heard. The example I gave is C89, and I know C99 and some GNU extensions. I don't know if a new standard introduced something else that could be referred to as a function that can be passed in but not returned.
A quick google for "c lambda" and "c closure" as well as looking for those keywords in the Wikipedia articles of C11 and C18 turned up nothing, so I guess not.