Re: [go-nuts] Go and GPUs

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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"

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

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

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

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

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

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 preall

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

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?

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

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

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

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

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

>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

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

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 >

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

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 messag

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

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

[go-nuts] Auto Make a named return map

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

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

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

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

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

Re: [go-nuts] Orderly exit

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

Re: [go-nuts] Orderly exit

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

Re: [go-nuts] Orderly exit

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

Re: [go-nuts] Orderly exit

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

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

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 -

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

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

Re: [go-nuts] Orderly exit

> 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

[go-nuts] Orderly exit

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

Re: [go-nuts] Error handling

>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

Re: [go-nuts] Error handling

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

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

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

Re: [go-nuts] Go Create

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

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

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

Re: [go-nuts] Go Create

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 p

Re: [go-nuts] Go Create

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

Re: [go-nuts] Go Create

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

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

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

Re: [go-nuts] Go Create

> 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

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

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

Re: [go-nuts] Golang security and reliability

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

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

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

[go-nuts] Golang security and reliability

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

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

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

Re: [go-nuts] Generics syntax suggestion

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

Re: [go-nuts] Generics syntax suggestion

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

Re: [go-nuts] Generics syntax suggestion

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 i

[go-nuts] Generics syntax suggestion

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

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

>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

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

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

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

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

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

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

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

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,

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

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

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

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

Re: [go-nuts] Advice, please

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

Re: [go-nuts] Generics security discussion.

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

Re: [go-nuts] Generics security discussion.

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

Re: [go-nuts] Generics security discussion.

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

[go-nuts] Generics security discussion.

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

Re: [go-nuts] Go Create

>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

Re: [go-nuts] Go Create

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

Re: [go-nuts] Go Create

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

Re: [go-nuts] Go Create

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

Re: [go-nuts] Go Create

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

[go-nuts] Go Create

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

Re: [go-nuts] ECDSA signature verification

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

Re: [go-nuts] ECDSA signature verification

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 >

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

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

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

> 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

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

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

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

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,

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

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?

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

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

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

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

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

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

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

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 :=

[go-nuts] Frontend languages utf-16 bubble

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

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

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,

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

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

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

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

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

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

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

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

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

>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

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

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

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

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

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

>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

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

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

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

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

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

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

  1   2   >