Re: [go-nuts] Go and GPUs

[Kevin Chadwick]

Didn't AMD and Intel open source their drivers. Or are you talking about
firmware here?

I thought that is how OpenBSD can run well with them but not with Nvidia hw?

-- 
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/CANNfpqdQAq%3DKmvg9pVZR_aXUwaGe7HEnzHhqFhS7Phcs5V_eOg%40mail.gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Kevin Chadwick]

> >>One solution is apparently to use a module like a giant mono repo, aka 
> >>gopath>
Still it requires for this replace

You do not need replace, unless you are amalgamating multiple modules.

You can just create a folder named e.g. library with a .go file; package lib

Then in your other folders with package main, .go files:

You can

import (
lib "{moduleName}"/library
)

-- 
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/221d2ca3-ab29-0d21-5386-dc86ebb5d190%40gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Kevin Chadwick]

>
>
> https://golang.org/ref/mod

The how to code docs need improving for packages but once you initialise a
module. You can create folders to hold different packages within the root
folder containing the .mod file. I'm not sure modules are not a regression
compared to gopath in some respects though? One solution is apparently to
use a module like a giant mono repo, aka gopath.  I never used gopath
extensively myself.

-- 
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/CANNfpqeQT2HX82UERnX1YXYD-sx4s%3DMFwWx2Urh%3DhzSjddi84w%40mail.gmail.com.

Re: [go-nuts] I'm missing godoc for local packages after converting to modules.

[Kevin Chadwick]

I found you had to cd to each directory with a .mod file and run it there.
A global option would be nice to know about.

-- 
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/CANNfpqeTbX9xpTXRo5U-LR5J2upKgbigSgtNKKxDHC5by5SQ1w%40mail.gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

Thank You for answering

Regards, kc

-- 
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/CANNfpqe%3Dfmi235qY_AN9rVTrXnki3khi6t0k-ZP8EB%2Bh54JFZQ%40mail.gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

On 3/17/21 1:57 PM, Axel Wagner wrote:
> No, I am saying that your assumptions that generics pose a problem is wrong.
> There is no technical reason that would prevent the authors of TinyGo to
> implement them, without too much trouble. Certainly far less trouble than 
> other
> language features they already support.

That is not what you said or meant and I didn't make an assumption.

> 
> AIUI that's also the answer you got from them, so  I don't understand the 
> confusion.

s/confusion/question/

That you ignored

I was basically asking if TinyGo and Go should communicate more. I assume from
what you have said, that you disagree.

-- 
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/e92fef38-42c9-e68f-e42f-813a961d0063%40gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

> I'm actually happiest with the language part of GO. Not necessarily so much, 
> the> implementation. It has the potential to make me happy, anyway.> >
"https://tinygo.org/lang-support/stdlib/;
I should clarify.

My interest is purely memory safety and ease of porting existing vendor provided
C code etc..

stdlib is a bonus, but attractive in some cases.

-- 
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/6710c498-ef44-1abd-1383-b545271e760c%40gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

On 3/17/21 10:02 AM, Axel Wagner wrote:
> When I look at the Go language feature page of TinyGo
> , I don't think that GC is the only or 
> largest
> hindrance to using it with normal Go programs. TBQH I'm always surprised that
> people call it a Go implementation - it certainly uses Go syntax, but it's IMO
> not even close to complete.

I'm actually happiest with the language part of GO. Not necessarily so much, the
implementation. It has the potential to make me happy, anyway.

"https://tinygo.org/lang-support/stdlib/;

>  
> 
> *Might* Generics adoption within the stdlib make more of it unusable
> (assuming generics poses a problem, it might not).
> 
> 
> No. Generics can be implemented as a purely compile-time feature
> .

So, like I said, if you avoid using parts of the stdlib. Or are you saying that
existing parts of the stdlib will not migrate to using Generics. If Generics has
any affect on the above link then I would have a conflict of interest in that I
hope they would migrate generally in order to avoid empty interface use.

-- 
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/b91bf116-a23b-8fdf-468b-cb83897d0a5b%40gmail.com.

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

On 3/17/21 12:11 PM, Space A. wrote:
> I don't think Java failed on micros, for instance look at JavaCard, a lot of
> SIM-cards are running applets based on it. SIM cards can be a dying technology
> on itself, but still, I think there was a huge success. Not sure about other
> "small places" because I never touched them in my work.
> 

I didn't know about JavaCard. Quite hard to gauge it's suitability to mmuless
systems, nevermind particular ones. I don't believe Pythons variant is suitable
but JavaCard might be. I don't want to write Java though anyway. I'm also not a
fan of Java's security record either.

> With regards to TinyGo, it's interesting. I also heard that they are sponsored
> by Google. Which is good. However Richard Musiol, the creator of GopherJS and
> person responsible for WebAssembly in Go compiler
> https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit#heading=h.mjo1bish3xni
> 
> in one of his comments on gihub clearly said that he is not paid or in any 
> form
> financially supported. And he's doing his work in spare time. I just don't 
> get it.
> 
> There is gioui project which aim at implementing crossplatform GUI without
> relying on C libs, and they have already showcased very promising results. Any
> support from Google? Like some symbolic $100 bucks check per month? You knew 
> the
> answer.
> 
> I'm pretty sceptical about TinyGo. It implements a subset of language, and I
> tried it for my WASM project, but didn't find it suitable at all. If I only
> wanted a small part of Go, I'd choose C.

Looks like JavaCard implements a far smaller subset than tinyGO according to
their site. If you have 256k Ram and that is a generous option, then it is going
to be a subset. I thought it was surprising how much of the stdlib is said to be
working. C compatibility is also important that both tinyGo and Zig offer. I
want to get away from C as much as possible! I shouldn't have to do so much like
writing reasonably memory safe array handling functions to be confident in my
codes security. Because C can't be arsed to offer safer compile options.

-- 
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/9be9cf18-7191-c81c-9b86-e15d1827f944%40gmail.com.

[go-nuts] Healthy tinygo Was: No generic, part -2

[Kevin Chadwick]

>> Go will loose its uniqueness and values, will never become a next big
>thing. No cross platform GUI, no Android, and browsers (GopherJS is
>more dead than alive, WASM idk) is also a big question. It will be a
>"bad copy" of Java or other mature languages (with better and more
>powerful generics and lots of other built-in capabilities), niche tool
>for cli, devops and microservices (until the fashion will turn into
>monoliths or whatever this spiral thing brings up again). Now think
>where all your investments in language skills be in next few years.
>
>All of those things could certainly come to pass.
>
>However, I'm very skeptical that adding generics to the language will
>cause them to come to pass.
>
>And, fortunately, even with generics I believe that Go will remain
>significantly simpler than languages like Java or C++, with a
>correspondingly smaller investment in language skills.
>

I do have one concern this touches on wrt tinygo. I do not know what googles 
stance is in regard to go on microchips but they seem to be supporting it 
financially. When raised before, it was stated that it had not been considered 
or discussed with the relevant parties. Java had the original aim of running 
everywhere, it failed on micros. Go could accomplish that aim

My concern (an uneducated concern) is that considering a micro running 
currently compatible parts of the stdlib with gc set to none and using global 
variables for reliable memory consumption. *Might* Generics adoption within the 
stdlib make more of it unusable (assuming generics poses a problem, it might 
not). I assume that it would not affect wasm.

This in itself is not a game stopper as I believe go is a useful language 
without gc or the stdlib. I do think that micros are important enough to be 
considered, however. Perhaps not important enough in the footprint of google 
services but maybe those that need Generics.

If I recall correctly. I may have raised it on the tinygo slack and the 
response was that nothing looked too problematic from what had been seen.

In any case, it might be worth the go team understanding what does and doesn't 
cause problems for tinygo?

-- 
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/58C57DC6-716D-4BD5-B32A-5492417A7302%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/13/21 5:27 PM, 'Axel Wagner' via golang-nuts wrote:

>  
> I'm once again not sure what your objective is here. No one is trying to argue
> that it is impossible to introduce semantics like you propose.
> We are only trying to give you the reasons why that's currently not done.
> 
> You can always file a proposal to change the semantics. But I would strongly
> suggest to a) get acquainted with the reasons given to you for why maps work 
> the
> way they do and b) have good answers ready when they come up in the 
> discussion.
> At least better answers than just dismissing them. If your only response to
> someone saying that performance would suffer to much if we had to allocate a 
> map
> for every zero value is "that is performance nonsense", my prediction is that
> your proposal would not get very accepted.

That was not my answer or "only response"!

>> If you are doing something a billion times then whatever you are doing is
>> more expensive than allocating a zero map. You can also avoid that return if
>> really necessary, which I doubt. It is right for optimisation steps to
>> increase, over run of the mill stuff.

e.g. append vs array

>> Nonsense around performance is the reason that c sucks.

perhaps I should have said, nonsense by default, but it is inferred from context


> Lack of "nonsense around performance" is also the reason why many people use
> Go instead of, say, Python.

Whilst you have wrongly called some things in this thread irrelevant.
That is irrelevant to this discussion as the reasons that Python is slower have
very little to do with this discussion. Whilst issues like this and ones already
fixed by go, do pertain to c.

I shall see if the staticcheck SA5000 linter can be improved to track returns or
submit a proposal at some point or wait for null safety to fix this issue.

-- 
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/3f7e04d7-b18d-6d05-8d7f-eaa04b79c368%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On Sat, 13 Mar 2021, 17:00 Jan Mercl, <0xj...@gmail.com> wrote:

> On Sat, Mar 13, 2021 at 5:52 PM Kevin Chadwick 
> wrote:
>
> > Very little resources, unless the map is actually used and not for long.
> If you really need to control gos memory use, you need to preallocate
> arrays in a long standing manner anyway, not for maps though, as you can't
> delete without realloc.
>
> How did you figure out "very little resources"?
>
> What if there's a hot loop called a billion times doing something and
> returning a non zero map in the very last call? We're then talking
> about probably measurable slowdowns and gigabytes of garbage the
> collector has to deal with. Allocating "preemptively" might be
> sometimes a good idea, but that's a decision better left to humans as
> the compiler usually does not have enough info to make that decision
> right.
>
> Ignoring for now other techniques that might get the cost of this
> down. They exist.
>

If you are doing something a billion times then whatever you are doing is
more expensive than allocating a zero map. You can also avoid that return
if really necessary, which I doubt. It is right for optimisation steps to
increase, over run of the mill stuff.

Nonsense around performance is the reason that c sucks.

>

-- 
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/CANNfpqcW2yRLefLzc9h1Dqk7Hr5ASwmrfoLD-QxhxwA7nwEzXw%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On Sat, 13 Mar 2021, 15:05 Jan Mercl, <0xj...@gmail.com> wrote:

