Live data from Hacker News

Less is exponentially more

commandcenter.blogspot.com

121–124 of 124 posts

Re: Less is exponentially more

#121

Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an or…

I tend to agree about the lack of generics - the type of people who design and write standard libraries (e.g. Rob Pike and co.) may find it easy to put these things together, but they aren't representative of the general class of programmers, and there should be easy ways to make typesafe collections available to the average programmer (and making them write the same boilerplate around someone else's empty-interface using code may be mechanical, but it isn't low-effort enough to be "easy"). That said, I generally like the direction Go is taking as a language, and would like to see it succeed.

Re: Less is exponentially more

#122
post #26
post #4

The claim that wanting to be able to abstract over types is the same as thinking that programming is about constructing taxonomies is one of the sillier claims I've seen recently.

His claim as I understood it is that the fundamental building blocks should not be types (what something is ), but functional capabilities (what something can do ). Type abstractions are fundamentally hierarchical (from an abstraction to multiple concrete versions), whereas capabilities are fundamentally about composition (I can do A, B and C).

And that's exactly how C++'s template ("generics") mechanism works, which makes Pike's claim seem uninformed.

Re: Less is exponentially more

#123
post #46
post #18

Earlier quoted context omitted.

Maybe it would be better to learn more about Go and rationally evaluate its use in those cases rather than using your imagination. I'm not sure what you mean by unfair. Its certainly far from an exact analogy but there are interesting similarities. That is true that Go is not just a syntax change to C++ and that it has a very different programming style. Many of the design goals of Go may be different, but maybe not…

I based my assumption off of a quote I heard that was along the lines of, "It is often better to write in the language of the OS when doing systems programming." My personal experience with FFIs and C bindings was extremely boring and tedious. C and C++ may be worse languages but are the obvious choice when dealing with libraries written in their own language. > My impression is that a primary design goal for Go is t…

>>although unfortunately the current implementation isn't there yet judging from the Benchmark GameThe benchmarks game Go programs are notably faster when compiled with 6g for x64 --

http://shootout.alioth.debian.org/u64q/which-programming-lan...

Re: Less is exponentially more

#124
post #104
post #88

Earlier quoted context omitted.

That. It's nice for languages to have a "benevolent dictator", but Go insists in a lot of arbitrary but not that good choices like the above. I would add the bizarro build system (go build et al), that if you want to use you have to follow some rather silly conventions (a little flexibility would go a long way). The GC also leaves a lot to be desired --they will implement something better eventually, but why wasn't t…

Go language has no syntactic difference between owning and non-owning pointers. Therefore, it is impossible to replace stop-the-world GC with reference counting GC eventually. IMHO that's a flaw in the language design and it's too late to fix it, this train is gone. Nevertheless, we have other good ideas in programming language design these days. Vala, for example, has robust memory management (so it will have predic…

Why would you replace real gc with refcounting?
Post reply on HN