[go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

On Thursday, April 5, 2018 at 7:26:19 PM UTC+2, bingj...@gmail.com wrote: > > Almost 10 years golang appears in the world. 10 years is not a short > duration. I think if it is not popular until 2020, it will never be popular. > I think it's already fairly popular. > I find one feather: they

[go-nuts] Re: Help On Kqueue Server

Go has goroutines -which makes network programming a lot easier- so that we don't have to deal with thread pools, epoll, kqueue or i/o completion ports. Creating a goroutine per request is cheap, you should try this approach first and not optimize unless you're certain that goroutines are the ca

[go-nuts] Re: Appreciating Go

Go is great because it's creators are great. Being smart alone doesn't mean anything. Bjarne Stroustrup is smart. It takes a good taste, a lot of first hand experience and many other things. Simplicity is the main characteristic of Go. Let's see where it comes from; Ken Thompson is a walking s

Re: [go-nuts] json encoding & decoding interface types

json, but clean method for firefox and chrome objects are completely different. On Tuesday, February 20, 2018 at 1:03:51 AM UTC+1, Burak Serdar wrote: > > On Mon, Feb 19, 2018 at 4:45 PM, Doğan Kurt > wrote: > > Hi great Go community. Sorry it's a long question, but i would re

[go-nuts] json encoding & decoding interface types

Hi great Go community. Sorry it's a long question, but i would really appreciate some guidance. Let's say i have two different objects, browser and executable that implement ScanCleaner interface. type ScanCleaner interface { scan() clean() } type browser struct { Name

[go-nuts] Re: All Forms of Wishful Generics

Generics would divide the Go community. I would probably never use it, like many people who comes to Go from C. People who are already experienced Go programmers also likely to avoid it. Java programmers on the other hand will surely overuse it. There it is, you have two different Go code bases

[go-nuts] Re: why defer function with parentheses

how will you pass parameters if its defer fn? On Sunday, January 28, 2018 at 3:42:03 AM UTC+1, Flying wrote: > > example : > fn := func() { > fmt.Println(10) > } > defer fn() > > > my question is why use defer fn() not defer fn > > > when we use fn() here doesn't it mean call it now ??? > --

Re: [go-nuts] Re: Updating specific elements of a big json file.

That seems to be the only solution. Thanks. On Friday, January 12, 2018 at 12:01:19 AM UTC+1, Burak Serdar wrote: > > > > On Jan 11, 2018 3:36 PM, "Doğan Kurt" > > wrote: > > I think i wasn't perfectly clear. When i say update i actually meant > inse

[go-nuts] Re: Updating specific elements of a big json file.

I think i wasn't perfectly clear. When i say update i actually meant insert, delete, update. I will delete big blocks of elements, insert new ones and modify some. If i have to deal with the json format, what's the point of using json package. I can write a json tokenizer myself. On Thursday,

[go-nuts] Updating specific elements of a big json file.

If i want to *read *just a certain part of a json file, i create my struct and unmarshall the json data. It works wonderfully. But what if i want to *modify *a certain part of the json file and save my changes, of course i don't want other parts to be lost. Consider this json; { "this_i_want_to

Re: [go-nuts] ungetc behavior in go

Thanks it's perfectly clear now. I actually knew that but it didn't look immediately obvious. On Monday, August 14, 2017 at 2:51:13 PM UTC+2, Konstantin Khomoutov wrote: > > On Mon, Aug 14, 2017 at 05:43:04AM -0700, Doğan Kurt wrote: > > > > Consider combining

Re: [go-nuts] ungetc behavior in go

> > Consider combining using the bufio package and scanning form a buffered > reader using fmt.Fscanf(). > Great worked like a charm. I just thought i couldn't pass *bufio.Reader to Fscanf which takes io.Reader. -- You received this message because you are subscribed to the Google Groups "

[go-nuts] ungetc behavior in go

I want to do something analogous to this C code. c = getchar() if (isdigit(c)) { ungetc(c, stdin); scanf("%d", &num); } In fmt package, fmt.Scanf("%d", &num) exists but ungetc doesn't exist. For bufio package, Peek function exists which is great but there is no ReadInt. Is there an elegant so

Re: [go-nuts] "fallthrough statement out of place" in `if` block inside `swicth` block

Fallthrough must be a design choice but goto's restriction is a necessity. What happens if you jump into the middle of an if block? You skipped the condition check, you run the code after the goto label, what about the code before the label, there might be some variables initialized, and how wi

Re: [go-nuts] Re: Generics are overrated.

> > it's amazing to see what people were able to accomplish with 2KB RAM, > *one* general-purpose register, no hardware multiply/divide, > Constraints boost creativity and discipline programmer. You may like this . Today'

[go-nuts] Re: GO Vs D

tactic point of view. > > So, again from a syntactic point of view, I don't think how you can affirm > that it's much easier in Go than in D to declare and use types, references, > functions, methods, slices, arrays, foreach, and all the common stuff > between both langu

Re: [go-nuts] Re: "fallthrough statement out of place" in `if` block inside `swicth` block

In first snippet, i didn't get the second if. cond1 is true anyway. Second snippet is equivalent to if (cond1) { do_stuff() do_other_stuff() } else if cond2 { do_other_stuff() } which is more straightforward than using fallthrough imo. On Wednesday, August 2, 2017 at 9:03:35 AM

[go-nuts] Re: GO Vs D

> > But from my personal experience, D is *at least* as easy to learn than Go, > if not easier. I seriously doubt, no offense. Go is so small and so intuitive, one can argue that there are people out there who knows most of the Go unknowingly :) Just the fact that it doesn't break much with