> On Fri, Mar 12, 2021 at 1:24 AM Kevin Chadwick 
> wrote:
>
> > Why doesn't go auto init or make an empty map for a named return to
> avoid the potential chance of a panic due to operating on a nil return?
>
> A non-zero value map value must be allocated. All well-known Go
> compilers allocate maps in heap. Allocating automagically a map that
> may end up never used is a waste of resources.
>

Very little resources, unless the map is actually used and not for long. If
you really need to control gos memory use, you need to preallocate arrays
in a long standing manner anyway, not for maps though, as you can't delete
without realloc.

>

-- 
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/CANNfpqceqbKAAoSu2ukCiydsn5ZZaorEN7vt_%3D1-T-wh0NrrSA%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/13/21 1:40 PM, Axel Wagner wrote:
> 
> Compiler complication is not the concern. It would be easy to build any of the
> suggested semantics into the language. It is just that none of the suggestions
> so far seem clearly better - that is, they all come with their own downsides.
> 

OK, I really meant, GC complexity, etc. Perhaps it does not affect that either.

> The concern about the zero value consisting of 0 bytes is more about
> performance. As long as that's the case, initialization is very close to free.
> As soon as the zero value becomes some non-zero bytes, they have to be written
> and that incurs a cost. 
> 
> When we say "the zero value of a map should only contain zero bytes", what we
> mean is that if I write
> var m map[int]int
> that should a) reserve some memory for m (currently that's as many bytes as a
> pointer needs) and b) those bytes should be zero after that.
> If "make was called implicitly" or anything like that, those bytes wouldn't be
> zero anymore - they would contain a pointer to an allocated map header.
> 
> It's as simple as that. You might feel that preserving that property is not
> important or less important than having a useful zero value for maps. That's
> fine. But that's the property Ian is talking about.


In that case, as far as I understand it, which may be a limited understanding. I
disagree with this being a useful property. Replacing a map of 0 length with one
that is larger is not a problem. Checking the length of a map also makes more
sense to me than nil.

Though I personally do not agree with Nulls in JSON either. An intentional empty
is always more useful. Similarly, nulls when permitted always being
unintentional is more useful in my eyes.

-- 
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/b962ffa5-0201-bffb-90c0-8f6de262d9a7%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

> 
> I don't think we should change creation; what about having the first 
> insert
> make the map if it's nil?
> 
> It seems that would be fairly transparent.
> 

This wouldn't solve the problem that I saw. Whilst, an easy personal fix is to
make sure coders always make a map whenever used. I figured a user might quite
easily think that := on a returned map would always be safe, like with a string.
Making an empty map just to return it and later making a map of a set size,
seems odd. I also do not see why you would ever initialise a nil map.

After looking into the named return discussion, including Dave Cheney's blog. I
also considered that :=, seemed to be the real problem in the end and IMO, the
feature with least to offer.

> 
> My original thinking was that either the function call or
> initialisation could run make under the covers. 
> 
> From Ian in those threads copied above "While not requiring the 
> make
> call".
> 
> Why not require make by calling it, behind the scenes?
> 
> 
> But that is exactly the loss of "the zero value is all 0 bytes" we are
> talking about. 
AFAICT, it looks like I misread Ian's response as if make could always be used
then it would solve the problem rather than being a cause of a compiler
complication.

-- 
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/87d37b24-14ba-1d9c-35eb-eef9832a10bc%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

>This sounds like if you are suggesting to make the zero value of a map
>an
>empty map, which is different from initializing a map variable to an
>empty
>map if it a named return. That suggestion has come up a lot, both on
>this
>list and on the github issue tracker. It's, unfortunately, not as easy
>as
>it sounds. Here is some prior discussion:
>https://groups.google.com/g/golang-nuts/c/SjuhSYDITm4/m/Z013vH5qDQAJ
>https://groups.google.com/g/golang-nuts/c/5_8E9OblIho/m/b9O038mzBQAJ
>

>> And another reason is that it's very convenient for the zero value >> for 
>> all types to be literally a sequence of zero bytes. We could
>> never figure out how to preserve that property while not requiring >> the 
>> make call for map values. In the very early days what we call >> maps now 
>> were written as pointers, so you wrote *map[int]int.
>> We moved away from that when we realized that no one ever 
>> wrote `map` without writing `*map`. That simplified many things >> but it 
>> left this issue behind as a complication.

>> The most plausible fix that I know for this is to invent a map
>> function that is similar to the append function, but I haven't yet
>> seen a good design for that. 

I do not need to understand the difficulties that exist, though I struggle to 
understand the zero bytes property as surely even an empty string has a 4 or 8 
byte pointer. Perhaps it is the memory pointed to. Maybe useful for compaction 
etc..

My original thinking was that either the function call or initialisation could 
run make under the covers. From Ian in those threads copied above "While not 
requiring the make call". 

Why not require make by calling it, behind the scenes?

-- 
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/AAB589F5-DA04-4468-A745-77F9177EAF76%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/12/21 12:33 PM, Axel Wagner wrote:
> This sounds like if you are suggesting to make the zero value of a map an 
> empty
> map, which is different from initializing a map variable to an empty map if 
> it a
> named return. That suggestion has come up a lot, both on this list and on the
> github issue tracker. It's, unfortunately, not as easy as it sounds. Here is
> some prior discussion:
> https://groups.google.com/g/golang-nuts/c/SjuhSYDITm4/m/Z013vH5qDQAJ
> 
> https://groups.google.com/g/golang-nuts/c/5_8E9OblIho/m/b9O038mzBQAJ
> 
> 

Thank You. Sorry, I should have searched.

> Are there any better tools than golang-shadow and golang-nilness, for 
> these
> problems?
> 
> 
> I don't know. I don't even know either of those.  

They are in x/tools. I only found them today.

-- 
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/c85bccf2-72a8-1e13-64ee-3475b77b9e21%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/12/21 11:51 AM, Kevin Chadwick wrote:
> Incidentally, I would be happy with err != "".

Of course I do appreciate the wrapping/error testing. Though I use little/no
more than could be accomplished with typed strings.Contains, personally.

-- 
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/a3721584-e18b-34cf-6371-86ce75042e31%40gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/12/21 7:16 AM, Axel Wagner wrote:
> I find named returns produce more readable code but I avoid them when
> returning a map.
> 
> 
> Personally, I would recommend avoiding naked returns in all cases. In the best
> case, a naked return is less explicit and requires readers to think about what
> is returned. In the worst case, a naked return can introduce subtle shadowing
> bugs (this has happened in production code, multiple times).
> 
> I don't think the convenience justifies the cost.

Shadowing is an issue that needs to be dealt with, in any case. Think about =
less readable.

> 
> Why doesn't go auto init or make an empty map for a named return to avoid
> the potential chance of a panic due to operating on a nil return?
> 
> 
> It auto-initializes every variable to its zero value. It would be very strange
> to make an exception for maps. And named returns aren't really different from
> regular variables in this regard.
> 
> I also don't think there are many cases where you'd *want* to implicitly 
> return
> an empty, non-nil map. A nil map says "there is no map", whereas an empty map
> says "there is a map, but it has no elements". It seems very appropriate that 
> if
> you want to say the latter, you have to explicitly do so.

I would argue that a string could be nil but isn't and that being 0 len is a
good thing. Ergo, it is strange for a map to be doing premature optimisation,
when you could test it for 0 size. More likely, it is an artifact of make coming
to the language later on and perhaps is tied by the go promise, unfortunately?
It might have also been a not tiny amount of work for a relatively small 
benefit.

We are encouraged to use make to initialise maps. I also replace err.Error()
with a function that returns "". Incidentally, I would be happy with err != "".
err.Error() has also lead to bugs in stdlib. So maybe I just have a different
point of view? Maybe null safety will come, eventually as it was quite high on
the survey and likely increasing as more languages provide this feature and
users acknowledge it.

Are there any better tools than golang-shadow and golang-nilness, for these
problems?

-- 
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/d89835e2-4db3-e34e-416c-a7db6d472a79%40gmail.com.

[go-nuts] Auto Make a named return map

[Kevin Chadwick]

I find named returns produce more readable code but I avoid them when
returning a map.

Why doesn't go auto init or make an empty map for a named return to avoid
the potential chance of a panic due to operating on a nil return?

-- 
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/CANNfpqe5VmDfd53YMHDecOEt-XNH3efCVGAa1Z3q6qJJbDQYsw%40mail.gmail.com.

Re: [go-nuts] Re: Modules and gopls (in VSCode)

[Kevin Chadwick]

On 3/8/21 12:04 AM, 'Peter Bourgon' via golang-nuts wrote:
> I don't have enough context about your development environment to say 
> you're using modules ·incorrectly·, but I'm fairly certain you're making 
> life significantly harder for yourself by trying to work with 137 (!) of 
> them at once. It is totally unsurprising that gopls is having trouble with 
> that, as, normally, you work with just one module at a time. That's because 
> you don't "modularize" your packages individually — modules are typically 
> one-to-one with code repositories, and contain many packages.

The docs such as "how to write code", and it's sub links, need to be
restructured to make this an easier and clearer read.

-- 
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/b91fab0d-6402-c035-78f8-fcf5bfdfb4f8%40gmail.com.

Re: [go-nuts] Differences between go1.16 and go1.15 ?

[Kevin Chadwick]

On 2/25/21 8:31 AM, Brian Candler wrote:
> I suggest that newcomers are told to create an empty directory, create main.go
> in that directory, and then use "go run ." (a literal dot), "go build .", "go
> fmt ." etc.  Of course, this means that if you have several programs you need 
> to
> create separate directories for them - but that's the right thing to do.  
> Plus,
> these days, you're soon going to need "go mod init myprog" anyway, which will
> create a go.mod alongside it.

I have found that using replace was problematic wrt vscode gopls and possibly
build messages. Apparently that should be improved however I believe users are
using replace that likely do not actually want or need to. There seems to be
more interest in improving that situation than the documentation bugs,
especially the onboarding documentation. The onboarding documentation, in my
mind, is far more important.

The wiki seems to point back to the start coding in go documentation too.

I have switched from replace (though I still have one in use currently) to
having each project in a folder with a single go.mod at it's root.

Within that folder you can have multiple packages without any other .mod files
and you do not need to worry about module versioning. All the files in each
folder will be treated as a separate build. You can just cd into each folder,
run go build and as long as the package is main then all .go files under that
directory will be built into one binary.

If you have another folder in the root directory next to the go.mod and within
that, the .go files are package lib. Then you can simply import it into all your
'main' packages using:

'import lib "example.com/modulename/libfoldername"'

In fact in vscode with gopls, typing lib.functionname will automatically import
it for you.

This way you can use any version control that you want to import files into any
project (folder/package within the module) and not worry about the go specific
tools except perhaps for publishing. Even then, you may not need to, as your end
result may be something else, such as an installer.

