Author here :) It's inspired by Haskell, yes, but not a dialect. Syntax is very much open for change still and that's really not the most important bit. Semantics are not like Haskell, more Go + polymorphism.
I'm a bit disappointed by the double colon; it's my least favorite part of Haskell syntax (I probably shouldn't care, but there you go). It also bugs me in PureScript. However, Agda, Idris, and Elm, all of which have syntax heavily inspired by Haskell, all do it the "right way", so there's no reason a Haskell-inspired language can't. Plus, this doesn't look that much like Haskell, certainly not to the point of being derivative.
Haskell is a bit of the odd man out in terms of syntax for type annotations. Scala, OCaml, Agda, Idris, Elm all use single colon. I'm actually unsure why Haskell is the way it is.
Haskell's designers wanted single colon for the cons operator, and the cons operator is legal on the left-hand side of an "equation" (sorry, don't recall the official terminology) because Haskell allows pattern matching there.
I'be been mulling over a similar concept for a while, really excited for this. Go has such great tooling and a nice ecosystem, but could use some language improvements, like coffeescript or the alt JVM languages.
I really want sum types, strict semantics, and untyped IO, and a good ecosystem.
The compiler is very fast, and in absence of interactive development that's good. The cross compilation is also a thing I guess? I just use docker anyways.
But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got."
The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project.
For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay.
Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool...
I just don't get why this ecosystem has adherents.
>The cross compilation is also a thing I guess? I just use docker anyways.
Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all.
>But no... I mean... I can get a lot of editors to do a better job of formatting.
I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc...
>Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW
The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies.
>so crazy that the ecosystem got a basic race detector before a basic interactive execution tool...
Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too.
> Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine.
Which IS the primary use case for nearly all of Go's interesting use cases. The exceptions are CLIs for API access? But you're going to have some trickiness with testing in these cases that warrant a non-trivial build-test cycle anyways. If that works well for you that's wonderful.
A good packaging of Go with some helper shell commands is also quite nice, for other reasons.
> I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc...
You say this like it's a good thing. I see only the downsides. I'm not much of a fan of Python's contemptuous ecosystem either.
> The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`.
It most assuredly has not addressed this issue. All it's done is decreased the confusing filesystem zigguraut so that a single repo checkin doesn't look patently ridiculous. Pretty important when GitHub is the primary code distribution mechanism.
But so long as the maintainers of Go pretend that everyone will always keep master up to date and never make breaking changes, Go projects are still at a disadvantage compared to every other civilized combiled build+deps tool.
I had high hopes for Go vendoring, but examinations in 1.5 really reinforced to me that the maintainers and designers of Go are interested in the (less compliant) real world issues everyone runs into, don't care about shipping reusable code to a wide audience over a long period of time.
Languages with contempt for programmers as a central tenant often have problems like these.
> Go projects do not decay if you've vendored your dependencies.
Hope you don't have a library with bugs. I sure found many in the libraries I pulled and if I put down a server for a month to work on something else, then tried to grab a security update? It was never not a headache.
> Am I crazy that I prefer having a race detector over a REPL?
I only refer to situations and inanimate objects as crazy. Anything else is disrespectful. You awknolwedge interactive development is necessary but don't want first class support for it. I just don't understand why you wouldn't want to actually have something that could integrate into a real workflow. Sharability is something we already can get with trivial pastebin/gist integration.
I mostly mean vim-go and all the tools it relies on. Dependency management is awful. All the IDE-like features that actually work well in vim are great.
What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean that.
A lot of people say this to mean that object types can't be set to nil. The classic fix is to implement parametrized types (which Go has resisted), although since Go is rabid about simplicity and puts a low priority on generality (generic maps but no other containers, automatic JSON but no other serializations, actor model keywords but no other concurrency primitives, type switch but no real pattern matching), it might better fit the Go philosophy to define only one kind of fallible type, like maybe[T], which is always either T or an error.
Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ?
And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
> Why just maps? why not sets, with useful set methods ?
Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write.
Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
In what way does Go have great tooling? Your compiler doing dependency management is one of the worst things that Go did (and I'm sure they'd do it differently if they could have their time again). It makes packaging libraries impossible, it caused the whole vendoring thing to happen. If you're talking about gofmt or govet, C has had stuff like that for years. Go's main selling point IMO is that they have added as little to the basic "C" language as possible while also adding as many updated semantics and concepts as possible.
I suspect you are just hating. The fact that you immediately glom onto the dependency management issue which EVERYONE KNOWS AND KEN AND ROB ARE REALLY SORRY YALL and also try to cut gofmt and govet off at the pass, which come on, let's be real, the fact that something exists that might remotely resemble those concepts is an extremely fucking far cry from them being standard community practices which if you don't see the value of that then you never dealt with other people's C code... indicates that you know in your heart of hearts exactly how great Go's tooling is. go run, go test, go build, boom! so simple. Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that.
There are plenty of good third-party options available for dependency management (nice double standard btw since you apparently have no problem with third-party stuff for fmt/vet/lint concerns) and there is also this https://golang.org/cmd/go/#hdr-Vendor_Directories so a better world is coming don't you fret.
> Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that.
go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)
go race is Thread Sanitizer, in fact, but see again my point about being part of the community best practice vs. a third-party tool you may or may not have heard of.
Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.
I wrote Go code all the time, and I don't /hate/ it. But it would be a mistake to call Go's tooling "incredible". The race detector is /sometimes/ useful, but it doesn't do any "real" analysis (you have to be very close to the race window in order to trigger the race detector to complain, which is quite difficult for more obscure race conditions based on random variables). The Linux kernel (which as we all know is written in C) has lots of far more sophisticated detection of lock contention and other such things at runtime. But I think you need static analysis if you actually want to figure out where races might exist in your code.
Vendoring makes life hard for people who have to package software. Traditionally, you have build dependencies which are the libraries your software uses. In Go (because nobody follows semantic versioning when changing the API of their libraries, and the Go tooling doesn't allow you to specify versions of a package -- WHICH IS ACTUALLY CRITICAL) you just have to dump all of your dependencies into the same place as your source and be done with it. I don't see why people see vendoring as the solution. Defining version dependencies in your source is the solution if you want to go with "our source code defines what we need to pull in". Don't get me started on the static linking issue. Oh, and build dependencies have to be packaged as source code (packaging them in their compiled form is quite hard to do).
Note that that issue makes perfect sense, and the odds of it affecting you are very very very small. I've written a lot of go code, and have never been affected by it.
So... GHC Haskell, really? The deployment profile, at least, is identical to Go in that you can just link statically and copy the binary.
I mean, I don't necessarily condone it, but if you're into "recipe programming" you can just use the Turtle package/modules and get pretty far. The tutorial is pretty amazing. I'm not saying it's a bad thing, necessarily, but I'm one of those crazy people who thinks that a little bit of cogitation should be (and is!) rewarded. Maybe I'm wrong.
EDIT: Oh, wait, you said "untyped IO". What does that mean, I wonder?
I don't know if this will be of interest, but I actually started my FP "journey" using O'Caml, oh (pun!) 10-15 years ago, but once I actually learned Haskell for real I didn't look back. There was just no contest. I've actually written a couple of pretty cool libraries for O'Caml that gained some traction in the community, way back when... which is a long-winded way of saying that I'm not a noob when it comes to O'Caml, so it's not that I don't understand what it can do for you :)
(I appreciate that people may have different requirements; mine were and are mostly around my own productivity -- not so much real-time/low-latency/predictable performance/etc.).
So any new functional language with static types is now a bug-ridden, half implementation of Haskell? Wow, that's arrogance. Haskell was one of this language's three named influences (along with Lisp and Go).
Anyway, very cool project. I look forward to trying it out.
Yeah, I'm aware of what's he's riffing off (note that Greenspun's had nothing to do with Haskell). It's still an annoying attitude to have toward any new functional language that happens to share a syntax with Haskell.
Is that the gp's attitude toward PureScript, for example? Or Idris?
If that's the case, it must be nice/"interesting"/boring having found a "forever language". Look forward to seeing how that's going for him in 2030.
I usually come here to defend the language designer, but I think this particular submission is worthy of brief, critical and vague criticism because there's not a lot to criticize.
The user guide and language reference is very thin and it's missing the two critically distinctive features of Go, namely goroutines and channels.
It's a nice idea, but there's not a lot here to talk about.
How is this _not_ exactly what I said it was though? The author even says in the readme that it's a NIH version of Haskell.
I love PL mental masturbation as much as anyone else, but stuff like this is equivalent to an oil spill in a freshwater lake with 20 endangered species.
The problem is the genre of the snarky dismissal. Perhaps there was a solid point behind what you said, but you didn't express it that way.
It's a tragedy of the commons. Posting such coments never feels harmful, but once they get above a certain level the whole community becomes filled with toxic fumes. This threshold is lower than it seems—the damage isn't only in the fumes your comment gives off, but in the encouragement it gives others to do the same.
Tragedy of the commons plus broken windows theory is not an auspicious combination, so we try to be proactive about asking people not to do this.
My gut feeling is that an early stage project such as Oden should simply focus on the technology, grow the community and then at a later stage consult with the community if they want to introduce a code of conduct.
> focus on the technology, grow the community and then at a later stage consult with the community if they want to introduce a code of conduct.
Yeah, that approach didn't work out too hot for nanomsg. I'm not a big fan of CoC's[1], but if you're doing to use one, best to be up-front about it, so people can make an informed decision about whether or not they want to participate in the project. Rather than springing it on them later.
1. I prefer a ruthless enforcement of the standards of polite company. Chances are your mama/daddy/grandma taught you how to behave. Just enforce that, no reason to use some (often) patronizing document to enforce society standards.
Though I really shouldn't care, I admit it kinda turned me off when I saw the prominent code of conduct. I don't think they are needed (you can ban a troublemaker without a document) and I don't think they are effective (never met a bully that cared if a piece of paper said "be nice"). But mostly, seeing these codes pop up everywhere bothers me because I like to think of hobby software as one of the last realms on earth where you can have a meritocracy without the politically correct nonsense that eats at your soul the rest of the day. I feel like the open source community is starting to get tainted, somehow, and I hope in time there's a strong reaction the other way.
I agree that political correctness should not be the focus of a technical discussion, and like-wise there shouldn't be anything remotely offensive in those kinds of discussions either. Just as political correctness eats away at your soul, racism/sexism/etc... do too. You're free to run your own projects however you want; the maintainer of Oden obviously doesn't want to work with people who require the freedom to be offensive in public forums. If that offends you then don't work on it.
It's more nuanced than that: Many people have no intention of being offensive but don't want to be regulated either.
CoC projects often attract the worst politicians who are just acceptably polite on the surface but absolutely cold and ruthless in their actions. Ironically, these people also often tend to blog about politeness in OSS.
No one is forcing you to work on the project. If you think this is how CoC works, then stop working on projects that add them. The rest of us will work on whatever projects we want and hopefully every piece of crap will decide they don't want to work on any of the projects because they're offended by CoCs.
> the maintainer of Oden obviously doesn't want to work with people who require the freedom to be offensive in public forums.
I'm sure that is the intent, but they make the code of conduct explicitly (and I would say somewhat aggressively) political. I think that it will deter a number of otherwise respectful and conscientious people.
In any case, I am glad that they are publishing a code of conduct. I don't like the content of the particular CoC they chose, but at least I know where they stand.
As for the project itself, it looks really cool. It seems to be addressing the kind of concerns that keep people like myself from engaging in the Go ecosystem.
There's already a very strong reaction the other way - every time a project with a CoC is posted here or anywhere else, it's pointed out with plenty of people agreeing that it's awful and a blight on society. The PHP community has people outright angry about its attempt at passing even an extremely watered-down CoC which essentially says "as long as you don't explicitly say 'on behalf of the PHP project, we all hate your guts, <insert slur here>', it's fine". And yet every time a project without a CoC is posted, nobody says a word - that's the default, that's what's expected.
I agree with you that the code of conduct initially felt a bit eh -- but the thing is, can you really ban a troublemaker without a standard? Otherwise you start a whole drama war and leadership gets accused of playing favorites and it's just a clusterfuck nobody wants.
While it would be equally as nice to pretend everybody could just be fucking polite human beings as to pretend a true "meritocracy" could exist, that's just not reality.
I just had a sinking feeling in my stomach that in a few years we might have to amend Wadler's Law of Language Design to include bickering over the code of conduct.
The funny thing is, if you're not being an asshole to people, and stay on-topic, you will never have any problem with the CoC. Keeping out the wrong kind of crowd from the start actually sounds like a better idea than (in the worst case) having to fix a shitty community after the fact.
Which do you think is the mode effective time to implement a style guide: at the start of a project or after thousands of lines of code have been committed?
I don't see this as being dramatically different - establishing the ground rules for contributors before they commit a single line, so they can make an informed decision as to whether they want to be involved or not.
Rust started with a CoC - in fact, its founder states that it wouldn't have been started without one.
When starting a project, you're not just starting writing a bunch of code. You're potentially starting an entire community, and in time an entire ecosystem. You can't pretend that you're just writing code and ignore the people developing and using it. Simply taking the default stance ("liberty is paramount, over and above people's protection from harassment and discrimination") is not apolitical, here or anywhere else.
Most people would not like to found a community that winds up going against their ethics on hugely important things related to the community and project itself. If you were an ethical vegan, you'd be unlikely to start a forum for steak-eaters - and if you're ethically pro-social-justice, you're unlikely to start a community based on unrestricted free speech within that community. To do anything else is to explicitly and intentionally support what you believe to be unethical, which is inherently unethical in itself.
I have no interest in oden, but I think it's good to get those kind of people out of a community as soon as possible, and they can go work on urbit or something instead.
I think your objection is less to codes of conduct as such than to their usual contents and the kind of environment they intend to create. You can have a very different code of conduct, e.g., one that goes something like this:
I don't expect it's everyone's cup of tea (I'm not even sure I'd use it unedited, if at all), but there's work being done in this space that isn't a variant of, say, the Contributor Covenant.
84 comments
[ 4.5 ms ] story [ 130 ms ] threadyeah :: Num yeah = 3
repeating yeah two times is ugly.
(I'm not saying I agree with the decision.)
I really want sum types, strict semantics, and untyped IO, and a good ecosystem.
It's story of building and dependency management is one of its major areas of growth in the last 2 releases because the developers agree.
But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got."
The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project.
For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay.
Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool...
I just don't get why this ecosystem has adherents.
Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all.
>But no... I mean... I can get a lot of editors to do a better job of formatting.
I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc...
>Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW
The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies.
>so crazy that the ecosystem got a basic race detector before a basic interactive execution tool...
Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too.
[0]: https://play.golang.org
Which IS the primary use case for nearly all of Go's interesting use cases. The exceptions are CLIs for API access? But you're going to have some trickiness with testing in these cases that warrant a non-trivial build-test cycle anyways. If that works well for you that's wonderful.
A good packaging of Go with some helper shell commands is also quite nice, for other reasons.
> I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc...
You say this like it's a good thing. I see only the downsides. I'm not much of a fan of Python's contemptuous ecosystem either.
> The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`.
It most assuredly has not addressed this issue. All it's done is decreased the confusing filesystem zigguraut so that a single repo checkin doesn't look patently ridiculous. Pretty important when GitHub is the primary code distribution mechanism.
But so long as the maintainers of Go pretend that everyone will always keep master up to date and never make breaking changes, Go projects are still at a disadvantage compared to every other civilized combiled build+deps tool.
I had high hopes for Go vendoring, but examinations in 1.5 really reinforced to me that the maintainers and designers of Go are interested in the (less compliant) real world issues everyone runs into, don't care about shipping reusable code to a wide audience over a long period of time.
Languages with contempt for programmers as a central tenant often have problems like these.
> Go projects do not decay if you've vendored your dependencies.
Hope you don't have a library with bugs. I sure found many in the libraries I pulled and if I put down a server for a month to work on something else, then tried to grab a security update? It was never not a headache.
> Am I crazy that I prefer having a race detector over a REPL?
I only refer to situations and inanimate objects as crazy. Anything else is disrespectful. You awknolwedge interactive development is necessary but don't want first class support for it. I just don't understand why you wouldn't want to actually have something that could integrate into a real workflow. Sharability is something we already can get with trivial pastebin/gist integration.
It's story of building and dependency management is one of its major areas of growth in the last 2 releases because the developers agree.
Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ?
And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write.
Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
Maybe I'm missing something, but? https://golang.org/src/encoding/xml/example_test.go
https://github.com/golang/protobuf uses this as well.
There are plenty of good third-party options available for dependency management (nice double standard btw since you apparently have no problem with third-party stuff for fmt/vet/lint concerns) and there is also this https://golang.org/cmd/go/#hdr-Vendor_Directories so a better world is coming don't you fret.
go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)
Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.
Vendoring makes life hard for people who have to package software. Traditionally, you have build dependencies which are the libraries your software uses. In Go (because nobody follows semantic versioning when changing the API of their libraries, and the Go tooling doesn't allow you to specify versions of a package -- WHICH IS ACTUALLY CRITICAL) you just have to dump all of your dependencies into the same place as your source and be done with it. I don't see why people see vendoring as the solution. Defining version dependencies in your source is the solution if you want to go with "our source code defines what we need to pull in". Don't get me started on the static linking issue. Oh, and build dependencies have to be packaged as source code (packaging them in their compiled form is quite hard to do).
The 'go' tool is not the compiler. The compiler is 'gc' and does not know anything about dependency management.
I'd like to see a language that compiles to Go, but also to Javascript, so that code can run on both client and server without changes.
That language should not equal Go, because, honestly, some aspects of this language are quite strange: https://golang.org/doc/faq#nil_error
I mean, I don't necessarily condone it, but if you're into "recipe programming" you can just use the Turtle package/modules and get pretty far. The tutorial is pretty amazing. I'm not saying it's a bad thing, necessarily, but I'm one of those crazy people who thinks that a little bit of cogitation should be (and is!) rewarded. Maybe I'm wrong.
EDIT: Oh, wait, you said "untyped IO". What does that mean, I wonder?
I kind of want Ocaml with a Go sized ecosystem.
(I appreciate that people may have different requirements; mine were and are mostly around my own productivity -- not so much real-time/low-latency/predictable performance/etc.).
[0]: http://www.frege-lang.org/
[1]: https://github.com/Frege/frege/wiki/Differences-between-Freg...
[2]: http://try.frege-lang.org/
Anyway, very cool project. I look forward to trying it out.
Edit: I'm assuming he's joking
Is that the gp's attitude toward PureScript, for example? Or Idris?
If that's the case, it must be nice/"interesting"/boring having found a "forever language". Look forward to seeing how that's going for him in 2030.
Not that I disagree, but I feel the HN comment section has become very predictable.
The user guide and language reference is very thin and it's missing the two critically distinctive features of Go, namely goroutines and channels.
It's a nice idea, but there's not a lot here to talk about.
I love PL mental masturbation as much as anyone else, but stuff like this is equivalent to an oil spill in a freshwater lake with 20 endangered species.
It's a tragedy of the commons. Posting such coments never feels harmful, but once they get above a certain level the whole community becomes filled with toxic fumes. This threshold is lower than it seems—the damage isn't only in the fumes your comment gives off, but in the encouragement it gives others to do the same.
Tragedy of the commons plus broken windows theory is not an auspicious combination, so we try to be proactive about asking people not to do this.
http://oden-lang.org/code-of-conduct/
My gut feeling is that an early stage project such as Oden should simply focus on the technology, grow the community and then at a later stage consult with the community if they want to introduce a code of conduct.
Yeah, that approach didn't work out too hot for nanomsg. I'm not a big fan of CoC's[1], but if you're doing to use one, best to be up-front about it, so people can make an informed decision about whether or not they want to participate in the project. Rather than springing it on them later.
1. I prefer a ruthless enforcement of the standards of polite company. Chances are your mama/daddy/grandma taught you how to behave. Just enforce that, no reason to use some (often) patronizing document to enforce society standards.
CoC projects often attract the worst politicians who are just acceptably polite on the surface but absolutely cold and ruthless in their actions. Ironically, these people also often tend to blog about politeness in OSS.
I'm sure that is the intent, but they make the code of conduct explicitly (and I would say somewhat aggressively) political. I think that it will deter a number of otherwise respectful and conscientious people.
In any case, I am glad that they are publishing a code of conduct. I don't like the content of the particular CoC they chose, but at least I know where they stand.
As for the project itself, it looks really cool. It seems to be addressing the kind of concerns that keep people like myself from engaging in the Go ecosystem.
I like to think that, but I'm really not convinced that it's true.
While it would be equally as nice to pretend everybody could just be fucking polite human beings as to pretend a true "meritocracy" could exist, that's just not reality.
http://lambda-the-ultimate.org/node/4287
Somebody shoot me when that happens.
Unless you post a political opinion that someone doesn't like on your own Twitter feed. Then you're in for it, cf. Opalgate.
I don't see this as being dramatically different - establishing the ground rules for contributors before they commit a single line, so they can make an informed decision as to whether they want to be involved or not.
When starting a project, you're not just starting writing a bunch of code. You're potentially starting an entire community, and in time an entire ecosystem. You can't pretend that you're just writing code and ignore the people developing and using it. Simply taking the default stance ("liberty is paramount, over and above people's protection from harassment and discrimination") is not apolitical, here or anywhere else.
Most people would not like to found a community that winds up going against their ethics on hugely important things related to the community and project itself. If you were an ethical vegan, you'd be unlikely to start a forum for steak-eaters - and if you're ethically pro-social-justice, you're unlikely to start a community based on unrestricted free speech within that community. To do anything else is to explicitly and intentionally support what you believe to be unethical, which is inherently unethical in itself.
1. Don't be rude.
2. Don't be stupid.
3. Check your identity politics at the door.
4. Listen to the moderators.
5. Do not complain about rules 1-5.
I don't expect it's everyone's cup of tea (I'm not even sure I'd use it unedited, if at all), but there's work being done in this space that isn't a variant of, say, the Contributor Covenant.