171–180 of 257 posts
Earlier quoted context omitted.
I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.
The Techempower benchmarks are using the old version of GHC, 7.6, and the Golang devs have been tuning Go's core libraries to win at this specific benchmark.
7.4, last time I checked.
Earlier quoted context omitted.
I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers. Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want tha…
Languages without decent compile-time type systems are pg's own blub.
The strong typing and lazy evaluation of Haskell makes it easy for functions to take only one argument at a time. Although a function could take a tuple parameter, it is usually rewritten to take each component of the tuple as a separate parameter, which makes the strong typing and built-in currying simple, higher structures like monads possible, and a syntax to suit this style. Lisp functions and macros, on the other hand, must be variadic to enable the homoiconicity of the language. It's therefore much more difficult for parameters to be typed, or to curry them. The syntax requires explicit visual nesting.
The poster child of each style, monads and macros, are thus two peaks in language abstraction simply because of these different required foundations of each, and if you, lmm, have achieved Haskell-style enlightenment, then dynamic variadic homoiconic languages are your blub.
Earlier quoted context omitted.
Because of the implicit thing! The api designer doesn't have to write the interface, you can do it yourself. As long as naming conventions are kept to and the signature matches, you can apply this anywhere. Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and…
> Because of the implicit thing! Known as structural typing and available in most modern languages.
Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?
Earlier quoted context omitted.
Go has nothing unique (and maybe that makes it special). I mean that sincerely, everything it has, has been done dozens of times. Interfaces in Go are implicit (which is important, IMHO) and really, tremendously simple. These two features make them exceptional easy to use, and ACTUALLY used. I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitl…
replace Go with Python in the text, and you won't see a difference: there are iterable, keyable, file-like interfaces, etc. And creating your own is trivial.
What people like about Go is its mix of features, not some specific one by itself.
Earlier quoted context omitted.
> It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compres…
Because of the implicit thing! The api designer doesn't have to write the interface, you can do it yourself. As long as naming conventions are kept to and the signature matches, you can apply this anywhere. Imagine a close() interface in Java. There isn't one - but having a try {...} finally { x.close(); } can be very useful sometimes. But having interface graphs made of granular interfaces makes everything slow and…
https://docs.oracle.com/javase/7/docs/api/java/lang/AutoClos...
You can even leave out the finally when you use an autocloseable resource.
//r will be closed no matter what
try(Resource r = getResource()) {
} catch(SomeException e) {
}Earlier quoted context omitted.
Composition I read your comment, but this seems more like A sane standard library with proper interfaces and not a language feature per se (also composition to me sounds like the pattern where you create objects which are composed of other objects but that's not what you mean, right)? What you display here can be done in pretty much any language suporting inheritance (or I'm missing something), so your point is those…
I think the point here is implicit inheritance. There are many interfaces in Go, but you don't need to specify which interface you are implementing. So you can easily implement io.Reader and io.Writer among many others, without extending your type declaration for lines on end. This means that many standard types in Go implements either io.Reader and/or io.Writer. That's neat. The implicit interface implementation is…
Earlier quoted context omitted.
> Because of the implicit thing! Known as structural typing and available in most modern languages.
available in most modern languages Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?
F# also supports it, given its ML linage.
C# tricks with dynamic, although in this case it is dynamic typing, so not really the same thing.
Earlier quoted context omitted.
replace Go with Python in the text, and you won't see a difference: there are iterable, keyable, file-like interfaces, etc. And creating your own is trivial.
Yes, but Python doesn't compile to a single binary, and usually runs much slower. What people like about Go is its mix of features, not some specific one by itself.
Earlier quoted context omitted.
Languages without decent compile-time type systems are pg's own blub.
pg writes about macros as the top of the blub ladder whereas you mention compile-time type systems, but I'd say it isn't a ladder but a twin-peaked hill, i.e. strongly-typed lazy functional code (e.g. Haskell) and dynamically-typed variadic homoiconic code (Lisp). They have an "impedance mismatch" such that they don't inter-translate very well, unless they use clunky addons like Template Haskell macros or Typed Cloju…
Earlier quoted context omitted.
There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.
Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.