-- 
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/cff3dcbe-6f7a-adc7-ccac-b514ed2eec66%40gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 11:37:05 PM UTC, robert engels  
wrote:
>A simple slice OOB causes a panic - this is why many robust servers
>will catch & recover so a single OOB due to bug triggered by rare
>input/state doesn’t crash the server for 1000’s of users. It might
>still cause problems due to resource exhaustion, but properly designed
>exception/error handling should prevent/limit that.

I would rather fail safe than cater for a situation that shouldn't happen. 
Recovery is a less sane environment and there are better ways to build in 
redundancy.

Wrt forking. I was talking about dropping privileges, once at daemon startup.

-- 
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/D74D9146-B712-4EFF-A291-3A4D7ACA051B%40gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 11:16:46 PM UTC, robert engels  
wrote:
>I’m sorry but that is not correct. If you have a “server process” that
>handles requests for 1000’s of clients - terminating the process due to
>an exception/panic easily leads to a DoS attack. The bad actor only
>needs to send similar requests infrequently to affect thousands of
>users - especially with round-robin servicing - you can take down
>1000’s of servers with 1:1 requests.
>

I figured after that I should have more politely said that. I am not sure what 
scenario you are thinking of but it doesn't apply to what I am doing.

Panics should not be triggerable by external influences, in any case.

-- 
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/CDB3583B-6171-4025-B635-CC680FDDDF0D%40gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 8:00:36 PM UTC, Robert Engels  
wrote:
>Depending on other infrastructure that can easily lead to easy DoS
>attacks. 

Utter nonsense, more likely the opposite, if any difference at all.

-- 
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/82940662-0589-4C68-AE4A-72AB0DBC36D3%40gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On 2/24/21 9:53 AM, roger peppe wrote:
> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick  <mailto:m8il1i...@gmail.com>> wrote:
> 
> I only instigate panic manually for one thing. Perhaps that will change, 
> but
> I doubt it.
> 
> If I want to send out or write a log to disk then I will call panic rather
> than os.exit, upon a log.fatal scenario. Think buffered go routine 
> logging.
> Saving the coder from having to think about it, once initialised.
> 
> Which produces some ugly output and likely extra processing.
> 
> Is it possible to call panic in a way that does not kill the process like
> os.Exit, but without log pollution?
> 
> I am solely thinking of manually instigated panics, so a noop panic called
> something like terminate?
> 
> Or is this bad practice, even when a program is in good operational order
> when instigated, as the OS is better at cleanup?
> 
> 
> Personally, I'd advise against using panic or log.Fatal in this kind of 
> context
> - I'd just bite the bullet and return errors instead.
> This makes it easy to move code between contexts if you need to without 
> worrying
> about non-local control flow.
> 

Yes, I avoid log.Fatal, wherever possible.

However, if I am for example running a drop privileges function and it fails
then I want an immediate exit. To avoid any potential of fragility.

Actually it seems that the panic never gets logged anyway and as the master
process is unlikely to fatal then a panic is unlikely to ever be seen. Perhaps
not ideal, but it works.

> For unexpected panics, you can still use recover to flush your log buffers,
> assuming the panic happens in code that's been called by your code.

I think I would rather os.Exit ASAP, in the case of an unexpected panic.

-- 
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/84a0db02-c4ec-15cf-cdd9-8543c1f9aa61%40gmail.com.

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

[Kevin Chadwick]

On February 23, 2021 2:46:20 PM UTC, Robert Engels  
wrote:
>I am not 100% certain but the build statement at the top of the Unix
>dns client specified Darwin. I would read the Go issues I linked to in
>the code snippet. 

I believe it varies. Android has no universal textual interface - 
/etc/resolv.conf, for example.

-- 
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/218CEFB4-B03F-4284-B62B-AFB2B1C2032A%40gmail.com.

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

[Kevin Chadwick]

On February 23, 2021 1:57:07 PM UTC, Peng Yu  wrote:
>This does not answer the question why net.Dial can not be made with
>the same behavior as ping on MacOSX. If the C library behaves
>differently on MacOSX and Linux, then the C library should not be
>relied on in this case. I just want to use /etc/hosts but not
>resolve.conf.
>

There is a setting to use gos DNS, I believe. You could always parse /etc/hosts 
and make a connection. If it's slow it us likely a timeout/mis configuration.

Generally you want to use whatever dns elaborations that the system provides or 
user has chosen, like mdns, doh, dotls, dnssec, unbound, unwind...

-- 
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/353AC292-2AAD-45C8-BCEC-0E7FDBD68B9B%40gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

> So you should probably disregard the sentinel-panic idea,  
> runtime.Goexit seems strictly superior) 

Thank you. I shall look into those. 

WRT Goexit. I was hoping a defer in main would run also. Thinking about it. I 
shall have to ponder about the relationship of panic and process groups too and 
whether a dedicated service like syslog is better. I may as well use syslog in 
that case but I had cross platform logging code that I figured, may be more 
flexible.

-- 
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/7E3A6D6D-1BAE-4F8E-8259-61B59D5C8731%40gmail.com.

[go-nuts] Orderly exit

[Kevin Chadwick]

I only instigate panic manually for one thing. Perhaps that will change, but I 
doubt it.

If I want to send out or write a log to disk then I will call panic rather than 
os.exit, upon a log.fatal scenario. Think buffered go routine logging. Saving 
the coder from having to think about it, once initialised.

Which produces some ugly output and likely extra processing.

Is it possible to call panic in a way that does not kill the process like 
os.Exit, but without log pollution?

I am solely thinking of manually instigated panics, so a noop panic called 
something like terminate?

Or is this bad practice, even when a program is in good operational order when 
instigated, as the OS is better at cleanup?

-- 
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/3A8FA632-4991-4245-ABB3-8F4CE1164703%40gmail.com.

Re: [go-nuts] Error handling

[Kevin Chadwick]

 
>don’t think ‘single shot, short lived processes’ are the typical Go
>paradigm - they are usually larger , multi layer, long lived “server”
>processes. It’s my opinion that Gos error handling is a problem for
>these types. I am not saying it can’t be done but it’s harder to
>design/deliver/maintain.
>

I can't agree. Long lived go server processes are made of many single shot 
worker tasks that can send errors back just the same.

>Exceptions (used properly) provide a lot of information when reading
>the code.  I don’t get the same feedback with Gos error returns. 

AFAICT, this is just structuring. There is nothing stopping your server 
processes from having a documented error processor, handling returned error 
types, possibly even from distributed services.

The only real difference is if the errors are tunnelled in plain sight or 
behind the scenes. You could store rather than returning errors if you wanted 
to. I don't think Go users should be encouraged to hide errors away.

-- 
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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com.

Re: [go-nuts] Error handling

[Kevin Chadwick]

On 2/18/21 4:01 AM, robert engels wrote:
> But - the issue is that most of the time - for complex systems - the errors
> cannot be handled where they are encountered - even in Go, most of the error
> handling becomes boilerplate returning the error detected and expecting some
> higher level to handle it.

Occasionally I think what could I add here at the points that you call
boilerplate. However, I almost always add context at every level. The benefit is
that I hardly ever have to pull out a debugger or even read the code aside from
the failure point or stdlib code. The debugger is useful for more subtle issues,
but a big, time waste, most of the time.

You can also create test errors easily by wrapping with the recent changes.
Wrapped errors act, in a way like exceptions. In fact, I log the latest
test/wrapped error and any previous one in the chain. So that I may see any one
provided by the stdlib as well as my own.

What you are proposing doesn't match up with Gos ease of picking up and running
with the language with good outcomes because exceptions are less likely to be
handled than errors by most devs and also in most situations. It also doesn't
marry up with the policy of trying to keep one way of doing things, for similar
reasons. Isn't there a package, that you could use?

-- 
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/a4f5ba51-c704-9616-a8b9-c6a0bbad1bab%40gmail.com.

Re: [go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?

[Kevin Chadwick]

> In future, work in two instances of VS Code

I set GOOS env variable and HISTFILE env variable on each code execution. So a 
particular folder is tied to that OS and the terminal history is separate.

IOW, i make a code app icon for each current project. One also for go stdlib 
src searches.

-- 
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/B31821FA-8443-4102-A235-7440C49CB27E%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

I am surprised this did not come up in the thread. I'm not sure if I never knew 
this was possible or I have forgotten during my time using replace. Turns out, 
that you can import a folder within the same module folder as mod 
identifier/package and it is automatically imported by gopls when you reference 
that package, which never worked with replace.

This allows existing version control tools to be used across languages too. 
Just pull the folder into the root module and away you go.

Being able to reference external folders such as with replace is nice but 
causes issues with gopls and mod updates and possibly erroneous build messages.

I believe there are some documentation bugs. The following does not mention 
this or link to "how to write go code".

https://golang.org/doc/tutorial/getting-started

The following alludes to this functionality, but could make this possibility, a 
lot clearer.

https://golang.org/doc/code.html

-- 
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/FCC0571D-11B7-4426-BA75-E9A512EFA46B%40gmail.com.

Re: [go-nuts] Possible Go 2 proposal for built-in Remove method for Slices.

[Kevin Chadwick]

>> >
>> > A "remove element from _slice_" operation always must make a new
>array
>> > and copy all elements that you intend to stay. Current idiom using
>append
>> > will do this for you while being frank about costs.
>>
>> Maybe I misunderstand what you wrote, but as long as the slice has
>> enough capacity the array will be reused and not not copied:
>>
>> https://play.golang.org/p/sevpWixzw6V
>>
>

Incidentally I've been wondering how this works for slices of strings and 
haven't found much on golang.org or via google yet. Are allocations still 
avoided for arbitrary sized strings?

-- 
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/93FD0FB0-7667-4109-98B0-6926280F92BB%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 2/3/21 5:14 PM, Kevin Chadwick wrote:
> Why would I trust DNS
> Why would I setup letsencrypt
> What if we have a minimal internet use developer machine policy

https://roberto.selbach.ca/go-proxies



Oh, this will be annoying.

https://golang.org/ref/mod#module-proxy

A module proxy must always serve the same content for successful responses for
$base/$module/$version.mod and $base/$module/$version.zip queries. This content
is cryptographically authenticated using go.sum files and, by default, the
checksum database.



Aha, this may be the key

The go command may download module source code and metadata directly from a
version control repository. Downloading a module from a proxy is usually faster,
but connecting directly to a repository is necessary if a proxy is not available
or if a module's repository is not accessible to a proxy (frequently true for
private repositories). Git, Subversion, Mercurial, Bazaar, and Fossil are
supported. A version control tool must be installed in a directory in PATH in
order for the go command to use it.

To download specific modules from source repositories instead of a proxy, set
the GOPRIVATE or GONOPROXY environment variables. To configure the go command to
download all modules directly from source repositories, set GOPROXY to direct.
See Environment variables for more information.

