51–60 of 439 posts
Earlier quoted context omitted.
I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.
That comes with a big memory cost, though. Also huge startup time, so not suitable for command line tools.
Also since Java 8 with tiered compilation, I wouldn't consider a few ms a huge startup time.
Earlier quoted context omitted.
Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.
If recover is used in a file you never read, is its complexity relevant?
Earlier quoted context omitted.
CLR (the C# runtime) generics are fully reified and about the most complicated and robust implementation available. It dynamically emits and loads types whenever a new generic parameter is seen for a function or type. This is very, very hard to get right and is not very performant. It also puts a lot of burden on the runtime vs. the compiler. Go expressly tries to keep the runtime as small as possible.
CLR-style just-in-time monomorphization is plenty performant: in fact, it's just about ideal. It's also not that difficult when you have a JIT when compared to the complexity you need for speculative optimizations of hot spots anyway. In any case, the .NET approach isn't an option for AOT compilers like those of Go. For Go, the only reasonable option is ahead of time monomorphization, which really isn't that bad.
From the post: > As Russ pointed out, generics are a trade off between programmer time, compilation time, and execution time This misses the most important metric: quality. Lack of generics forces copying and pasting of code which inevitably lowers quality and increases defects. It's amazing to me that with the all the expense that crappy software causes, we're more focused on compilation and execution time. Last tim…
Earlier quoted context omitted.
If recover is used in a file you never read, is its complexity relevant?
I think what's happening here is pcwalton is a language implementer, so when you talk about 'conceptual complexity' he thinks about how the feature is specified, whereas you or I think about how the users of the feature think about and use it. We're all talking past each other a bit, I think.
To be fair, pcwalton was not advocating this. He was pointing out that defer is already more costly runtime wise than exceptions, correcting another person.
Generics as a language retrofit tend to be ugly. See C++. I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generi…
Generics as a language retrofit tend to be ugly. See C++. I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generi…
The current interface{} workaround doesn't quite solve the same problem, rather it is like a bad excuse.
Earlier quoted context omitted.
We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.
Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now? There was definitely a lesson to be learned there, but it wasn't the one you're implying.
The aggressive code reuse in the node ecosystem is, and remains, the quality of it I respect the most.