[go-nuts] is this safe?

[DV]

I think that's a horrible idea in any language, honestly. You shouldn't be 
mutating the thing you're enumerating. 

-- 
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.

[go-nuts] test debugging woes

[DV]

I wish I could help you, but your description of the problem could not be more 
vague.  Your post can be rewritten as "problem pls help". 

What library is this? Is it on GitHub? Can we look at it? What section of code 
is returning nil? Is nil the problem? Or is there a panic? What's your code 
look like? How are you invoking 'go test'? What's a "citc"? That's just some of 
the questions that sprang into my mind in the first 5 seconds of reading your 
question. 

-- 
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.

[go-nuts] cgo style question

[DV]

Which "style" of wrapping a C array in a Go slice is more idiomatic in this 
code - https://play.golang.org/p/6EbKl22MPQ - "arr1" or "arr2"? They both 
seem to produce the exact same result.

I've seen the "arr2" style more often, but I don't understand why. The way 
I wrapped "arr1" seems more clear to me - you have to know the length of 
the C array, so why not just declare the pointer to the array with the 
correct length to begin with? Why is the 1<<30 bit the more accepted style, 
e.g. here - cgo 
.  It 
seems a bit noisy, especially with having to remember to put the length 
*and* capacity when slicing the array.

I have a feeling I'm missing something important but I don't understand 
what...

-- 
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] "find" for Slices like "append"

[DV]

Go has never been a "let's include all possible methods for all possible 
use-cases for all possible users" type of language. It's just not in its 
DNA. You seem to like Python - so why not stick with Python? Do lots of C++ 
people complain about how Javascript doesn't let you do pointer arithmetic 
or multiple inheritance easily and expect Javascript to include such 
functionality? 

I write Python *and* Go on a daily basis, and appreciate the weaknesses and 
strengths of both languages - I can't say I think that one should be a 
strict subset of the other. Python has multiple inheritance and duck-typing 
as well - should those be part of Go to '"ease" adoption by Python 
programmers? 

"append" exists for slices for the same reason that "delete" exists for 
maps - difficult to implement correctly and efficiently, hard to live 
without it on a daily basis if using those data-structures. Before 
"append", there was a std. lib Vector type (circa 2009 or so) and removing 
Vector and adding "append" was a huge quality-of-life improvement. 

"find" ? Not difficult to implement correctly, *not* hard to live without 
it -> small chance your proposal makes the cut. Barrier of entry is high. 
Just how it is. 


On Monday, September 4, 2017 at 6:56:24 PM UTC-4, Martin Rode wrote:
>
> Ian, 
>
> thanks for the "generic" function. I appreciate.
>
> I think such a function would provide beautiful symmetry to the already 
> existing "append" function Go has.
>
> Martin
>  
>
> On Wednesday, August 9, 2017 at 5:53:45 PM UTC+2, Ian Lance Taylor wrote:
>>
>> Here is a generic Find function that works for all types, using the 
>> language defined == operator.  It will panic if invoked incorrectly. 
>>
>> package main 
>>
>> import ( 
>> "fmt" 
>> "math" 
>> "reflect" 
>> ) 
>>
>> // Find returns the index of val in the slice s, or -1 if not found. 
>> func Find(s, val interface{}) int { 
>> sv := reflect.ValueOf(s) 
>> l := sv.Len() 
>> for i := 0; i < l; i++ { 
>> if sv.Index(i).Interface() == val { 
>> return i 
>> } 
>> } 
>> return -1 
>> } 
>>
>> var tests = []struct { 
>> s, v interface{} 
>> want int 
>> }{ 
>> {[]int{1, 2, 3}, 2, 1}, 
>> {[]int{1, 2, 3}, 4, -1}, 
>> {[]string{"a", "b"}, "a", 0}, 
>> {[]float64{0, 1, math.NaN(), 2}, 2.0, 3}, 
>> {[]float64{0, 1, math.NaN(), 2}, math.NaN(), -1}, 
>> } 
>>
>> func main() { 
>> for _, t := range tests { 
>> if got := Find(t.s, t.v); got != t.want { 
>> fmt.Printf("Find(%v, %v) = %d, want %d\n", 
>> t.s, t.v, got, t.want) 
>> } 
>> } 
>> } 
>>
>

-- 
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] Re: Generics are overrated.

[DV]

I think "need" is indeed one of those special words that means different 
things for different people.
Go doesn't "need" generics and you technically don't "need" anything except 
air, water, food, a sharp spear, and shelter, to survive.

I recently started toying with writing quick-n-dirty programs for the 
original NES and it's amazing to see what people were able to accomplish 
with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, 
etc Heck, it's even *fun* to do some of those things using 6502 assembly 
from scratch! Doesn't mean I sometimes don't wish for certain 
quality-of-life improvements with that experience, even though I can 
definitely do it all from scratch, given infinite free time. 

Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 

Go to me is an awesome little house on a beach. I love going to it in the 
summer. Everything is great about it. Almost. It just doesn't have hot 
water. I have to heat water myself and carry it for a 1/4 mile every time I 
want to shower. It's kind of annoying, but not a big deal in itself to make 
me stop going to the awesome super fun summer house. 

I really like functional programming paradigms for data transformation 
tasks. I like chaining 
map(...).reduce().filter(.).skip(.).drop().select() 
etc. and building a nice pipeline through which my data can flow. I *can* 
do it all with loops, of course. Just like I can carry hot water for a 1/4 
mile every day. 

I'd love to be able to write generic compile-time type-safe functions but I 
can live without them. 


On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>
> As with every community, there's the silent majority and the vocal 
> minority. 
>
> It's easy to be confused, and think that the lack generics is a major 
> issue in the Go community. It is *not*.
>
> The number 500,000 Go developers worldwide has been thrown around a lot 
> this month. (https://research.swtch.com/gophercount)
>
> Evidently most of them are using Go just fine -- as individuals, at 
> startups, and at huge companies.
>
> At every scale, Go's adoption is amazing and the the projects they're 
> building are changing the world:
>
>- You don't need generics to write Docker.
>- You don't need generics to write Kubernetes.
>- We could add so much more to this list, but you get my point.
>
> So, let's stop feeding the trolls. The far fewer than 1% of the people who 
> have not yet taken the time to appreciate Go for what it is, and therefore 
> find it lacking in comparison to something they have taken the time to 
> appreciate. I don't mean to belittle those people by calling them trolls, 
> but they are trolling. I'm sure most of them who give the language an 
> honest, unbiased try will come around.
>
> Imagine if Go programmers went to other language mailing lists and 
> complained about the lack of goroutines and channels, which clearly make 
> those other language "unfit for concurrent programming." That would be 
> equally unhelpful.
>
>
>

-- 
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.

[go-nuts] Is there any golang package available for building mongodb query from plain logic expression string or URL?

[DV]

This seems pretty trivial, tbh. You just parse the URL query string and 
construct a JSON doc out of it? 

Go's philosophy in general is that it's better to just write the code yourself 
sometimes, even multiple times, than to pull in a dependency. Especially for 
something like this. 

Do you remember the Node community's "left-pad" fiasco from last year? 

-- 
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.

[go-nuts] Puzzle for golang guru.

[DV]

Very subtle fix:
https://play.golang.org/p/xTEGpgIyP6

-- 
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.

[go-nuts] Puzzle for golang guru.

[DV]

Very subtle fix:
https://play.golang.org/p/xTEGpgIyP6

-- 
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.