-- 
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/d336c1db-59cb-6288-5b9e-ba99e33cf469%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 2/3/21 2:46 PM, David Riley wrote:
> I understand the need for the domain as part of the module namespacing, but 
> it does make a certain assumption that all of these things are going to be on 
> resolvable domains, which isn't true for everyone.

I have a resolvable domain and run a mail server with a lets encrypt certificate
but there are other issues.

Why would I trust DNS
Why would I setup letsencrypt
What if we have a minimal internet use developer machine policy

Replace isn't used by the masses and works ok but it isn't as well tested as
demonstrated by various gopls and other bugs. How do we know the issue we are
having with gopls is caused by being in a minority with replace or build tags.
Actually a giant package main is likely better tested.

It was said that replace probably should not be used in a daily workflow, yet
there are numerous issues stating to do so. It's possible that the main mistake
was in giving the stdlib special treatment! If Go needed to do something, likely
others will too.

I am currently looking into this proxy as Athens that uses Docker is likely not
cross platform because Docker is not cross platform. The docs like this thread
seem to assume people will use github!

"https://github.com/goproxy/goproxy;

-- 
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/b1e4a14a-7839-b276-4beb-976408a2d679%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

> 
>> Note, that this is essentially one of the workflows suggested here (which I
>> would consider the canonical documentation for the "eng org wants to onboard
>> Go" case):
>> https://golang.org/ref/mod#private-modules
> 
> I have realised a goproxy may be needed rather than a http server as I expect 
> a
> domain with https, will be required for security despite being LOCALLY secure.
> 

>> Jim, I used replace this way just yesterday. It works fine, but is not easily
>> discoverable as a process and it took me a minute or two to figure it out.

It works well mostly but seems buggy at times. Saying functions aren't defined
with illogical fixes like connecting the internet and "updating transitive
dependencies. I'm starting to reluctantly come to the conclusion that I will
simply have to spend the time setting up a GoProxy, to be in a more tested 
place.

Having to occasionally delete empty lines and put them back seemingly randomly
after a build tag is enough to deal with already.

Maybe I should dos2unix all my files or something?

-- 
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/ce6d8693-c722-165d-6eee-5ac2e559a6a6%40gmail.com.

[go-nuts] Options other than pointers, regarding code duplication

[Kevin Chadwick]

I have three logging functions that are almost identical.

If I move the identicle code into a function without pointers then there is a
noticeable speed decrease. I know this is premature optimisation as logging
shouldn't happen frequently enough or be that large (hopefully).

That said. I am left wondering aside from code generation steps and copy and
paste (current solution) if I am unaware of any options that might avoid pointer
use, such as:

1./ scoped global, like a Class might provide

2./ macro type instantiation that simply inserts the code at compile time but
without the compiler doing any computations

I assume not, from perusing the spec?

p.s. It's fine if the solution is pointers. Just wondering if I can avoid panic
potential.

-- 
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/e7cfd4a6-8264-229e-ad96-a935aaa1be3a%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

> Note, that this is essentially one of the workflows suggested here (which I
> would consider the canonical documentation for the "eng org wants to onboard
> Go" case):
> https://golang.org/ref/mod#private-modules

I have realised a goproxy may be needed rather than a http server as I expect a
domain with https, will be required for security despite being LOCALLY secure.

(reminds me of web filesystem apis and PWAs)

Can you run a GO proxy on http without TLS, such as tunnelled through SSH?

> though, FTR, that internal module hosting solution can be as simple as an NFS
share.

How would something like this work. Do I mount an sftp folder into my projects
'main' despite the library being project 'library'. Would I rename the 'library'
package as 'main' also and use it like an 'extension' to packages with main()?

Thanks, Kc

-- 
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/0567ec9c-92f7-d611-b687-aed141958480%40gmail.com.

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

[Kevin Chadwick]

>
>> I think the general rule of thumb I find agreeable is "the length of
>an
>> identifier should be inversely correlated to the distance between its
>> declaration and its use".
>>
>

Loosely correlated, perhaps.

I'll be honest. I have always found this advice to be rarely useful. It 
certainly removes one of the hardest parts of programming from tiny functions 
and encourages their use but their use should be a consideration, in any case.

I still don't see why generic functions can't be as close as possible to 
standard functions.


-- 
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/96B745EC-FAD4-4F88-A4FD-FC8633289579%40gmail.com.

Re: [go-nuts] Golang security and reliability

[Kevin Chadwick]

On 1/20/21 1:46 PM, Axel Wagner wrote:
>  My personal projection is that security will mostly be unaffected (/I don't
> know of many security issues in the past that were related to Go type safety 
> or
> lack thereof/), if it *is* affected, the effect will be positive and that
> type-safety will increase.

I apologise then. I guess I read many as any.

-- 
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/5a05a7e4-0659-7e6d-0c7a-7491d852f165%40gmail.com.

Should Generics also be as usable as empty interfaces; Was: [go-nuts] Golang security and reliability

[Kevin Chadwick]

>> I don't understand what you are trying to say or achieve. But, to be clear:
>> 1. Yes, Go does intentionally not attempt to build a type-system which >>
excludes as many bugs as possible statically.
>> 2. Yes, there is a possibility that Go software has security bugs that could
(or would) have been caught by a more powerful type-system.

I just wanted to make a simple point and not pollute this with any agenda as I
am not going to hunt for a bug that matches any other concerns of mine or spend
any more time. I care about Go but not to the detriment of other tasks.

I will ask one thing and then I am going dark. If generics do help users avoid
type erosion then perhaps Generics should be more usable than the current plan
and smaller in scope? I don't normally like multiple ways in languages but
perhaps there should be both an easier and a more powerful Generics syntax?

This is relateable from another thread:)

>>> But, hopefully, in the-glorious-future™, this won't be needed anymore. And
>>> maybe we can get back to view interfaces as their own type

-- 
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/f2efecd6-318b-9fe8-c3f7-748a01ceebc7%40gmail.com.

[go-nuts] Golang security and reliability

[Kevin Chadwick]

I know Go is far from plagued by these issues and I certainly wouldn't want to
trade Gos simplicity away. However, there seems to be a playing down of null
pointers and type safety issue potential.

Is this not a type safety issue?

"https://www.cvedetails.com/cve/CVE-2019-14809/;

and obviously null dereferences that can cause critical service failures to need
investigating urgently.

"https://access.redhat.com/security/cve/cve-2020-29652;

-- 
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/ddf94844-7cf3-2366-691f-7b915e6dce1f%40gmail.com.

Re: [go-nuts] Re: Interface arguments to generic functions

[Kevin Chadwick]

On 1/20/21 10:42 AM, 'Axel Wagner' via golang-nuts wrote:
> IMO it is confusing to allow comparing generic values to nil, in general. If 
> we
> could, I would either assume I can compare any *non*-generic value to nil. I
> would assume we can always go from a generic function to an instantiated one 
> by
> substituting all occurrences of the type-parameters. But IMO, nil is already
> confusing enough as it is.
> 
> I think the solutions Patrick and Ian provided for checking if an interface is
> nil, or a value is zero, are enough. Because, to be clear: Calling a method on
> an interface can panic *whether or not that interface is nil*.

It looks to me like interfaces are causing a lot of problems in this proposal.
Although nil is largely a non issue in go compared to Dart where they are
pushing for migration to null soundness. I would personally like to see nil use
and related panics minimised further, if anything.

-- 
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/f2eb905c-90ce-653c-1d33-af352f05c782%40gmail.com.

Re: [go-nuts] Generics syntax suggestion

[Kevin Chadwick]

>>string
>>or []byte) ? "
>>
> 
>You could always use a well placed &. That isn't the point. 

Or perhaps group with {} like Darts optional parameters. Again though, not the 
point.

-- 
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/FE5449DD-8060-4845-9FFB-228D9AAB5FF3%40gmail.com.

Re: [go-nuts] Generics syntax suggestion

[Kevin Chadwick]

On January 19, 2021 9:13:55 PM UTC, Levieux Michel  wrote:
>I think the question was: "given your proposal here, I can write func
>(string | []byte in1, string | []byte in2) which enforces that in1 and
>in2
>must be either of type string or type []byte, but how do I tell the
>compiler that in1 and in2 must be of the *same type* (whether it is
>string
>or []byte) ? "
>
 
You could always use a well placed &. That isn't the point. 

-- 
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/BDDBF610-2D1C-4F8A-880B-AAB2ED321004%40gmail.com.

Re: [go-nuts] Generics syntax suggestion

[Kevin Chadwick]

On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts 
 wrote:
>On Tue, 2021-01-19 at 20:01 +0000, Kevin Chadwick wrote:
>> I was inquiring about the possibility of no identifiers or
>> abstraction but simply like Gos non generic functions (possibly
>> reversed if needed). Using type OR type.
>> 
>> func (String | []byte firstInput, myType | publicKey
>> secondInput)   {
>> 
>>   firstInput[0]
>>   firstInput[[]byte]
>> }
>
>
>How does this encode the desire that parameter types match?

These are the parameters. dynamic var firstInput must be a String or byte slice.

-- 
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/F183269A-E743-4069-90C3-0357F5C6D36D%40gmail.com.

[go-nuts] Generics syntax suggestion

[Kevin Chadwick]

>> Seems to me that most generics implementations use a capital letter 
>> abstracted type syntax that I hate.
>>
>
>This is just a convention and not part of the syntax, which means it's 
>irrelevant to the discussion about the proposal. You can easily use 
>lowercase letters/identifiers:
>https://go2goplay.golang.org/p/eWgJSLNTZw8

I was inquiring about the possibility of no identifiers or abstraction but 
simply like Gos non generic functions (possibly reversed if needed). Using type 
OR type.

func (String | []byte firstInput, myType | publicKey secondInput)   {

  firstInput[0]
  firstInput[[]byte]
}

-- 
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/17BEE437-A5BB-4152-8215-B3F27A7265C1%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

>Apologies then. I assumed you where trying to amend OPs suggestion,
>which
>was specifically to abscond with type parameters and the ability to
>express
>constraints.
>Note the topic of this thread: »instead of generics, why cant we just
>implement an "any" builtin?«

Oops, Sorry for hijacking the thread without changing the title. I do that too 
often when being whimsically inquisitive.

-- 
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/67D43CEB-2576-4A9E-939D-DDE2B3CC07D2%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 4:53 PM, Axel Wagner wrote:
> 
> Yes. And there are definitely syntactical choices that can be decoupled - like
> how we went from `(type T)` to `[T any]`. Not having type parameters or ways 
> to
> constrain them, though, is more than just a syntactical choice. It removes the
> actual core of the design. Of the ten bullet points in the high-level design
> description

I believe my suggestion included constraints in the function parameter list
whilst avoiding the needless abstraction?

-- 
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/56a0130c-64d5-c4a8-ddda-9d22abd99565%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 3:32 PM, Axel Wagner wrote:

