[go-nuts] My views on Go and why it's better than Scripting

Hi, I could be wrong (please correct me ;-), but here you are what I think about Go: INTRODUCTION Computers and software were initially developed for scientific computing; e.g., ALGOL and FORTRAN from the 1950s! Therefore, several computer languages and libraries have been invented and are used

[go-nuts] Re: My views on Go and why it's better than Scripting

Thanks for your suggestion! To put it in context, I'm drafting a plan for my colleagues in order to make a case for using Go in teaching instead of Fortran or C. On Friday, March 2, 2018 at 1:29:45 PM UTC-8, dorival...@gmail.com wrote: > > Hi, I could be wrong (please correct me ;-), but here

[go-nuts] Re: My views on Go and why it's better than Scripting

Thanks for your suggestions! On Saturday, March 3, 2018 at 5:56:41 AM UTC-8, Alex Rice wrote: > > Hi, thanks for sharing. I am not convinced about the reasons stated why Go > is better than the other languages you mentioned. I am just learning Go, > but I have 20 years of experience as a profess

[go-nuts] Re: My views on Go and why it's better than Scripting

Great feedback, Matt and Wang. Thanks and Cheers! On Monday, March 5, 2018 at 2:13:29 AM UTC-8, Wang Sheng wrote: > > I am c++/C expert, I like because it is easier than C++ and more powerful > and flexible than C > with Golang , you would not need consider create/destroy/monitor pthread >

Re: [go-nuts] My views on Go and why it's better than Scripting

Awesome! I'll read the paper too. Thanks! On Monday, March 5, 2018 at 5:31:06 PM UTC-8, kortschak wrote: > > This was essentially my thinking in choosing Go to write my > bioinformatics library in - mainly because much of our code will be > written and maintained by students, but we want goo

[go-nuts] Re: My views on Go and why it's better than Scripting

Thanks for sharing your experience! On Tuesday, March 6, 2018 at 4:46:54 PM UTC-8, Rich wrote: > > I am a systems administrator. I find it easier and faster to write a > program in Go than it is to script it in Bash. Since writing scripts is > something most Sys Admins do I've had to write them

[go-nuts] Computations with complex numbers may be slow if care is not taken

Hi, This is an interesting benchmark: Given this function: // ImagPowN computes iⁿ = (√-1)ⁿ // // i¹ = i i² = -1 i³ = -i i⁴ = 1 // i⁵ = i i⁶ = -1 i⁷ = -i i⁸ = 1 // i⁹ = i i¹⁰ = -1 i¹¹ = -i i¹² = 1 // func ImagPowN(n int) complex128 { if n =

Re: [go-nuts] Computations with complex numbers may be slow if care is not taken

Re(x) in > {-1,0,1} and Im(x) in {-1,0,1} before undertaking the general computation. > > On Thu, Aug 3, 2017 at 5:43 PM, Dorival Pedroso > wrote: > >> Hi, >> >> This is an interesting benchmark: >> >> Given this function: >> // ImagPowN computes iⁿ =

[go-nuts] Re: Computations with complex numbers may be slow if care is not taken

complex(0, x), complex(float64(n), 0)) } } } With the following results: BenchmarkImagXpowN-32 20 10299 ns/op BenchmarkImagXpowNcmplx-32 10 18595 ns/op Now it's "just" 1.8x faster. Cheers D On Friday, August 4, 2017 at 10:43:41 AM UTC+10, Dorival Pedroso

[go-nuts] Re: Generics are overrated.

