241–249 of 249 posts
And half are from dependencies? ;)
Read the article: As of this writing, the main repo for Juju, http://github.com/juju/juju , is 3542 files, with 540,000 lines of Go code (not included in that number is 65,000 lines of comments). Counting all dependencies except the standard library, Juju is 9523 files, holding 1,963,000 lines of Go code (not including comments, which clock in at 331,000 lines).
Earlier quoted context omitted.
I disagree with the concept of "blessed" syntax in the first place. I want users to write libraries just as powerful as the standard library.
Philosophically, I agree. Pragmatically, generics seem to tempt programmers into writing really weird code in pursuit of some purist notions of terseness or reusability. After having used Go as well as lots of languages with generics, I will say that most Go programmers write very similar code for very similar problems, and it does make it easier for programmers to understand each other's code. There are a few times…
Earlier quoted context omitted.
I think the point is that Lisp lets you create an ad-hoc, poorly-specified version of any language you like, or perhaps several mashed together, which feels great at the time, but feels horrible when you come back to it later. DSLs/Jargon/New Languages are constructing a new world, and you need to be really sure the costs of that abstraction are outweighed by concrete and lasting benefits in the domain (sometimes the…
The DSL doesn't go away. Your only choices are to implement it, or else read and write the boilerplate you get by imperfectly compiling it in your head.
Earlier quoted context omitted.
I disagree with the concept of "blessed" syntax in the first place. I want users to write libraries just as powerful as the standard library.
Philosophically, I agree. Pragmatically, generics seem to tempt programmers into writing really weird code in pursuit of some purist notions of terseness or reusability. After having used Go as well as lots of languages with generics, I will say that most Go programmers write very similar code for very similar problems, and it does make it easier for programmers to understand each other's code. There are a few times…
Static typing that doesn't cover common use-cases is worse then useless. It gets in your way.
Earlier quoted context omitted.
In C#, you can overload operators, so the + could in theory do anything. What can be confusing is what the meaning of `+` (or `plus` is) QED
Any function can do anything. I can write a function called "read_from_file()" that doesn't read any files. Amazing, I know. Also please actually read the comment before replying: > Operator overloading is nice, but has to be used tastefully.
Earlier quoted context omitted.
Philosophically, I agree. Pragmatically, generics seem to tempt programmers into writing really weird code in pursuit of some purist notions of terseness or reusability. After having used Go as well as lots of languages with generics, I will say that most Go programmers write very similar code for very similar problems, and it does make it easier for programmers to understand each other's code. There are a few times…
I need a tree. Sorted lg(n) structures are incredibly useful, and maps aren't sorted, but as it stands I can't have one without risking runtime type errors. Static typing that doesn't cover common use-cases is worse then useless. It gets in your way.
I agree. See my previous comments.
> Static typing that doesn't cover common use-cases is worse then useless. It gets in your way.
I agree. Fortunately Go's static typing covers the most common use cases. If your primary deliverable is typesafe tree algorithms, Go might not be for you.
Earlier quoted context omitted.
Accordingly to your logic then we should have no language other than C because everyone had decades worth of experience in that language and was not interested in starting fresh again. From my point of view I was very relieved when imperative languages and their adept seemed finally to embrace better tools after Y2K. Apparently now there is Go that follows up with that style (that was perfectly fine for a 10 years ol…
Actually, yes, that's a very good example. Go uses the C syntax. That is the most known syntax in the world. It's in the same family as C++, Java, C#, and in a different league PHP, Javascript. That's the kind of VERY IMPORTANT DETAILS that make a language reasonable. Go didn't attempt to throw under the bus a decade of muscle-memory coding. By comparison, F# or Ruby are total aliens in every regard and not just the…
Earlier quoted context omitted.
It struck me the other day that when using Go codegen tools which generate packages based on a template, e.g. [0], the Go developer is doing manually what the OCaml compiler will do with functors at compile-time. The concepts are fundamentally the same...the effort just happens in different places. [0]: https://github.com/cheekybits/genny
They're very different. Generics in languages that have them are typed —you have to declare up front the methods that your generics support. That's the entire thing that makes ML functors functors. By contrast, generics in languages like C++ and D, as well as the code generation tools for Go, are untyped —you can call whatever functions you want on your types, and if it doesn't work it fails at template instantiation…
I guess the point I was getting at – though improperly phrased – was that if current Go tooling is similar to templates, and templates are similar to functors (in that you're instantiating both but the latter have additional checks for correctness), then perhaps module genericity wouldn't be as tough a sell to the Go team/community.
Earlier quoted context omitted.
You might be interested in my side project: https://github.com/lukechampine/ply IMO when people say they want generics in Go, they really just want a few functional-style methods and functions on slices (e.g. map, filter, reduce methods, and functions like sort, reverse, repeat). So I wrote a compile-to-Go language that allow you to write "Go code" that also has those things. One of the things I've found, though, is…
Wouldn't xs.map((x int) int => x*x) be simple desugaring without messing with the type system?
xs.morph(x => x*x)
As far as I can see, there are two potential annoyances with this approach: you have to explicitly cast constants sometimes (e.g. uint64(3) instead of just 3), and you have to explicitly cast values if you want to return an interface (e.g. io.Writer(file) instead of just file). But these cases are rare enough that I think the tradeoff is worth it.