> "I think this design sucks, you should throw it away and start from scratch"
I assume you believe that is what I affectively said but I am not sure if I were
in a position of understanding all of the requirements and details, that I would
agree? I gave a preferred syntax example with a caveat of lacking understanding
of the implications. There is obviously a lot more than syntax to the proposal.
Perhaps the requirements and syntax should be separate proposals. Though Ians
remarks make it sound like most if not all of the requirements may have been
finalised a while ago?

I am certainly not sold on the idea that an "idiomatic" interface like approach
is going to be less rather than more confusing (removing upvote).

-- 
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/c73f30e4-558a-b7e4-5706-d879936e68d0%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 1:41 PM, Axel Wagner wrote:
> 
> OK, but using a T all over the place, sucks.
> 
> 
> That is a fair opinion to hold. But if you don't like the current design and
> want an alternative (or nothing at all) to happen, the strategy of just saying
> "it sucks" just isn't going to be very effective towards that goal. Because
> you'll need to actually get specific people on board for that and they are
> unlikely to get swayed by simplistic rhetoric like that.

Sure, but the Go team needs to be realistic and realise that not everyone is on
the salary that they are or can afford the time that they can, or even on a
consistent salary at all (e.g. founder with two jobs). Casual observations are
not worthless and you don't need to have the answers to know something may seem
sub optimal!

I expected a discussed already response.

>> And, of course, you can change the suggested syntax again. But every time you
>> do a change like that, you are flushing the entire previous discussion down
>> the drain, because we now have to re-consider all aspects of the design, from
>> tokenization, over parsing to type-checking and implementation etc.

After ten years of waiting for the "right" generics. This isn't the time to
disregard the option of fundamental changes. On the contrary, being so close to
it, might be blinding (Ian does seem to be open minded however). Seems to me
that most generics implementations use a capital letter abstracted type syntax
that I hate. This is thankfully conservative but isn't exactly thinking outside
the box for an implementation, that is just right. It may be that there are
unavoidable reasons for that abstraction but it looks like needless abstraction,
on the face of it.

p.s. I had already upvoted the proposal actually, as it is certainly well
considered and well constrained.

-- 
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/1c1ab297-7165-3cc7-e964-20dc74b3eec6%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 12:21 PM, Axel Wagner wrote:
> And, of course, you can change the suggested syntax again. But every time you 
> do
> a change like that, you are flushing the entire previous discussion down the
> drain, because we now have to re-consider all aspects of the design, from
> tokenization, over parsing to type-checking and implementation etc.

OK, but using a T all over the place, sucks.

-- 
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/f6e17dd3-91d5-39eb-7aa2-42f8058f13af%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote:
> This is essentially the previous generics design
> ,
> where you implicitly use the function body as a contract - with the exception,
> that you have no way to express that two arguments should be *different*

firstInput[0]
firstInput[[]byte]

-- 
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/91fee76b-922c-fd1c-f177-65c9251c6992%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 11:19 AM, Artur Vianna wrote:
> Similar how you can't compare two slices and it fails to compile, because 
> slices
> aren't comparable. Internally the compiler would need the information on every
> possible operation on every type, but i guess this partly exists already, as
> part of the static checking.

I'm not tuned into the requirements of the Generics proposal, however.

I would like the syntax of.

func (String|[]byte input, myType|publicKey secondInput){
}

-- 
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/54f1c29a-3328-623a-a83b-9e312b658b27%40gmail.com.

Re: [go-nuts] Advice, please

[Kevin Chadwick]

On 1/17/21 4:46 PM, Bakul Shah wrote:
> I’d be tempted to just use C for this. That is, generate C code from a 
> register
> level description of your N simulation cores and run that. That is more or 
> less
> what “cycle based” verilog simulators (used to) do. The code gen can also 
> split
> it M ways to run on M physical cores. You can also generate optimal
> synchronization code.
> 
> With linked lists you’re wasting half of the memory bandwidth and potentially
> the cache. Your # of elements are not going to change so a linked list doesn’t
> buy you anything. An array is ideal from a performance PoV.

Potentially forgive me and ignore this message if inappropriate as I haven't
been paying close attention to this thread at all really.

However, it strikes me that arrays are perfectly usable in GO. Similarly to how
you might use a global array with tinygo to ensure memory usage limits are not
breached. What is the issue of using an array in Go? Even a global one, *IF*
suited to the task at hand and dishing the work out to workers with a scheme a
little more complex than odd, even etc. as required?

With the benefit that an off by one etc. causes a panic and not something
potentially worse?

-- 
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/9768615d-180e-42fb-9677-da21b5105c37%40gmail.com.

Re: [go-nuts] Generics security discussion.

[Kevin Chadwick]

On 1/13/21 2:09 PM, Axel Wagner wrote:
> Let me repeat my question: Do you have any concrete reason to assume there is 
> a
> negative security impact of generics? Feel free to bring that up. Otherwise, I
> don't see a reason to talk about it in the design doc.

I don't and I don't mean to make demands of other peoples time. Though I'm sure
security has been carefully considered and might be fresh in peoples minds. It
might be worth formalising it, in any case. I am sure some members of the rust
community will do so likely inaccurately, if/when Generics are released.

Despite seeing horrible to read code, again on Reddit today. The blog asked for
us to consider voting. I'm inclined to upvote if the security of Go code is
expected to increase, otherwise I would likely down vote for readability 
concerns.

-- 
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/bd5281c2-f231-f84c-cf42-f84372b30bb7%40gmail.com.

Re: [go-nuts] Generics security discussion.

[Kevin Chadwick]

On 1/13/21 2:06 PM, Robert Engels wrote:
> A panic is not a security issue. Memory corruption/stack overflow is. In Go 
> the latter is accomplished through CGo and unsafe pointers/operations. 
> 

It isn't as clear cut as that. Panics can be security issues and memory
corruption/stack overflows can also result in DOS and not necessarily be
exploitable.

Granted panics should be handled and are largely akin to logic errors, except
when the compiler would have prevented that failure before release. Logic errors
are the biggest cause of security issues in Go

Personally. I would restart a panicked process or process group, without
exception and treat it more severely, if it happens.

-- 
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/f48d42d3-f3cc-a78a-6168-91522636a0d3%40gmail.com.

Re: [go-nuts] Generics security discussion.

[Kevin Chadwick]

On 1/13/21 11:17 AM, Axel Wagner wrote:
> Assuming generics like interfaces, potentially erode type safety.
> 
> 
> Can you elaborate? Because that statement seems exactly contrary to 
> established
> wisdom.

Clearly Go without interfaces, especially an empty interface is safer. Perhaps
Generics reduce that risk via constraints etc.?

> How many security issues and/or production panics to date might have been
> avoided by avoiding interface use all together?
>
>
> I assume panics in production are sufficiently common

Really. If you avoid interfaces and pointers. Is it even possible to
panic...maybe with channels. I don't use exceptions personally. Perhaps that is
what you mean?

I'm not trolling or anything. I just feel that a risk analysis section by those
that understand all the details, might be useful to people, before deciding on a
thumbs up or down?

-- 
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/5274cf02-a9a7-357d-e498-b979c1b02f15%40gmail.com.

[go-nuts] Generics security discussion.

[Kevin Chadwick]

I appreciate that generics use will be optional. However I am concerned  that 
neither in the design draft nor the proposal issue, that the word security nor 
safety has been used even once.

Assuming generics like interfaces, potentially erode type safety.

Will generics increase the likelihood of security issues, aside from panics?

Will it make package choice more important as a result?


Now for the one where I may need to duck afterwards.

How many security issues and/or production panics to date might have been 
avoided by avoiding interface use all together?

-- 
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/DEFAB41C-6AF9-49FE-955A-4ED730C57DDE%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

