|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://golang.org/
go google()!
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> http://golang.org/
>
> go google()!
I don't see anything in that website that claims Google has anything to do
with it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> http://golang.org/
> go google()!
I wonder if anyone has devised a version of the bullshit bingo for
programming-related topics. I bet that page would get quikly a win... ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez escreveu:
> nemesis wrote:
>> http://golang.org/
>>
>> go google()!
>
> I don't see anything in that website that claims Google has anything to do
> with it.
http://golang.org/doc/go_faq.html#Is_Google_using_go_internally
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis escreveu:
> Nicolas Alvarez escreveu:
>> nemesis wrote:
>>> http://golang.org/
>>>
>>> go google()!
>>
>> I don't see anything in that website that claims Google has anything
>> to do with it.
>
> http://golang.org/doc/go_faq.html#Is_Google_using_go_internally
>
and
http://golang.org/doc/go_faq.html#What_is_the_origin_of_the_name
and
http://blogs.computerworld.com/15078/googles_go_a_new_open_source_programming_language
BTW, I wonder if Guido van Rossum is involved in any way...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis schrieb:
> http://golang.org/
As for the actual syntax, this seems pretty much like "C reloaded". Lots
of crypticisms in there.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> nemesis schrieb:
>> http://golang.org/
>
> As for the actual syntax, this seems pretty much like "C reloaded". Lots
> of crypticisms in there.
Surely Google's javascript expertise has something to do with too...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> http://golang.org/
Hmmm. Interesting. (Three people have told me about this already. :)
> Interfaces can be added after the fact if a new idea comes along or fo
r
testing—without annotating the original types.
That's a good step towards the "next language" bit I was talking about
earlier. Where unit testing is trivial in the language, or some such.
> Go's concurrency primitives derive from a different part of the family
tree whose main contribution is the powerful notion of channels as first
class objects.
Very nifty. I suspect I'm going to have to look into this more.
> It is practical to create hundreds of thousands of goroutines in the s
ame
address space. If goroutines were just threads, system resources would ru
n
out at a much smaller number.
And this.
I was very skeptical just glancing thru it at first, but it seems there's
more going on than evident at a quick glance.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Interfaces can be added after the fact if a new idea comes along or
> for testing—without annotating the original types.
>
> That's a good step towards the "next language" bit I was talking about
> earlier. Where unit testing is trivial in the language, or some such.
This is one of my favourit things about Haskell classes [which are
really interfaces]. You can add them to any type you fancy.
> > Go's concurrency primitives derive from a different part of the
> family tree whose main contribution is the powerful notion of channels
> as first class objects.
>
> Very nifty. I suspect I'm going to have to look into this more.
I must admit, I'm not sure what this even means. Might be interesting
though.
"Do not communicate by sharing memory. Instead, share memory by
communicating. And there is no spoon."
> > It is practical to create hundreds of thousands of goroutines in the
> same address space. If goroutines were just threads, system resources
> would run out at a much smaller number.
>
> And this.
Lots of languages have light-weight threads, no?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I must admit, I'm not sure what this even means. Might be interesting
> though.
CSP. A bunch of actors running around exchanging messages asynchronously,
each process being a single thread in its own address space. Like Erlang or
any of the other dozens of languages designed for real-time distributed
processing.
That the channel itself is a first class object makes for the ability to do
cool stuff like passing the channel to a new version of the program running
on a different computer, so you don't lose any outstanding messages.
Assuming they really mean "first class" there.
> Lots of languages have light-weight threads, no?
Many have lightweight threads that also occupy multiple processors. I.e.,
most languages where you can launch 10,000 threads launch them in one
process and fake it 100%.
But yes, the availability of lightweight objects and first-class channels is
a good combination. Either one alone is difficult.
I'll have to see what kind of introspection they support and what kind of
dynamic loading.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |