Go and Assembly

Post by jlgreco » Fri, Feb 08, 2013, 12:30 AM UTC

emmelaich wrote: post #63

freehunter wrote: post #2

And herein lies the problem with Go. Seriously, try searching for articles about Go on HN. People always say "well the name isn't a problem, because you just search for it with "golang" instead!" but no one writes golang unless they're pointing out how to search for it . If I was trying to get back to this article a month from now and I searched for "go", would I find it? Probably not, unless I remembered the article…

C and R used to be hard to search for, but these days Google search does brilliantly given a bit of context. If Go is hard to search for now, be sure it will get better. I do wish they had chosen a different name, but I realise it matters less and less.

Post by WalterBright » Fri, Feb 08, 2013, 12:43 AM UTC

    int *_memset32(int *p, int value, size_t count) {
      asm {
        mov     EDI,p           ;
        mov     EAX,value       ;
        mov     ECX,count       ;
        mov     EDX,EDI         ;
        rep                     ;
        stosd                   ;
        mov     EAX,EDX         ;
      }
    }

Post by flogic » Fri, Feb 08, 2013, 1:34 AM UTC

jlgreco wrote: post #79

rartichoke wrote: post #73

Earlier quoted context omitted.

It's a good start but it needs many more features to be considered usable. For example, I just did a search for "redis" and about 30 libs came up. Half of them don't even have a description. How can I know which one to pick at a glance? Asking me to evaluate and profile 30 different libs for just a single task is unreasonable. Also this page isn't even on Google's first page for when you search for something. I didn'…

How do you handle that with any other language? There is no shortage of redis libs for any language.

Post by cerales » Fri, Feb 08, 2013, 1:57 AM UTC

geoka9 wrote: post #56

charlieflowers wrote: post #44

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too). I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful. I don't know i…

I think the only thing missing is a REPL as part of the tool chain. ipython and scala shell are so useful, especially when you're learning or just testing things out.

Post by charlieflowers » Fri, Feb 08, 2013, 3:04 AM UTC

charlieflowers wrote: post #59

jlgreco wrote: post #49

Earlier quoted context omitted.

I think the real value of panic/recover over try/catch is the vastly improved idiomatic usage. Only to be used in exceptional cases, and never to cross package boundaries. I just find that so much more pleasant.

Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.