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

> 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. Yes, I understand that in your projects using tinyGo instead o

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

On Wed, Mar 17, 2021 at 3:22 PM Kevin Chadwick wrote: > That is not what you said or meant and I didn't make an assumption. > No offense, but you did use the words "assuming generics poses a question". Apologies that I misunderstood, but I was trying to respond to that. > I was basically askin

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 t

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

On Wed, Mar 17, 2021 at 2:36 PM Kevin Chadwick wrote: > > *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 > > < > https://github.com/golang/prop

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

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

Java was actually very successful on micros. It is running on billions of IOT and smart card devices - and android on SoC. > On Mar 17, 2021, at 4:47 AM, Kevin Chadwick wrote: > >  >> >>> Go will loose its uniqueness and values, will never become a next big >> thing. No cross platform GUI, n

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

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

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

On Wed, Mar 17, 2021 at 10:47 AM Kevin Chadwick wrote: > 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. When I look at the Go language feature pag

[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