[go-nuts] nice user survey re Go-lang
https://www.zdnet.com/article/google-go-programming-language-three-months-in-and-you-are-productive-say-developers/ -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b5e8870e-55d5-49a6-a9e6-d35eedcec2e6n%40googlegroups.com.
Re: [go-nuts] Error handling
Rust lang, very early in its evolution, saw the need to create its operator '?' to more efficiently manage error handling. But the guardians of Go lang have resisted any changes to its clumsy method of error handling despite it being a major concern of Go users for a very long time. On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote: > Dnia 2021-02-13, o godz. 17:44:47 > Michael MacInnis napisał(a): > > > I've been playing around with reducing error handling boilerplate > > You're not alone. Hundreds of us went into such thinking in the first weeks > of reading/using Go - yet before we noticed how much more productive we > are with Go's "boilerplate" than we were in languages where handling errors > (failures) was "a problem of others", including future-us as "others". > > Perceived consensus of the Go community is that "error handling > boilerplate" > is a strong feature. I.e. in normal production software you MUST handle > failures > and you should do it as close as possible to the source of said failure. > > Go helps with that. Even team's proposal was finally retracted: > https://github.com/golang/go/issues/32437 Discussion there is lengthy, > but worth > reading to sense why wider community considers "boilerplate" as asset. > > Error handling proposals umbrella: > https://github.com/golang/go/issues/40432 > > > Michael. > > Hope this helps, > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com.
[go-nuts] Linux distro..based only on GO
All Linux distros are currently based on several languages (Python, Perl, C/ C++ etc) as well as tool-type packages like GTK etc ... What if, there was a Linux distro based entirely on GO ? This would greatly reduce the Linux footprint given the huge number of libraries Linux currently uses to support each language. It seems to me a Linux distro based entirely on GO would be another major GO milestone. Is this do-able given the current capability of GO? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/95de7ec1-4932-4bca-9f33-4def9a023988n%40googlegroups.com.
[go-nuts] Re: Generics, please go away!
Hopefully the GO leadership will isolate Generics to a module so that those who dont wish to use them can quietly ignore them, while those that believe Generics have value can just import the relevant module(s) On Tuesday, December 29, 2020 at 4:32:30 AM UTC-5 rickti...@googlemail.com wrote: > My point of view is that Generics should not become part of the Go > standard library. I appreciate there are use cases where it is very helpful > to have, but I do not believe that adds value to Go. The real value for Go > is it's simplicity, avoidance of generics and avoidance of classes. This > makes the language accessible and approachable to all, which is > increasingly more valuable. Go appeals to new-comers and experienced > developers because it is simple, and comfortable. The rate of uptake in > computing technology is still subject to Moores law, and today we see a new > type of programmer emerging, the 'citizen developer'. > > Go follows time proven computational concepts, it does not follow the 'new > paradigm' tribes, it's roots are firmly planted in statically typed > procedural/functional programming techniques, and this maps well to much of > the literature available. The growth of entry level developers ( aka > 'citizen developers' ) will be exponential over the next decade, and in > that landscape it is Go's simplicity that will win the day. > > On Monday, 28 December 2020 at 17:35:40 UTC L Godioleskky wrote: > >> " If generics gets added to Go, we're opening a very dangerous door, and >> it will be the downfall of Go because - and Robert Griesemer this is >> especially addressed to you - what's next then? Seriously, what's next? >> ... " >> >> .. AI, followed by cryto currency and asexual repoduction >> On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote: >> >>> No polls. It's not a matter of majority rule! >>> >>> It's a matter of understanding why generics was left out of Go from the >>> start, like classes was left out of Go. If we start adding stuff that >>> the original developers of Go left out by purpose, we're not >>> understanding the design choices that went into Go, which is exactly >>> what makes Go unique! >>> >>> Go was a major slap in the face to all the hype that has polluted the >>> programming industry for the past 30-40 years, which is why Go got so >>> much hate in the beginning from all the hype loving people. >>> >>> If you want to add generics to Go, if you want to change how errors are >>> handled, if you want X, Y or Z feature that Java, C++, or some other >>> complex language has got, then go use that language! Why are you even >>> here!? >>> >>> The design choices that went into Go was not made randomly, nor were >>> they made by just anyone. Please understand that the people who >>> designed Go, and we all know who they are, had/has tons of experience >>> and the pragmatic approach they took is what make Go stand out so >>> beautifully! >>> >>> If generics gets added to Go, we're opening a very dangerous door, and >>> it will be the downfall of Go because - and Robert Griesemer this is >>> especially addressed to you - what's next then? Seriously, what's next? >>> Let the community decide by majority!? Is that how we design a >>> professional programming language now? By majority rule?! NO! The >>> majority is all about hype and shine. >>> >>> Adding generics to Go will rip out the spine of the philosophy of Go >>> and I for one will not be a part of that. I have more than 30 years of >>> experience in the business and I fully understand why generics and >>> classes and all the other clutter was left out of Go. >>> >>> If generics gets added to Go, we're a big enough part of the community, >>> that passionately hate that, that we can manage to fork Go - which I >>> strongly believe will then be the right thing to do! >>> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c75ea174-1626-4374-8bf0-bb41ba83036fn%40googlegroups.com.
[go-nuts] Re: Generics, please go away!
" If generics gets added to Go, we're opening a very dangerous door, and it will be the downfall of Go because - and Robert Griesemer this is especially addressed to you - what's next then? Seriously, what's next? ... " .. AI, followed by cryto currency and asexual repoduction On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote: > No polls. It's not a matter of majority rule! > > It's a matter of understanding why generics was left out of Go from the > start, like classes was left out of Go. If we start adding stuff that > the original developers of Go left out by purpose, we're not > understanding the design choices that went into Go, which is exactly > what makes Go unique! > > Go was a major slap in the face to all the hype that has polluted the > programming industry for the past 30-40 years, which is why Go got so > much hate in the beginning from all the hype loving people. > > If you want to add generics to Go, if you want to change how errors are > handled, if you want X, Y or Z feature that Java, C++, or some other > complex language has got, then go use that language! Why are you even > here!? > > The design choices that went into Go was not made randomly, nor were > they made by just anyone. Please understand that the people who > designed Go, and we all know who they are, had/has tons of experience > and the pragmatic approach they took is what make Go stand out so > beautifully! > > If generics gets added to Go, we're opening a very dangerous door, and > it will be the downfall of Go because - and Robert Griesemer this is > especially addressed to you - what's next then? Seriously, what's next? > Let the community decide by majority!? Is that how we design a > professional programming language now? By majority rule?! NO! The > majority is all about hype and shine. > > Adding generics to Go will rip out the spine of the philosophy of Go > and I for one will not be a part of that. I have more than 30 years of > experience in the business and I fully understand why generics and > classes and all the other clutter was left out of Go. > > If generics gets added to Go, we're a big enough part of the community, > that passionately hate that, that we can manage to fork Go - which I > strongly believe will then be the right thing to do! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6326efe5-e9c4-48a2-b39c-2ce14897fb9en%40googlegroups.com.
[go-nuts] Re: Generics, please go away!
Hopefully, the Go team will encapsulate all generics in a separate module(s), so that those of us who want to ignore them can easily do so On Monday, December 21, 2020 at 7:26:02 AM UTC-5 Space A. wrote: > Unfortunately it was expected that creators of the language will not > resist forever being under the pressure of masses most which do not even > code in Go, or not use Go as the main language and just following patterns > and shitty idioms they took elsewhere. Generics are bullshit crap in its > essence. They either don't improve anything or overused (with some huge > cost). I'm telling this as someone who had 15+ years in Java before moved > to Go. I was literally happy when I found that Go has almost everything > which is good about programming and almost nothing bad. And I knew that it > will start degrading at some point. I just keep some hopes that community > will fork the language after this "Cyberpunk" releases. Rephrasing "no is > temporary, yes is forever": good Go is temporary. > > > > > воскресенье, 20 декабря 2020 г. в 22:38:54 UTC+3, Martin Hanson: > >> I think people who want generics added to Go should go and program in >> Java or C++. >> >> Adding generics to Go will ruin the beautiful simplicity of the language >> and I haven't found a single example in which adding generics to Go pays >> off. >> >> Even with the examples of having two almost identical functions reverse >> some list, one of ints and one of strings, seriously!? We already have tons >> and tons of open source reusable code that covers all use cases which >> people complain about. >> >> Go was designed without generics purposefully from the start and Go is >> fine just the way it is. >> >> Adding generics means that we're opening the door to the beginning of >> bloating Go with all the crap that Java, C++ and all the other complex >> languages has gotten over the years, and Go was designed specifically >> without that clutter. So we add generics, then what? Classes? >> >> Adding generics to Go ruins that beautiful simplicity that went into the >> design and the added complexity just isn't worth it! The standard library >> have managed just fine without generics and so have we! >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ad1b3da3-f270-47f9-8c08-ffc5ea6cb5efn%40googlegroups.com.
Re: [go-nuts] Re: Question re fcns that return multiple values
OK ...I now see the wisdom of why Go does not allow my simple
example...Thanks ALL for you help on this
On Wed, Aug 7, 2019 at 12:46 PM Adrian Ho wrote:
> On 7/8/19 9:44 PM, lgod...@gmail.com wrote:
> > f( g() ) compiles when g returns exactly the number of args that f()
> > requires, but if g() returns only 1/2 that number f (g(), g() ) wont
> > compile !! ...Is this not a Golang absurdity ??
>
> On the contrary, it's a good example of Go's pragmatism, allowing some
> relatively safe syntactic sugar without opening a Pandora's box of
> complete generality.
>
> To illustrate Rob Griesemer's point, in his comment that I linked to in
> my earlier reply
> (https://github.com/golang/go/issues/973#issuecomment-142733515),
> consider the following package that's maintained by someone else (your
> colleague or an Internet stranger):
>
> ===
>
> package mu
>
> func CalcDispersion (in []float64) (variance float64, stddev float64) {
> ... }
>
> func CalcAvg (in []float64) (sma21 float64, ema21 float64) { ... }
>
> ===
>
> Then you use it as follows, assuming a future Go version that allows
> "spreading" of multi-valued function returns:
>
> ===
>
> v, sd := mu.CalcDispersion(i)
>
> sma, ema := mu.CalcAvg(i)
>
> func delta (a, b float64) float64 { return a-b }
>
> d1 := delta(mu.CalcDispersion(i))
>
> d2 := delta(mu.CalcAvg(i))
>
> func me (variance float64, stddev float64, sma21 float64, ema21 float64)
> float64 { ... }
>
> m := me(mu.Alpha(i), mu.Beta(i))
>
> ===
>
> All well and fine, until one day, the package interface changes after
> some discussion:
>
> ===
>
> package mu
>
> func CalcDispersion (in []float64) (variance float64, stddev float64,
> range float64) { ... }
>
> func CalcAvg (in []float64) (sma21 float64) { ... }
>
> ===
>
> Yes, that's a breaking change, and the Go compiler helpfully screams at
> you on every assignment statement ...except the last one. And since the
> compiler was silent about that last line, you're almost certainly gonna
> miss the HUGE logic error in it...and spend days scratching your head at
> the absurd results your program throws up.
>
> --
> Best Regards,
> Adrian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/lFBWugE1nt0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/504b90aa-afea-02b7-dfd9-eabf9eace9dc%4003s.net
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALYe2v4szoy_XMohyegRLZ3GQAfZ3B1W2xhhn9i2fb-9noA8Vg%40mail.gmail.com.
Re: [go-nuts] Why does this simple snip generate an infinite loop ?
Ok, thanks.
On Thu, May 2, 2019 at 1:26 PM Robert Engels wrote:
> Because when u add 1 to 0xff it goes back to 0 since it is only 8 bits
>
> On May 2, 2019, at 12:22 PM, lgod...@gmail.com wrote:
>
> func main() {
>
> var c8 uint8;
> var S [256] uint8;
>
>for c8 = 0x00; c8 <= 0xff; c8 += 0x01 { S[c8]= c8 }
> }
>
> --
> 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.
>
>
--
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.
Re: [go-nuts] Go if else syntax .. suggested replacement
The lack of a Go ternary operator is at odds with Go's major theme of clean and easy to read syntax. Those who choose not to use the ternary operator can always resort back to Go's current 'if -else' or 'case' syntax. So Go syntax suffers no negative impact by adding the ternary op to its syntax list. Those opposed to the ternary op should not be allowed to deny it use other Go programmers, that consider it useful. On Wed, Apr 24, 2019 at 8:31 AM Robert Engels wrote: > That’s not what he meant. It takes 5 lines for a trivial assignment > if/else rather than 1 line with a ternary with no loss in readability. > > > On Apr 24, 2019, at 7:11 AM, Jan Mercl <0xj...@gmail.com> wrote: > > > >> On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann < > r.mark.volkm...@gmail.com> wrote: > >> > >> The idea of adding the ternary operator to Go has been debated many > times. It’s clear that those in charge have a strong dislike for it. For me > the lack of the ternary operator is one of main things I dislike about Go. > It’s nails on a chalkboard for me to write a five line “if” statement when > it could have been a one line assignment statement. > > > > That's a nice example why Go does not have the ternary operator. > > Fitting five if statements into one line makes the code probably > > unreadable just for the imaginary gain of saving some vertical screen > > space. > > -- 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.
Re: [go-nuts] go execution speed for float64 based calculations vs float32
Thanks guys for the cogent clarifications..I will now forget about converting to float32 on 64-bit CPUs I'm in the process of converting my often-used C-code apps to Go because I see tremendous advantages of Go vs C. I've been using C,C++ for many years and only recently discovered Go... My Go knowledge is 100% self-taught and entirely based on Go web docs, tutorials, blogs etc A good doc on "C to Go code conversion",would help me greatly, so if anyone knows of one, I'd appreciate knowing about it I'm somewhat reluctant to use software based conversion On Mon, Apr 22, 2019 at 8:55 AM Marvin Renich wrote: > * lgod...@gmail.com [190421 21:56]: > > ?? On 64-bit CPUs does anyone have any experience comparing the run-time > > speed of float64 based calculations vs float32 ? > > > > Some of my C-code when translated to Go-code seems to run noticeably > > slower, so I'm wondering if I can speed things up by converting float > vars > > to float32 vs float64 > > I would be more suspicious of the C-to-Go conversion than float32 vs > float64. While Go has similarities to C, rewriting in Go with its > strengths and weaknesses in mind will produce much better code all > around (performance and maintainability). > > ...Marvin > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/3Io9xRmqAWM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