Agreed! And I was a "heavy" user of templates (see e.g. http://mechsys.nongnu.org/, including extensive use of "expression templates") ~5 years ago before the "wonders of Go". Let's focus on making Go faster instead! Cheers. Dorival On Friday, July 28, 2017 at 10:41:10 PM UTC+10, dogan...@dod

[go-nuts] How to optimize as with -O2 from Gcc? (50x speedup)

I've noticed that this C code: #include "math.h" int main() { double x = 2.5; int Nmax = 1000; for (int N=0; Nhttps://groups.google.com/d/optout.

[go-nuts] Re: Concurrency Testimonial

Great news. Thanks for sharing On Sunday, August 6, 2017 at 1:37:11 AM UTC+10, Mandolyte wrote: > > This past week I wrote an "audit" program for management to see how a long > running data migration effort was going (it will take several months to > complete). I was little discouraged when I fo

Re: [go-nuts] Re: How to optimize as with -O2 from Gcc? (50x speedup)

Fixed. Cheers. On Sunday, August 6, 2017 at 12:23:57 PM UTC+10, Michael Jones wrote: > > Great. Hope it helps. I had a typo in power 0 (which is never called. > Change the return to 1.0. > > On Sat, Aug 5, 2017 at 6:50 PM > wrote: > >> Thanks, Michael. >> >> I've created a tiny project with those

[go-nuts] Re: error handling needs syntactical sugar

Hi, Error management in Go is perfect! But I like the idea of `watch` (may we drop the `if`?) So, `watch` would work in the context of a function like `defer`. However, this would effectively become a `catcher` for errors (instead of `panics`) within the `defer` function, right? Also, I think

[go-nuts] Re: error handling needs syntactical sugar

by the way, above, I was thinking of `watch` as a counterpart of `var`... On Tuesday, September 5, 2017 at 8:56:24 AM UTC+10, Dorival Pedroso wrote: > > Hi, > > Error management in Go is perfect! > > But I like the idea of `watch` (may we drop the `if`?) > > So, `watch` w

[go-nuts] Re: error handling needs syntactical sugar

Hi, the `watch err` could also work in "APIs" that already return "error". For instance: package myapi func First() (err error) { watch err err = internalFunction(1,2,3) err = internalFunction(3,2,1) err = internalFunction(1,3,2) } On Tuesday, September 5, 2017 at 4:27:20 AM U

[go-nuts] Re: error handling needs syntactical sugar

, Dorival Pedroso wrote: > > Hi, the `watch err` could also work in "APIs" that already return "error". > > For instance: > package myapi > > func First() (err error) { > watch err > err = internalFunction(1,2,3) > err = internal

Re: [go-nuts] error handling needs syntactical sugar

Hi Axel, thanks for your input. I think Martin's proposal is all right. We'll certainly keep suggesting all good practices to handle errors (I myself have tons of error messages + handling..). Go is perfect in doing this. We can even mimic "try" + "catch" with "panic" + "recover" (although I r

Re: [go-nuts] error handling needs syntactical sugar

I'm working on a Go project right now and I realised I've written 569 "if err != nil": find . -iname "*.go" -exec grep -inH "if err != nil" {} \; | wc -l 569 On Tuesday, September 5, 2017 at 4:57:45 PM UTC+10, Axel Wagner wrote: > > > > On Tue, Sep 5, 2017 at 8:49 AM, > > wrote: > >> Axel, >>

Re: [go-nuts] error handling needs syntactical sugar

;ve done only 20% of the error messages... (lots of work still needed...) On Tuesday, September 5, 2017 at 5:15:16 PM UTC+10, Dorival Pedroso wrote: > > I'm working on a Go project right now and I realised I've written 569 "if > err != nil": > find . -iname "

[go-nuts] Re: error handling needs syntactical sugar

Hi Martin; What about two commands "*watch*" and "*watchif*"? The first works as the "*var*" command and the second as the "*if*" command. "*watch*" does: 1. In a function with *error* as an output (anywhere): returns in case the *err* declared with *watch err* (or *watch myerror*) becom

Re: [go-nuts] error handling needs syntactical sugar

ame as *var*. > > Martin > > > On Tuesday, September 5, 2017 at 9:20:10 AM UTC+2, Dorival Pedroso wrote: >> >> And I've written 231 error messages (I use a function called chk.Err() to >> do so): >> find . -iname "*.go" -exec grep -inH "chk

[go-nuts] Re: error handling needs syntactical sugar

// do stuff > yo1, err := do_stuff1() > yo2, err := do_stuff2() > yo3, err := do_stuff3() > } > > > Martin > > > On Tuesday, September 5, 2017 at 9:32:50 AM UTC+2, Dorival Pedroso wrote: >> >> Hi Martin; >> >> What about two commands "

Re: [go-nuts] Re: error handling needs syntactical sugar

s should work. > > Please reread that blog post. > > -rob > > > On Tue, Sep 5, 2017 at 5:45 PM, Dorival Pedroso > wrote: > > Fair enough. This would be perfect. Cheers > > > > > > On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10, > >

Re: [go-nuts] Re: error handling needs syntactical sugar

g enough about how errors should work. > > Please reread that blog post. > > -rob > > > On Tue, Sep 5, 2017 at 5:45 PM, Dorival Pedroso > wrote: > > Fair enough. This would be perfect. Cheers > > > > > > On Tuesday, September 5, 2017 at 5:42:

Re: [go-nuts] error handling needs syntactical sugar

t! Also, I think we're just wondering whether a "syntactical sugar" is worth in Go or not (speaking for myself, of course). Best wishes. Dorival On Tuesday, September 5, 2017 at 11:07:12 PM UTC+10, ohir wrote: > > On Tue, 5 Sep 2017 00:20:09 -0700 (PDT) > Dorival Pedros

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightw

[go-nuts] Re: error handling needs syntactical sugar

What about the following? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightw

[go-nuts] Re: error handling needs syntactical sugar

What about? func something() (x int, err error) { watch err != nil { // this is only required to watch out in case "err" ever becomes non-nil return // the error will propagate outside (same as "return err") } res, err = acquireResource() // will return straightway (because we

[go-nuts] Re: error handling needs syntactical sugar

Hi, yes we need the check condition you had before in defer. That seems fine. But there may be some other problems I haven't thought of. Cheers -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving em

[go-nuts] Re: error handling needs syntactical sugar

Since *defer* "is the last thing to happen", I think this code is all right: func something() (x int, err error) { watch err != nil { return } res, err = acquireResource() defer func() { if err == nil { err = res.Close() } }() err = abc1(

Re: [go-nuts] Re: error handling needs syntactical sugar

Hi Michael, I fully agree with handling each single error ("health issue") as they are discovered. The idea of "watch" is NOT to replace this procedure. It's just a "syntactic sugar" to do what you are doing already. Cheers. Dorival -- You received this message because you are subscribed to

[go-nuts] Re: error handling needs syntactical sugar

Agreed, Tim. This discussion helped me to realise that try/catch is pretty good; e.g. we never even bothered discussing this topic in our C++ code http://mechsys.nongnu.org/ at all... In the end of the day, we want to treat ALL errors (obviously...). Go is great that we have two approaches. R

Re: [go-nuts] Re: error handling needs syntactical sugar

Yes, Nigel! try/catch in Python may at times looks uglier that err != nil. I think the reason try/catch didn't bother us in C++ is that we had lots of macros to simplify the work... In Go, we don't have macros but we don't need to wrap things with "try" and just need to "recover" panics, I thin

Re: [go-nuts] Re: error handling needs syntactical sugar

Hi Dave, The "watch" strategy would, of course, allow us to do the important steps you've mentioned (e.g. clean up and so on). For instance: watch err != nil { // do the important things return err } The watch basically "groups common tasks". For example, If we have so many tasks, we c

Re: [go-nuts] Re: error handling needs syntactical sugar

please replace: "will return immediately to the [...]" with "will jump immediately to the [...]" (sorry) On Friday, September 8, 2017 at 4:07:35 PM UTC+10, Dorival Pedroso wrote: > > Hi Dave, > > The "watch" strategy would, of course, allow us to do th

Re: [go-nuts] Re: error handling needs syntactical sugar

Sure! I'm happy to listen to the experience of you all and to keep working using the existent approach. Thanks, everyone. Dorival On Friday, September 8, 2017 at 10:29:02 PM UTC+10, Marvin Renich wrote: > > * Dorival Pedroso [170908 02:08]: > > The "watch" strategy

[go-nuts] [hooks] go get --post-download "make"

Hi, is it possible to run scripts after go get? -- 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

Re: [go-nuts] [hooks] go get --post-download "make"

ok. I need the other way around (go get => calls make of bash).. thsnks On Saturday, August 10, 2019 at 12:15:18 PM UTC+10, saurabh singh wrote: > > It's possible to run go get in a make but not the other way around. > What's your use case? > > On Sat, Aug 10, 2

Re: [go-nuts] Re: Go 1.6.1 Link problem on Windows:

-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dygcs01179.o):(.idata$5+0x0): > first defined here > > > > On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote: >> >> Hi, >> >

Re: [go-nuts] Meet runtime.typedslicecopy: nosplit stack overflow error when cross platform compiling.

I'm getting a similar error on Windows 10 with IntelliJ, even though it's *not* cross-compiling... Apparently IntelliJ needs "-N -l" for debugging (with delve...) My installation was pretty standard (out of the box); but a simple: package main import "fmt" func main() { fmt.Print("hello") } fail

[go-nuts] Who Loves Go?

Hello Everyone, I'm preparing a list of people / companies that use Go and *really like Go*. The plan is to present this to a large crowd of undergraduate students (and others). So, suggestions are very welcome! Many thanks. Dorival -- You received this message because you are subscribed to

[go-nuts] directory name versus package name

Hello, I haven't noticed that the code below (located at *$GOPATH/src/MyWrapper*): package mylib import "fmt" func SayHello() { fmt.Println("hello") } is actually being installed (go install) as a *MyWrapper* package, even though the package name was explicitly given as *mylib*. I couldn't f

[go-nuts] Re: directory name versus package name

I like the idea that the go tool would enforce matching directory and package names. This would help us in case we forget to be consistent... On Wednesday, March 29, 2017 at 5:18:52 PM UTC+10, Dorival Pedroso wrote: > > Hello, > > I haven't noticed that the code below (locate

[go-nuts] Minecraft and Go (with project Malmo)

Hello, Everybody: If you like Minecraft and Go, you may like project Malmo and the GoWrapper I have been working on (https://github.com/cpmech/malmo forked from here ). For example, a minimal