>If you are using replace as part of your regular workflow, I do agree
>that
>you are probably misusing it. It's just hard to understand why, from
>what
>you said so far (barring the "I don't have an internet connection and
>want
>to use something from my module cache" case, which I find surprising,

"https://github.com/golang/go/issues/37554;

A folder import in whichever file has main() would be nice, but nvm.

I guess it's best to throw up a http server. Would be nice if the docs made it 
clear that http is the simplest solution though. As filesystem use is expected 
to have first class support by most engineers.

If only I knew a good language for writing a web server ? (Joke)

-- 
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/BF30C5ED-E896-45E5-BEC0-9BF3F06A259B%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 1/12/21 12:37 PM, Axel Wagner wrote:
> Again, would be interesting how other languages can make this simpler, 
> because I
> genuinely can't imagine.

The issue is that I believe go avoids files in order to speed up compilation.
Which I am thankful for. It's just I don't believe the replace directive was
meant for this and yet upon googling. It is the only way that I have found. mod
vendor doesn't seem to do what I want.

They are fairly similar otherwise.

Flutter create
open lib/main.dart
add import to file locations in any dart files where you wish to access that
particular code (like in most languages)
add package to pubspec.yaml
IDE asks to run flutter pub get
add import referencing package where needed

vs

go mod init
edit .mod with weird replace line that links a domain to a file location
add import matching replace directive domain/url
go get package
add import for the package

As I said. I should probably just set up a local git server and sync up that
way. symlinks were only an issue in some programs and only when using Windows 
too.

-- 
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/8417466a-deb0-98f6-3635-3240278dbcc7%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 1/12/21 12:33 PM, Axel Wagner wrote:
> You also talk about onboarding - but I don't understand how the rest of your
> message relates to that. The replace-directive is an advanced feature that
> newcomers to the language don't need to be concerned with, as far as I can 
> tell.
> It's really only useful to overwrite the dependencies of your dependencies 
> with
> patched versions - which is pretty fickle and IMO not something newcomers 
> should
> attempt.

Maybe I need to look into -mod vendor as I didn't know that existed. Otherwise
disconnect your internet and then import a folder of local .go files that you
use in multiple projects?

-- 
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/448d0354-65b5-4d0c-1566-88603fd9052e%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 1/12/21 9:39 AM, Artur Vianna wrote:
> I don't think this tweet is very true, it took me many months of learning Go 
> to
> start learning about go.mod. I think that's not the first thing one learns 
> about
> a language, you can just 'vim main.go' and begin experimenting.
>

Fair enough. I had forgotten how easy that is tbh. I did that too, though my
experience was importing packages quite quickly.

I guess it's the

Call code in an external package
"https://golang.org/doc/tutorial/getting-started;

That is a little hairy.

> How do you propose this tool will work?

Not sure exactly. I guess it would ask for remote Git or local Folder/Git option
and maybe folders to import. Then create a .mod and file with main() and those
imports. Maybe I should just be using filesystem links instead of replace
though. I might have tried that and ran into issues though. I should probably
just set up a local git server and /etc/hosts

It just seems that manually editing a .mod with replace entries as well as
imports in the project files to a non existent url location is a bolt on and not
a thoughtful solution.

-- 
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/a3c5862e-460a-796f-40cc-4d605c8c4e36%40gmail.com.

Re: [go-nuts] Go Create

[Kevin Chadwick]

On 1/12/21 9:43 AM, Axel Wagner wrote:
> git init
> go mod init 
> 
> I guess you *could* safe the `git init` part, but is that really worth the 
> added
> complexity?


Sorry I meant replace keyword, not require in the original mail. Though
requiring a domain name is equally unintuitive.

I guess the point is that a domain is good for one scenario and env variables
shouldn't need editing for GoPATH. If env editing isn't needed for go path then
they should be put on an equal footing, maybe GoPATH put back in primary
position. I've never really used GoPATH much but I'm not sure a vendor folder
should be required.

I usually init git from within vscode afterwards. I wonder if doing it pre would
save me any trouble.

AFAICT go mod init works great, if you use remote git.

If you work locally then you have to manually edit the .mod files. For me with a
replace directive to bring in general libraries. That is the likely scenario of
a new user. I have noticed that GoPATH is more prominent again in the docs.

Generelly Gos docs and methods are far simpler and better than Dart/Flutters but
in this regard. Flutter create followed by opening the folder in an IDE with
import files as required, is a lot simpler. I believe they may have some complex
cyclic dependency checking though.

> FTR, I don't think what you are trying to solve here is a problem Jaana is 
> having.

True, but I think maybe more pertinent to the issue of onboarding. After all if
you are using Kubernetes, then you aren't exactly opting for simplicity anyway.

-- 
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/930e33cd-be9d-c2d7-bc8c-ffa84e66e234%40gmail.com.

[go-nuts] Go Create

[Kevin Chadwick]

Inspired by:

"https://twitter.com/rakyll/status/1348723364894961666;

"Yet another couple of hours spent on go.mod and go.sum. If I was giving #golang
a first try today, I'd just give up and look for another option. What are we
doing as a community to address this?"

Couldn't go have a folder based Go create command akin to Flutter create. That
creates a project in the current folder perhaps with a unique 128 bit ID or just
local folder based. IOW Hybrid between Go Path and Go mod (cd based, no GOPATH
env). Maybe there could be a Go import for adding another folder as a lib to the
.mod file?

Go Mod with require keyword still seems unintuitive to me, even with a unique
domain. I still get network calls that I don't want, too. Sometimes I am in one
folder down and get odd failure messages WRT domains, before realising too.

-- 
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/452f4e85-7ddb-9a55-f888-0a93d37f502c%40gmail.com.

Re: [go-nuts] Re: Generics - please provide real life problems

[Kevin Chadwick]

>> Fair enough.
>
>It could be a first step (genrics only in the stdlib) before opening
>generics to everybody.

This stdlib trial approach might allow a spec to mature without the 
compatibility promise? Is there a danger that it evolves to favour implementers 
over readers?

Should support for empty interfaces go? Simplifying interfaces job and 
documentation? Unfortunately external web articles rarely die. Fortunately Gos 
docs are very good and the authoritive source.

Take this with a pinch of salt as my experience is far less than the designers 
being scripting, web, c and more recently Go and Dart and in smaller code 
bases. However I have always endeavoured to write readable code, often 
rewriting c with too much pointer use and either needless or complex 
abstraction. I'm afraid to say that even the recent examples and even robs 
talk, have actually hardened my concern that interfaces, methods and now 
Generics tend to make code less readable with largely pointless abstraction 
compared to multiple simple functions (I don't mean passing functions as 
objects either). Perhaps at the expense of memory copying wrt avoiding methods 
(I guess methods came about because pointers suck). Personally, I find that I 
do not appreciate the OOP approach.



-- 
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/6B8AB03D-888A-492C-B868-5ED650A87F73%40gmail.com.

Re: [go-nuts] Linux distro..based only on GO

[Kevin Chadwick]

On 12/31/20 3:26 PM, L Godioleskky wrote:
> 
> 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?
> 

It would seem not, unless you throw the unix philosophy out of the window
completely wrt one tool, one job.

You would likely need cgo for anything graphical currently, anyway.

I suppose the best you could do right now with build size, would be a console
system, busybox style. Calling e.g. cut, sed as command strings from one large
binary. Perhaps the package manager could build the binary based on command
selections?

Alternatively, perhaps tinygo could be used to create small binaries and keep
the unix phlosophy and packaging.

-- 
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/bca69fb7-1254-5063-7f44-bda1d4038edc%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Kevin Chadwick]

On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> I don't think this is accurate.  Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features.  (To avoid
> misunderstanding I'll say again that changes to the Go language are
> not driven by polls.)

Firstly, I appreciate that dev is not driven by polls but it may be that
internally to Google these desires are true too. It is natural to be less likely
to get an honest answer from many employees, of course.

If Generics is something wanted by the designers without or little debate aside
from the form, then just say so and end the discussion?

One thing brought up in a recent thread is that a past user of Generics in other
languages has found over time he has changed his mind/bias and now prefers his
code without them.

The existence of generics in other languages has likely increased the chances of
this request. Familiarity bias.

Also, whilst understanding that voluntary submission has it's benefits in terms
of avoiding suggestion; that data has already been acquired. I wonder what the
result would be given a number of options. I probably can't think of many of the
good requests, so this could be fuelled by past submissions. I can't remember
hitting a null pointer in my code but certainly have in stdlib network libraries
(missing an & etc.)


Null pointer panic avoidance via automatic error return (what happened before
panics?)

enhanced Gomobile support

enhanced tinygo support

Generics

Flutter, Go cooperation

...

No changes


p.s.

Personally, whilst I respect that I need to account for my familiarity bias. I
feel that Go already has some small rough edges, due to influences and
familiarity bias from some largely frontend languages.

Thank You all for my favourite language and Happy New 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2fdc3328-b65a-9de3-b9ba-75e9973cc20b%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Kevin Chadwick]

On 12/30/20 2:36 PM, Jan Mercl wrote:
> Because there's no good reason to have just yet another
> Java/C++/you-name-it programming language.

I get that point but I have lots of reasons to prefer Go over those. Mostly
readability (but also using utf-16, is just wrong). I know Ian is reportedly
taking readability very seriously at the cost of implementation difficulty, at
least? I don't have the time to commit to analysis, myself. I expect that may
succumb a little to implementers requests during protoyping.


I would love Go to be a safe C that can run everywhere.

Alas, it isn't. The original developers pains were in using c++, not c and they
deserve to reap the benefits of their hard work.

Selfishly, I do hope generics won't have negative effects on runtime/binary size
WRT tinyGo and gomobile.


I was going to delete the rest, but it may explain my skepticism to a degree.

I am still of the opinion that I am yet to see strong arguments for Generics
tbh. Mostly it seems to be a way to fix interfaces, which I don't implement
anyway. When raising the simple case of casting strings to bytes, which
represent most things, the response was, not a pain point. I am happy writing
multiple functions as I expect at some point they will diverge and have the best
chance of being efficient in the process. I don't see why Kubernetes queue
handling isn't type safe already (lack of API control, laziness/work pressure?).
Many experiences may differ and I am surely missing a lot of the details.

I am simply hoping the team and communities will do such a good job of Generics
that we will become thankful for them, in the end. Possibly not. I am very
thankful for channels but not interfaces or methods, despite many attempts to
appreciate them I seem to disagree with the benefits proposed from so many
interfaces articles and videos that I have stopped wasting my time now (Calhouns
was probably the best of them). I simply prefer the c ways to solve the same
problems, atleast for my purposes. I seem to be in the minority there though as
the community seems to love, that which I find pointless. Interfaces even make
reading more difficult, if you care about the details but it doesn't affect me
too much, aside from some wasted time.

-- 
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/6eac705e-16b1-b8c1-9744-7ab64bea6087%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/23/20 11:19 AM, Axel Wagner wrote:
> I have to call it out here though as I see statistic abuse on the news 
> every
> day. Not to mention that asking the question encourages people to think of
> something.
> 
> Ignoring that encouragement in the question (and not remembering survey
> structure). This would more accurately be described as 80% reported not 
> needing
> any new features and 15% reported needing Generics!
> 
> 
> That re-framing is itself abuse of statistics. Because (as rightly pointed out
> by Ian)
> 
>> Of course this isn't definitive, since there was no clear way for people they
> say that do not want generics.
> 
> Unless there was a "I don't need any new features" checkbox, exactly 0% of
> respondents reported not needing any new features.
> There not being such a checkbox might be considered a methodological flaw. But
> luckily, the goal was neither to do science, nor to vote, so it doesn't hugely
> matter.
> 
> I think what how Ian phrased it, is unambiguously the most accurate 
> description:
> 25% of the survey takers answered that question and of those, 79% mentioned
> generics. Any inaccuracies come from reading more meaning into these numbers -
> as you tried when saying "80% reported not needing any new features" or as 
> would
> happen if Go *was* designed based on public polls and these numbers would be
> used to say generics where desperately needed. But it isn't and the survey 
> isn't
> the (only) reason to include generics and Ian was quite careful in pointing 
> out
> the methodological flaws in trying to interpret the numbers in any of these
> ways, so there is nothing to see here :)

I disagree on multiple counts. Most importantly, I misleadingly state "more
accurately" and not accurately described in order to emphasize that the
impression given by the statement may be the complete opposite to reality.

Primarily. It misled me to the wrong conclusion at first. You can argue, that is
my problem, but it isn't. It is framing, though I am sure not intentionally.

An accurate statement might be, "it is the most requested new feature, when
asked"? Of course that assumes new features are good, which is part of the
debate raised in this thread.



On a side note, generics may alleviate some confusion around interfaces and
maybe type safety (I avoid interfaces in my code) and may prove to be a good or
bad thing to happen to Go for me. Unfortunately, I am not sure a survey would
help anyway. Personally, I have found the discussions confusing and haven't the
time or likely the expertise for any sufficient analysis. Perhaps many have but
I doubt that?

I have never used Generics and potentially never will. Maybe I will learn to
love them. The likelihood is a love/hate relationship AFAICT.

Thankfully, Ian is very engaging on the details for those that can and seems to
be very knowledgeable and considerate on the topic. I am glad I don't have those
pressures, too.

-- 
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/a7ced0ab-a7de-c48c-3ce1-9424405cf50c%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/23/20 8:06 AM, Alex Besogonov wrote:
> In general, Go managed to tread a very fine line between "overcomplicated
> nonsense" and "stupidly verbose" pretty well. So I suggest trusting the 
> language
> maintainers. They are doing a great job!

I wholeheartedly agree with this and thank you for your dedication Ian and
others. You have the time to make a far better analysis than most/all of us?, in
any case.


> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics. Previous years also showed support for adding
> generics.  Of course this isn't definitive,

