Re: [go-nuts] Re: Proposal to add Index operator methods

i think this looks nice but realistically only cleans up v simple cases. a lot of the very-verbose-and-not-so-elegant-looking multidimensional math stuff looks "worse" than other languages because go doesn't have operator overloading. it is not clear to me this improves syntax too much in practic

Re: [go-nuts] Re: syscall/js: JS Module Dynamic Imports?

the environment of the wasm decides what you have access to, so you might want to add the import in the HTML around it instead. [Joop Kiefte - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=pq35q) [pq35q] On October 5, 2020 at 18:03 GMT, Eduard Castany wrote: So,

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

On Mon, Oct 5, 2020 at 10:31 AM Vladimir Varankin wrote: > > Or, it will be written as assert.Equal(got, want, > fmt.Sprintf("MyFunction(%v)", input)), but that is harder to write, and > therefore less likely to be written. > > That obviously depends on the implementation details but since we tal

Re: [go-nuts] Re: syscall/js: JS Module Dynamic Imports?

So, adding to the header does NOT seem to import anything into Go's wasm. I'm thinking that this is because modules do not have global scope so Go has to import them itself, rather than delegating the loading to JS, to be able to use them. Any ideas? On Tuesday, 29 September 2020 at 16:34:13 U

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

> Or, it will be written as assert.Equal(got, want, fmt.Sprintf("MyFunction(%v)", input)), but that is harder to write, and therefore less likely to be written. That obviously depends on the implementation details but since we talk about testify the API is: assert.Equal(t, want, got, format, [args

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

On Mon, Oct 5, 2020 at 8:47 AM Viktor Kojouharov wrote: > > I don't find any difference between calling t.Errorf and assert.Something > with a provided message. Both will populate the test log, with the later > giving you more details exactly where things differ from the expectation. The differ

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

Truth. I would even go farther and say that mocks are a code smell - and lead to very brittle tests. > On Oct 5, 2020, at 8:14 AM, 'Bryan C. Mills' via golang-nuts > wrote: > > As for mocking dependencies: in my experience, the best strategy is often > not to. > > It is a good idea to avoi

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

I don't find any difference between calling t.Errorf and assert.Something with a provided message. Both will populate the test log, with the later giving you more details exactly where things differ from the expectation. On Monday, October 5, 2020 at 3:03:48 PM UTC+2 Bryan C. Mills wrote: > I t

[go-nuts] Re: Go is easy to lean. But other languages are hard to forget

"It takes many months of immersion in idiomatic Go for these scars to have a chance to heal." Well, those other languages were also good at specific things that Go might not be specifically designed for. So all the things you learned from other languages was not simply waste. It was good for s

[go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

As for mocking dependencies: in my experience, the best strategy is often not to. It is a good idea to avoid depending on services or resources external to the test, such as other production services. However, in my experience you'll get much better test fidelity — you'll find more real bugs, a

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

I think that FAQ entry really *is* referring to jUnit-style assert functions, including those provided by testify. The core of the problem is that `assert` functions generally *cannot* provide enough context to produce useful test failures

[go-nuts] Re: Go is easy to lean. But other languages are hard to forget

You won't write good idiomatic Go just after 1 day of learning it. Even after a week. воскресенье, 4 октября 2020 г. в 23:25:19 UTC+3, Amnon: > Go is a beautifully simple language. It is easy to learn. > Most programmers can learn to write working production code within a day. > > But learning

Re: [go-nuts] Go is easy to lean. But other languages are hard to forget

thankfully I chose to learn go as my first language...so all good then :-) On Monday, October 5, 2020 at 10:23:32 AM UTC+1 era...@gmail.com wrote: > I believe all these are statements of facts based on practical > observations that one finds out that to learn GO one needs to unlearn and > then

Re: [go-nuts] Go is easy to lean. But other languages are hard to forget

I believe all these are statements of facts based on practical observations that one finds out that to learn GO one needs to unlearn and then learn again. For GO, that is indeed the way to GO. On Mon, Oct 5, 2020 at 12:21 AM Tyler Compton wrote: > I wonder if mailing lists for all languages get