Educational and entertaining as always Evan, I would love to see a similar writeup on Elixir. Maybe a Chicago Boss port is in order ;)
Evan actually spent a lot of time enabling Elixir support in CB when he was actively involved with the project.
Four days of Go
161–170 of 187 posts
Re: Four days of Go
#162Earlier quoted context omitted.
In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…
I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?
it's not a "not now" approach, they are simply not going to add any new significant feature to the language (source : https://thechangelog.com/148/?utm_content=bufferf8f9d&utm_me... ) . Go will not have generics at all.
People don't want generics for the sake of it, they want type safety.
Re: Four days of Go
#163Earlier quoted context omitted.
In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…
Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If…
[deleted]
Re: Four days of Go
#164Earlier quoted context omitted.
I think you left off the key part of his point, namely "when recursively parsing unknown json data structures". json parsing in Go uses reflection, which not only means it is slow, but if your input is not consistent (like say.. a log file with 20 different possible formats), it can be quite painful and very verbose.
Do you have any resources demonstrating that JSON parsing in Go is slow?
Here are a few google results:
* http://erickt.github.io/blog/2014/11/03/performance/ and http://erickt.github.io/blog/2014/11/11/benchmarks/
* https://github.com/ugorji/go-codec-bench
* https://github.com/golang/go/issues/5683
In my own testing it was faster (even with ffjson) to pre-clean my data in cpython or pypy, and then emit some intermediary format (like capnproto) for the go code to consume. I was parsing huge files full of lots of non-uniform json with many formats.
For most use cases though, the fact that json is "slow" is probably not a huge factor, as network IO or something else is likely the gating factor. For those uncommon cases though, I wish the native json lib in Go was faster.
Re: Four days of Go
#165In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
I remember when Go first came out and I thought "wow, that looks interesting, I'll check it out", then when I was checking it out, I found that the language enforced placing opening curly braces at the end of a line rather than wherever you want, such as at the beginning of the next line (which I generally prefer).
There was no option to even be flexible about this, for example, by programming one way and then using gofmt before committing code, because you will literally have an incorrect program if you put the opening brace on the next line due to automatic semicolons placed at the end of lines.
And so ended my 15 minutes of playing with Go.
Re: Four days of Go
#166In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languag…
And how often do we actually encounter these "unknown" json data types? Using an official api? Never.
Re: Four days of Go
#167In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languag…
This is great. I have struggled with using Go in web apps.
It's nice to know that I am not crazy in questioning its viability in that area.
Re: Four days of Go
#168Earlier quoted context omitted.
> unless of course you're a masochist and ... want static typing Some people say to prototype in a dynamically-typed language and then switch to a static language later. Dynamic typing might save keystrokes, but typecasting and type-checking do require lots of typing, and who cares that much about a few hundred extra keystrokes anyway? Some people say to create whole, large apps in dynamically-typed languages, but th…
I think you left off the key part of his point, namely "when recursively parsing unknown json data structures". json parsing in Go uses reflection, which not only means it is slow, but if your input is not consistent (like say.. a log file with 20 different possible formats), it can be quite painful and very verbose.
I believe you that it's slow, but I'm not sure I know enough to understand how it's a knock against Go as a language. Is it something that's impossible to fix without changing the syntax?
Anyway, you could always use a highly-optimized JSON parser written in C[1], so it shouldn't be a deal-breaker for anyone interested in Go.
Re: Four days of Go
#169Earlier quoted context omitted.
Both Eclipse and IntelliJ have supported cleaning up imports and running style tools on every save for years. I have no idea why this would be a core part of any language.
It's not part of Go-the-language. It's part of the distribution of the most popular (ok, only) implementation of that language.
Not true.
It is illegal for a package to import itself, directly or indirectly, or to directly import a package without referring to any of its exported identifiers.
Re: Four days of Go
#170Earlier quoted context omitted.
no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.
> Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Rust has language stability (in practice right now, and officially once we hit 1.0 in a month), so we in fact do guarantee this. > Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. Languages can do that too, in which case the entire langu…
> Languages can do that too
Languages can abandon own std lib? Keep away from such languages.
> HTTP is a fast-moving standard (see HTTP 2, for example), and so it's very important to be able to iterate quickly to support new features.
Golang doing it just fine, so Rust can too.
> I disagree. Web applications need HTTP, but many applications aren't Web applications.
I'm talking exactly about web applications, not about all applications. And if web applications is not the field of Rust - let us know about it. Right now is not obvious and even web frameworks exist in Rust.