I have to call it out here though as I see statistic abuse on the news every
day. Not to mention that asking the question encourages people to think of
something.

Ignoring that encouragement in the question (and not remembering survey
structure). This would more accurately be described as 80% reported not needing
any new features and 15% reported needing Generics!

-- 
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/4ea1d4b4-6059-936e-5ad2-c7b4919eb369%40gmail.com.

Re: [go-nuts] Re: Generics, please go away!

[Kevin Chadwick]

On 12/21/20 12:26 PM, Space A. wrote:
> Unfortunately it was expected that creators of the language will not resist
> forever being under the pressure of masses

Whilst I don't agree with the language of these mails.

I have worries and struggle to see much benefit also.

Mostly I feel the time could be better spent elsewhere, though I am sure that I
am missing much of the picture.

It is said that it will only be used sparingly and some stdlib functions can
then be written that will be simpler to use.

Yet in Dart I even see examples for riverpod/provider for non generic code
written using Generic syntax, for demo purposes!

The performance will also be reduced, so wouldn't there be pressure for the
stdlib to keep duplicated more performant code, in most cases?


I take comfort in the airings that unlike Dart where dynamics were the norm
originally. It will be explicitly made clear that Generics are intended to be
far from a first resort.

-- 
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/b2fcd8b0-df4b-36cd-eba8-2ba2da110008%40gmail.com.

Re: [go-nuts] Re: Is this really true? (Go 'unable to reliably change their UID once started for goroutines' ?)

[Kevin Chadwick]

>> It is very important to be aware that programs written in Go are unable to
>> reliably change their UID once started, due to how goroutines are implemented
>> on unix systems. As an unavoidable consequence of this, CGI processes started
>> by Molly Brown are run as the same user as the server process.

> It certainly is possible to run a subprocess as a different user. It might not
> be terribly convenient and you definitely have to deviate from the traditional
> fork/change process state/exec" model. But it's also not beyond feasible.

The statement is quite far off practically but pretty close for arguments sake,
if you understand the details. Probably written to avoid criticism to some
degree. It's worth pointing out that whilst running go processes as different
users is certainly a security benefit if designed right and not over used. It is
less important than for daemons written in c.

s/'once started'/'post go command/'

I had read that OpenBSD was unaffected but I'm not sure whether that is true or
whether I am confusing two bugs. If that is true then.

s/'unix'/'linux'/

I Run server processes as many users all started from a master process on
OpenBSD. I just setup the processes before using the go command, to be certain.
Currently they all run as the same process group still. I like that as the
master dying takes down all the processes. So, what I am doing curently is
certainly different to forking children on demand but then I believe that would
be less efficient than using go routines anyway.

I use sh scripts to bootstrap separate process groups where needed for
simplicity and you could always use a sh script to fork processes, if you really
wanted and didn't mind bringing in a shell. Or write a forking tool. That would
be pointless in my experience of using go though.

-- 
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/95b9f584-77a8-6fcf-d29d-4cc283eb36a1%40gmail.com.

Re: [go-nuts] Discussing the browser compatibility of WASM produced by the official Go compiler

[Kevin Chadwick]

 > So please feel free to write down your thoughts and ideas!

My recommendation would be less performant wasm for Safari where it is easily 
maintained. Otherwise drop Safari support almost out of principle. Leaving 
users vulnerable to script kiddie attacks by monopolising Safari engine use AND 
only allowing webkit engine updates with firmware is dispicable anyway and 
anything that shines a light on that is a good thing.

"https://youtu.be/-wqdTxkRkeI;

-- 
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/2F8F9CFF-CEB4-4909-8F22-48727E79840B%40gmail.com.

Re: [go-nuts] ECDSA signature verification

[Kevin Chadwick]

On 2020-10-09 09:01, Kevin Chadwick wrote:
>  However, there is even a possibility that a quantum computer with
> enough qubits to defeat p256 is never built or a traditionally binary computer
> succeeds first in many years time.

It is also worth noting that the amount of money required to build and run a
quantum computer, will be many times more than enough to subvert a certificate
authority today.

-- 
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/85d0dae2-397d-cfd0-8000-04e733cdd99f%40gmail.com.

Re: [go-nuts] ECDSA signature verification

[Kevin Chadwick]

On 2020-10-08 16:22, Marcin Romaszewicz wrote:
> Practically, there isn't much reason today to use the P384 and P521 curves. 
> The
> security provided by P256 is very good, not known to be crackable today, and
> it's a widely supported curve. P384 is reasonably well supported, but not as
> widely, and P521 isn't well supported at all, since it's not in the NSA Suite 
> B
> crypto recommendations, which drive many crypto standards.

There is no good reason to use P384 and little reason to use P521 and no reason
to use p521 for a standard website. The only reason I know of to consider p521
which the browsers do not support (for no good reason, though ssh even installs
a 256 bit host key by default anyway, so maybe key variability simplicity) is
because it offers the greatest challenge in qubits to any potential quantum
computer. However, there is even a possibility that a quantum computer with
enough qubits to defeat p256 is never built or a traditionally binary computer
succeeds first in many years time.

I don't think the world is quite ready for tls 1.3 only yet but you could even
limit the provided algorithms to ed25519 or block P384 in tls 1.2. I would see
that as a far better choice than cgo personally!

Here is how
"https://blog.cloudflare.com/exposing-go-on-the-internet/;

-- 
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/1da205bc-b646-1595-75c2-d1c4c02d3ed2%40gmail.com.

Re: [go-nuts] Exec and write data to stdin of new process

[Kevin Chadwick]

On 2020-09-30 23:48, Ian Lance Taylor wrote:
>> Is there a way to accomplish this in go? Normally what I'd do is `fork` a 
>> process that would handle writing to a pipe, `dup` the read end of the pipe 
>> to stdin and then `exec` to the process I want to run, but `syscall` doesn't 
>> have a `Fork`. I could probably use `import "C"` but at that point I would 
>> just rather write the tool in C.
> There is no syscall.Fork because Go programs are always
> multi-threaded, and there is no safe way to fork a multi-threaded
> program.  fork/exec can be made safe if written with care, but plain
> fork cannot.
> 
> The closest you can come is what you showed later, where you fork/exec
> a program to feed standard input back to your own program.  Or you
> could, if possible, put the new process's standard input in a file,
> and syscall.Open/syscall.Dup before you syscall.Exec.

There is an issue (closed I believe) that ended up asking whether it could be
allowed before running any go routines. The response was, along the lines of
worth it?, why not just run "/bin/sh program &"

-- 
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/64d3f6a5-6b12-f9e1-f663-1eb1f7254145%40gmail.com.

Re: [go-nuts] error types/strings and errors.Is

[Kevin Chadwick]

> The current approach of passing them through mostly untouched still allows the
> application to make any decision it wants based on them - and that's where the
> necessary information is anyway.

I like the approach with multi return far more than Darts try, catch etc. My
first thought was that perhaps they shouldn't need a grep to find, but that is
of course easier said than done, with so many builds.

>> And even given Posix, you might have small variance in exact interpretation
>> of certain error codes or constants, so it tends to be a good thing to make
>> sure your operating system interprets them as you expect. In addition, many
>> modern APIs live outside the umbrella of Posix, making things even more
>> fluctuating in what you can expect. As a general rule, I tend to go with Alex
>> suggestion: pack them away until they are needed and only use them with
>> surgical precision.


I don't actually need them logically, though I did a little when using TLS. The
errors.Is is mainly to give a user a more friendly rectification message and the
actual log message if a more information button, is clicked.

I'm OK with testing and grepping for them though, actually. Especially with the
stability that syscall.Errno brings.

Regards, kc

-- 
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/7d2be321-26dd-b1bd-84cf-c1f4a5996d2e%40gmail.com.

Re: [go-nuts] error types/strings and errors.Is

[Kevin Chadwick]

On 2020-09-29 18:38, Axel Wagner wrote:
> I hope not. If you want to handle a specific error, what you should do is file
> an issue to expose that error as a type (and thus make it part of the API of 
> the
> package), not to match strings - precisely *because* they aren't part of the
> stable API, if they are not exposed, so shouldn't be relied on.
> 

OK. I expected not but thought they were unlikely to change atleast.

> For your specific case, have you tried `errors.Is(err,
> syscall.Errno(syscall.ENETUNREACH))`?

That works, Thank You

I feel like a few of these should probably be exposed in the net package?
Perhaps they haven't because different systems return different ones in
different circumstances, but I hope Posix means that isn't the case.

-- 
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/091726ef-29c6-31f1-f128-b2a15ebea26a%40gmail.com.

Re: [go-nuts] error types/strings and errors.Is

[Kevin Chadwick]

On 2020-09-28 23:28, Ian Lance Taylor wrote:
> I don't think there is any one solution that will be used in all
> cases.  Where the standard library can reasonably provide a shared
> error type, it should, as it already does for types like os.PathError
> and os.SyscallError.  For a user package, whether it returns a
> specific error type is part of that package's API.  Often there is no
> need for special error types for a user package.  Where there is a
> need, the error types should be documented like any other part of the
> API

Is ENETUNREACH - "network is unreachable" typed anywhere? I assume string
matching on these is part of the Go 1 promise?

-- 
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/1f29dfd6-2f41-ac84-6ee8-c9ff0d4bf917%40gmail.com.

[go-nuts] error types/strings and errors.Is

[Kevin Chadwick]

Are there any thoughts on how to handle error types. Will the user create custom
error types from strings for use with errors.Is like for their own code or are
some error strings in the stdlib likely to change. In which case an "import
errors/types" managed by the stdlib might make sense?

proposal: Go 2 error values

https://github.com/golang/go/issues/29934#issuecomment-546896170

-- 
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/ebb5c380-2c55-c198-d3a8-013852b91e9f%40gmail.com.

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

[Kevin Chadwick]

On 2020-09-11 19:08, Ian Lance Taylor wrote:
> The way Go works, ioutil.ReadFile is compiled with the io/ioutil
> package.  It can't change based on how it is called.  So it is always
> going to return []byte.

Ok. I figured it might save an allocation as well if the coder made clear their
intention prior. I thought it may not be worth the effort, even if it were
straight forward.

Thanks for the consideration.

-- 
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/30d863c3-c702-2f26-3b33-d66f4add4e40%40gmail.com.

[go-nuts] Proposal: auto return String instead of []byte if requested

[Kevin Chadwick]

I apologise if this has already been discussed. Google didn't turn up anything
directly related.

If you read a file using the following that returns a byte slice.

tlsCertb, err := ioutil.ReadFile("/etc/ssl/mycert")
if err != nil {
   log.Fatal(err)
}
tlsCert = string(tlsCertb)

Is there a way to get a string without the cast.

Otherwise couldn't the language automatically return a string rather than a byte
slice in these cases if the receiving var is already a string?

e.g.

