The March Towards Go

Post by rdtsc » Fri, Jul 04, 2014, 2:16 PM UTC

Karunamon wrote: post #145

rdtsc wrote: post #101

Earlier quoted context omitted.

> Python falls through because it doesn't have real lambda. No it doesn't. Been using it for about 10 years can't remember being bothered by lacks of "real lambdas" > There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. If there would be minor detail we wouldn't have had the "Good Parts" book. And trying to deals with variables in Javascript is pain, var vs no var, what does…

I assume you're referring to the "Wat" talk by Gary Bernhardt, here. My question is why does it matter? It's funny and notable behavior, but why is this a problem that a real programmer will face dealing with a real problem? (For reference, [] + [] = "", [] + {} = Object, {} + [] = 0, {} + {} = NaN)

Post by Dewie » Fri, Jul 04, 2014, 2:20 PM UTC

collyw wrote: post #98

dom96 wrote: post #29

Earlier quoted context omitted.

This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).

With the exception of speed, why does Python need a replacement? I am using Python daily, and pretty much all performance problems (with my work) can be solved at the database or caching level. I get the impression that Numpy can produce reasonable performance for numeric problems. In my experience developer productivity is of far more importance to business than language performance (obviously that depends on your d…

Post by pjmlp » Fri, Jul 04, 2014, 2:21 PM UTC

personZ wrote: post #144

pjmlp wrote: post #93

Earlier quoted context omitted.

Because thanks to our experience with strong typed languages with native compilers and type inference, we know better. Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family. So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwar…

My professional history is with C, C++, C#, Fortran, even years of Object Pascal in Delphi back in the day. In no universe does Go feel like it's a "bit backwards", and I think you're trying to speak for a group without their input. Indeed, an implementation I regularly use now is high performance algorithms in C++ (the Intel vectorizing compiler is superb) to function libraries, Go/cgo as the extremely efficient, ve…

Post by Karunamon » Fri, Jul 04, 2014, 2:27 PM UTC

rdtsc wrote: post #151

Karunamon wrote: post #145

Earlier quoted context omitted.

I assume you're referring to the "Wat" talk by Gary Bernhardt, here. My question is why does it matter? It's funny and notable behavior, but why is this a problem that a real programmer will face dealing with a real problem? (For reference, [] + [] = "", [] + {} = Object, {} + [] = 0, {} + {} = NaN)

Because it hides errors instead of helping the developer find them

Post by marcosdumay » Fri, Jul 04, 2014, 2:33 PM UTC

fauigerzigerk wrote: post #140

_yosefk wrote: post #12

Earlier quoted context omitted.

Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves…

>It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration. Exceptions force API designers to decide whet…