291–300 of 318 posts
Earlier quoted context omitted.
a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad
It's more concise, but certainly not more readable. You lose a few seconds writing it the second way. It's fine.
Earlier quoted context omitted.
To me the ternary operator is more readable. It has way less extraneous symbols, it is expression-oriented and lets you focus on what's really happening: that something gets assigned to a based on some condition. It expresses intent better than the if-else . Sure it can be abused and nested beyond human comprehension... just like if-else ! So that's a non-argument.
This is the typical operator vs programmer argument. If you're working with difficult concepts compactness trumps simplicity. Plus Go makes it such an enormous chore to write programs with a lot of features. If you're the one trying to figure out what went wrong in production, both properties are big plusses. Simplicity means scanning code quickly will yield an answer. And the fact that Go makes writing code a chore…
why is if statement that necessitates multiple assignment statements, involves scoping rules and is objectively bloated for trivial cases, why is it considered simpler?
it sure is easier to get than an operator due to proximity to natural language, but why tend to people that can't grasp that a statement can be represented as an expression?
Earlier quoted context omitted.
a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad
If `c` is not some complex expression, I would write that as: a := c if flag { a = b }
a := c
Earlier quoted context omitted.
This is the typical operator vs programmer argument. If you're working with difficult concepts compactness trumps simplicity. Plus Go makes it such an enormous chore to write programs with a lot of features. If you're the one trying to figure out what went wrong in production, both properties are big plusses. Simplicity means scanning code quickly will yield an answer. And the fact that Go makes writing code a chore…
i don't get what is not simple about ternary operator? why is if statement that necessitates multiple assignment statements, involves scoping rules and is objectively bloated for trivial cases, why is it considered simpler? it sure is easier to get than an operator due to proximity to natural language, but why tend to people that can't grasp that a statement can be represented as an expression?
Think about it: algebra (most of it) is just simple concepts incredibly densely written down and recursively applied. There are very few really complex parts in it, by which I mean there's very few individual steps that take long to understand, there's just so bloody many of them and they link together so incredibly tightly.
Earlier quoted context omitted.
But the problems go further. The go type system is littered with exceptions. Why ? Because append, make, maps, channels in for loops, channels in while loops, ... all have their own specific entries in the type system. Go has generics ... but only for the core team. Go has polymorphism (there are polymorphic functions, all of which BEHAVE differently in the type system), there are return type polymorphic functions (f…
I found the https://github.com/juju/errors library to be a very practical way to include tracing info in the error values. I wish the core error library behaved like that, and that the core language made it less verbose. This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community. Other languages changed a lot over the years, getti…
C++16 beta compilers can compile the very first C program just fine. How's that for backwards compatibility ? 44 years. In fact, this is exactly what's frequently blamed for C++'s complexity. Support lots of weird edge cases because "at some point it worked". Over 44 years (wtf C is old now).
Java - same. ML - same. C++ - same.
> I believe this promise of stability paved the way for much of Go's success, despite many shortcomings
Actually for most of it's 7 year life the exact opposite is true. Go regularly broke it's weird cases (I would say because getting a compiler without a sound type system working well is a road that is littered with mines). This is why "gofix" exists ( https://blog.golang.org/introducing-gofix ). Go's authors are crediting this with Go's "simpleness".
Earlier quoted context omitted.
But the problems go further. The go type system is littered with exceptions. Why ? Because append, make, maps, channels in for loops, channels in while loops, ... all have their own specific entries in the type system. Go has generics ... but only for the core team. Go has polymorphism (there are polymorphic functions, all of which BEHAVE differently in the type system), there are return type polymorphic functions (f…
As I said, generics are missing, and the core team is working at them. But I really appreciate that they do not implement something like the Java generics. If your code produces errors, you can of course add location information like stack traces, there is an API for that. I have not benchmarked Go against Java explicitly, but I do benchmark against C and it compares very nicely in performance to C code, so for most…
On average, Go code is about 50% as fast as C code in calculations and algorithms, usually, and has more lines of code for equivalent functionality without cheating. Do your benchmarks tell you something different ?
Java is about 10% slower than C. 30% or so if you "don't cheat" (meaning write a direct translation of C code into java, e.g. using char[] instead of string)
There's also that C encourages you to write faster code, at least it does for me. Java, Go, and every other language I know, encourage me to do string mangling by making lots of temporary strings. C doesn't really allow for that, instead making me think about doing in-place string editing, which is far, far faster than using copies. Of course, get the tiniest little detail wrong and it'll blow up, but there's no beating it in speed.
Earlier quoted context omitted.
As I said, generics are missing, and the core team is working at them. But I really appreciate that they do not implement something like the Java generics. If your code produces errors, you can of course add location information like stack traces, there is an API for that. I have not benchmarked Go against Java explicitly, but I do benchmark against C and it compares very nicely in performance to C code, so for most…
> I have not benchmarked Go against Java explicitly, but I do benchmark against C and it compares very nicely in performance to C code, On average, Go code is about 50% as fast as C code in calculations and algorithms, usually, and has more lines of code for equivalent functionality without cheating. Do your benchmarks tell you something different ? Java is about 10% slower than C. 30% or so if you "don't cheat" (mea…
Earlier quoted context omitted.
I found the https://github.com/juju/errors library to be a very practical way to include tracing info in the error values. I wish the core error library behaved like that, and that the core language made it less verbose. This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community. Other languages changed a lot over the years, getti…
> This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community. C++16 beta compilers can compile the very first C program just fine. How's that for backwards compatibility ? 44 years. In fact, this is exactly what's frequently blamed for C++'s complexity. Support lots of weird edge cases because "at some point it worked". Over 44 ye…
nitpick: a c++ compiler can compile C only if it knows that it's a C source. Not every valid C source is a valid C++ source:
char *foo = malloc(42);
C++ is 33 years old. Still impressive backward compatibility track.
I guess that backward compat is a good reason for why C/C++ is still widely adopted.
IIRC there are some minor things that have been removed from the standard, e.g. the export keyword, but apparently it wasn't widely adopted if at all.
> ... This is why "gofix" exists I was under the impression that this was a thing before Go 1.0.
I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…
Multiple result sets Sorting slices
I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…
> what it does couldn't possibly be done in e.g. Python What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.
The real benefits for me with go are
Tooling. Gofmt, godef, etc make using emacs a dream.
Extensive stdlib. I pull in exactly two small libraries to build a very large web app: odbc, gorilla mux. Everything is baked in: http server, templating, compression, database
Cross compiling, being able to build a Windows exe in my Mac for deployment is awesome
Fast compilation.
Interfaces are a key concept and used everywhere to great effect in the std library