var string tlsCert
tlsCert, err = ioutil.ReadFile("/etc/ssl/mycert")
if err != nil {
   log.Fatal(err)
}

-- 
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/80be59d6-be0a-4112-3c6b-7f37b05543ea%40gmail.com.

[go-nuts] Please thumbs up this github issue, if you might like to use Go with Flutter?

[Kevin Chadwick]

https://github.com/flutter/flutter/issues/65315

Thanks

-- 
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/5bb34c95-77f6-739a-06ba-aca2be39974b%40gmail.com.

Re: [go-nuts] rin: return if nil syntactic sugar

[Kevin Chadwick]

On 2020-08-31 03:34, Ian Lance Taylor wrote:
>> Idk if this has been proposed or discussed before.
>>
>> Given the last error handling abbreviation proposal is rejected. How about 
>> some simple syntactic sugar like this:
>>
>>   rin Something()
>>
>> Which is just a sugar for:
>>
>>   if err := Something(); err != nil {
>> return err
>>   }
>>
>> To make it worth the new keyword make it so that:
>>
>>   rin v := Something()
>>
>> equals to:
>>
>>   v, err := Something()
>>   if err != nil {
>> return err
>>   }
> This is similar to the check/handle design draft, without the handle.
> You may want to take a look at https://golang.org/issue/40432.
> Thanks.

I am using flutter and so Dart for the frontend right now, and I have come to a
conclusion that is related but perhaps beyond magical. It is my opinion that
having additional syntax simply for syntactic sugar reasons offers little
benefit but pointless cognitive load when reading code. I now remove syntactic
sugar in Dart like => and ... in my codebases. As the full syntax does the same
thing but offers greater functionality, I see negatives with negligible benefit
in any case.

Especially when there is the potential for code readers to switch from backend
to frontend and not necessarily being masters in both languages.

-- 
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/d7a23054-25d5-5cb3-2fd1-33a310bf4917%40gmail.com.

[go-nuts] Frontend languages utf-16 bubble

[Kevin Chadwick]

On 2020-08-13 14:16, Brian Candler wrote:
> If you want a mutable string, look at []byte instead, and read the excellent
> intro to slices at https://blog.golang.org/slices

Does anyone think the frontend languages can be persuaded to meet the web
standards and switch to Utf-8, rather than sticking to their Utf-16 bubble?

"https://github.com/dart-lang/sdk/issues/36316;

-- 
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/74a3d3f1-9521-eb85-7597-5a26d138aeff%40gmail.com.

Re: [go-nuts] Assigning byte to string location is not allowed

[Kevin Chadwick]

On 2020-08-13 14:16, Brian Candler wrote:
> 
> If you want a mutable string, look at []byte instead, and read the excellent
> intro to slices at https://blog.golang.org/slices
> 

Also worth remembering that unicode strings aren't necessarily bytes, so
requiring verbose action for byte access, instead of using the strings package,
isn't really a bad thing.

-- 
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/29ef10a4-986b-2f4e-e733-ee5b151aca3e%40gmail.com.

Re: [go-nuts] Is a variation on Templates a better way for Generics?

[Kevin Chadwick]

On 2020-08-01 18:34, Ian Lance Taylor wrote:
> Personally, when it comes to interpretation by the reader, I think
> that the new generic syntax in the design draft is fairly minor.  I
> don't see how a template based approach will be any clearer; it won't
> be less clear, but I don't see why it will be clearer.  Perhaps you
> could write down a couple of short examples to show why using
> templates would be clearer for the reader.

I'm thinking (whilst likely missing some important things) that a reader
wouldn't even need to know the Generics syntax to understand the executed code.
Just the author. To become an author, the reader could look at the templates
compared to the .go code output. It's certainly true that it wouldn't be worth
the effort, if the Generic syntax is easily understood anyway.

However, I'm not sure the following is a trivial amount of work to understand,
especially if it becomes part of a more complex piece of code?

"https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md;

-- 
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/2e323144-1225-9bcc-f443-271ae5c3ec61%40gmail.com.

Re: [go-nuts] Is a variation on Templates a better way for Generics?

[Kevin Chadwick]

On 2020-08-01 18:20, Ian Lance Taylor wrote:
>> I'm wondering. Would it be better to have say a template in a folder that is
>> used to generate all the various typed Golang ready for the compiler.
>>
>> This way the code would be fully typed and could be maintained in one place. 
>> The
>> compiler could maybe still be as fast as today post generation and the 
>> untyped
>> code ignored and the generated typed code read more easily as standard code?
> There are existing tools that work that way for Go.  They can be
> awkward for cases where you need to instantiate a type with a generic
> type, as in List(List(int)).  They don't tend to help much with
> compilation time overall, as each package that needs a generic type
> needs to instantiate the template itself, so you get lots of
> duplicates that all get compiled.  Debugging is awkward as the
> debugger doesn't know anything about the copies.

I was mainly thinking that having duplicate code with typed syntax would be more
understandable and a substantial advantage over new generic syntax that requires
further interpretation by the reader. The generated .go files could also teach
how to write the generic code. Sounds like it may have already been considered
and ruled out though.

-- 
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/4b61560a-686e-9069-a9e7-cf8e206fd127%40gmail.com.

[go-nuts] Re: Is a variation on Templates a better way for Generics?

[Kevin Chadwick]

On 2020-08-01 10:29, Kevin Chadwick wrote:
> I'm wondering. Would it be better to have say a template in a folder that is
> used to generate all the various typed Golang ready for the compiler.
> 
> This way the code would be fully typed and could be maintained in one place. 
> The
> compiler could maybe still be as fast as today post generation and the untyped
> code ignored and the generated typed code read more easily as standard code?

Maybe the compiler could switch between the generated imports depending on the
type in 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/063874f8-c704-f0e1-e6b8-d17cd4767911%40gmail.com.

[go-nuts] Is a variation on Templates a better way for Generics?

[Kevin Chadwick]

I'm wondering. Would it be better to have say a template in a folder that is
used to generate all the various typed Golang ready for the compiler.

This way the code would be fully typed and could be maintained in one place. The
compiler could maybe still be as fast as today post generation and the untyped
code ignored and the generated typed code read more easily as standard code?

-- 
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/b10bdfa8-a81b-42b2-387c-8733b4c6372f%40gmail.com.

Re: [go-nuts] Go in programming language trends

[Kevin Chadwick]

>The fact that JS is top and above TyoeScript says a lot. 
>

Really, that is your analysis?

Assuming valid data and considering js has enjoyed monopoly status for so long, 
despite an IMO terrible syntax;

It says a lot that javascript is falling and typescript and Dart are rising. Or 
maybe that is frameworks choosing for users like js is the browser choosing?

I definitely prefer Golang function syntax over Dart and Dart function syntax 
over js though.


-- 
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/6B8878BA-45AC-4A39-9ED4-517600B78ECB%40gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

[Kevin Chadwick]

>  If simply being connected to the internet is risky enough that
> your machine can be compromised

Incidentally, as the leakage is bits over time. OpenSSH added this defence.

Add protection for private keys at rest in RAM against speculation and memory
sidechannel attacks like Spectre, Meltdown, Rowhammer and Rambleed. This change
encrypts private keys when they are not in use with a symmetic key that is
derived from a relatively large "prekey" consisting of random data (currently 
16KB).

"https://www.undeadly.org/cgi?action=article;sid=20190621081455;

-- 
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/72ef34b1-8247-37c3-479f-a82f4d142c29%40gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

[Kevin Chadwick]

On 2020-06-12 00:47, joe mcguckin wrote:
> Yes, of course they have internet connections, but I don't run virtualization
> software. It's my understanding that most of these 
> bugs have to do with information leaking from one process or VM to another or
> with a process trying to escape from it's user process into a higher 
> privileged one.  If simply being connected to the internet is risky enough 
> that
> your machine can be compromised, there's more of a problem here than a cpu 
> bug.

Yes, the original play down by Linus proved to be a bad move, like the SMT
default has/will! Just like embargos measured in months (latest is something
like a year or more!) while smaller players are kept in the dark for no good
reason. Who then have to work under pressure before POC that bad guys have
probably acquired for ages, are being released.

An OS uses privileges for everything!

"https://www.redhat.com/en/blog/thoughts-netspectre;

"NetSpectre proves the danger of jumping to conclusions (although the current
observed access rates to unauthorized data are slow as noted below). The
brilliant team of researchers at TU Graz in Austria have once again demonstrated
a completely novel attack."

"https://misc0110.net/web/files/netspectre.pdf;

-- 
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/ec9c0c0a-675b-edd0-303d-276de1f9b281%40gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

[Kevin Chadwick]

>Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
>
>It's my understanding that there is a significant performance penalty
>and I 
>don't share my machines
>with anyone else, so I'm not concerned with information leaking between
>

It is likely more dangerous, than you realise. So they don't receive any data 
from the Internet?

-- 
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/1486A9D3-7233-4851-A3BB-04B4004368F7%40gmail.com.

Re: [go-nuts] Re: GO on multi-processor systems

[Kevin Chadwick]

>> What about where there are multiple cpus?  My servers have 2, 6 core 
>> Xeons. With hyper threading, it looks like 24 cores available to
>Linux.

I know the latest issues also affect hyper threading/SMT but you shoukld 
consider switching it off or using AMD, if you care about security. OpenBSD was 
proven right in that regard and yet Linux still kept it insecure/enabled, by 
default!!!

-- 
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/D29E1BC0-C83F-4AD1-9455-D907EA261B70%40gmail.com.

Re: [go-nuts] TLS dial error pkg variables - Best way to logically detect the type of tls failure

[Kevin Chadwick]

On 2020-06-08 01:49, Matt Harden wrote:
> I suspect your (possibly wrapped) error will be of type
> x509.UnknownAuthorityError, so you should be able to check for it with 
> errors.As:
> 
> var uaerr x509.UnknownAuthorityError
> if errors.As(err, ) {
>   // handle as an unknown authority error
> }

Thank You

It is even documented at the bottom of the x509 doc!

I read errors could be found in "Variables", in a forum and assumed they would
all be in one place, doh.

I guess a case sensitive search for Error, may work.

-- 
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/b1951dcb-4501-d8f8-26eb-f3cb433a7f8f%40gmail.com.

[go-nuts] TLS dial error pkg variables - Best way to logically detect the type of tls failure

[Kevin Chadwick]

I want my client application to behave differently depending upon whether the
server is down or it is a "x509: certificate signed by unknown authority" 
condition.

It seems there isn't an errors.Is (btw the dot syntax makes it difficult to
google search!)

I intend to just string match the returned error. However, as it isn't a pkg
variable (had to grep). Does the string fall outside the compatibility promise?

If so. Is there a better way or should I just create a test to run on every
stdlib upgrade?

Thanks

-- 
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/f4ddc813-ade5-7501-4fb4-d19dba375a4f%40gmail.com.