free thoughts, pick in it, discuss it, let try to be not dogmatic toc - bushigô - example - economic cost - a new language, really ? - imho
*bushigô* Heard about the bushido ? The way of the warrior. Sometimes i feel like working with go is about taking the hard way. I think about bushido because rob s pike surname on the ml is general, and because the path of the samurai must be difficult. I m not a bottom => top developer (from c to php/nodejs, to illustrate) I m a top => bottom dev, i started with php, and now go That way of the bushigô, i believe is not felt strongly for a bottom => top dev, writing C/C++ is way more harder than go, but writing go is way more harder than php, so the way of the bushigô hurts more. see ? *example* Let s try to take an useful example, Dave cheney wrote this cool blog post https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions under small ideas categories. Especially the Prph: Let’s talk about actors See the cool snippet of code it provides, type Mux struct { ops chan func(map[net.Addr]net.Conn) } func (m *Mux) Add(conn net.Conn) { m.ops <- func(m map[net.Addr]net.Conn) { m[conn.RemoteAddr()] = conn } } func (m *Mux) loop() { conns := make(map[net.Addr]net.Conn) for op := range m.ops { op(conns) } } If you follow the current way to go, then you will have to duplicate this code for as many type as you want to chanmutex. Lets not get lost into the technical debate of generic, which i know everyone reading so far think about. *economic cost* Lets talk about this situation as an economic cost. Its an observation that such kind of solution has an economic cost, simply because if you made a mistake into the duplicated code, you ll have to fix it multiple times. And for a beginner mistakes are so easy, right ? So the mess is necessary even more messy, probable consequences => drop off the language, bad experience, feeling of difficulty rather than => thinking genuine experience, ease of fixing my mess, want to do more. That being said, it must be recalled that it is not a fatality, especially for go. Proven fact it has been able to provide solutions with a cheaper implementation cost than other languages on a wide variety of problems. Mainly speaking here about concurrency, type system. Interestingly, if you look at what go is good at, you ll see that it is mostly about which problems the standard lib got solved. See this example, an how it betrayed that go was though to be good at, it s a perfect start for a parser, a typical problem the stdlib has to solve, for c := range "some string to parse" { switch c { case '"': //... } } I d say some construct exists in the go DNA without being formally designed. It was needed, it has been designed to fit nicely. Think about retroactive loops like they use in climate models. This way to look at go, what its good at, what its not, to solve an economic approach of the programming experience, is the pragmatism i currently miss to go beyond the mantras. Surprisingly, it looks likes at early life go, this pragmatism to go beyond the mantras was THE mantra. (one might think about how that probably happened at the moment go entered in production at google, and how surprisingly a private company effort,in that very specific moment, did not lead to more innovation, but conservatism, *but* this is a totally different aspect of the things, and *it does not remove any good to the initial initiative and innovative action taken by google*). *a new language, really ?* That is an hot question for me. I only put in balance few arguments, purely factual, really (...), - go is currently maintained by one the most great team of developers - a new language means to re invent what they are the some of the best at - cutting from that is about shooting its own leg *imho* It is a better decision to take a path to ease the way to go, while being compatible with it. So one can take full advantage of all the good brought by go team, but take a different path on subjects of disagreements. ok, that s it. On Saturday, April 15, 2017 at 4:21:35 PM UTC+2, Stan Lo wrote: > > Hi, Rooby <https://github.com/st0012/Rooby> is a new object oriented > language I created recently (written in Go). It looks just like Ruby for > now because it's mainly inspired by it. But I want it to be a new language > and start developing its own feature when it gets more mature. So I'm > looking for developers who also interested in this project, any help or > idea will help me a lot. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
