 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
So you mean each thread waits for messages to arrive, processes them,
maybe sends some other messages, and then waits for the next message?
> 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.
Mmm... In C, an integer is a "first class" thing, but that doesn't mean
you can send it over a network connection, for example. They might mean
that these channels only work inside a single running instance of a
single program.
>> 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%.
Oh, OK. I assumed they all do what Haskell does - you call forkIO and it
creates a thread. You specify CLI options to say how many *real* threads
to use.
[It's mildly irritating that to change the number of real threads, you
must stop and restart your program - and also you can only control this
from the CLI args...]
> I'll have to see what kind of introspection they support and what kind
> of dynamic loading.
Ah, dynamic loading is fun.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> So you mean each thread waits for messages to arrive, processes them,
> maybe sends some other messages, and then waits for the next message?
Essentially, yes.
> Mmm... In C, an integer is a "first class" thing, but that doesn't mean
> you can send it over a network connection, for example. They might mean
> that these channels only work inside a single running instance of a
> single program.
If you can send a channel over another channel, then all you need is to
encapsulate channels over sockets and you're done. If you can't send a
channel over another channel, then it isn't first class.
> Oh, OK. I assumed they all do what Haskell does
No. Generally, desktop languages that supported threading before multi-CPU
machines were common either fake it or use OS threads. Any language with a
"threadpool" structure in the library is probably one of these.
Java with green threads faked it, Java with real threads allocates threads
one for one, C# uses real threads, Smalltalk fakes it, C and C++ tend to use
real threads, etc.
Of course, java and C# can change the semantics to use lightweight threads.
C and C++ are probably stuck unless they break compatibility with all the
other thread languages. Smalltalk is probably stuck with its own threads
because everything there is "too open".
> Ah, dynamic loading is fun.
It's important for long-running programs, things with plug-ins, etc. Even if
it's just dynamic linking. Of course, given it's google, they might very
easily say "crash out if you want to load a different implementation of
something, because everything we write recovers automatically anyway."
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> So you mean each thread waits for messages to arrive, processes them,
>> maybe sends some other messages, and then waits for the next message?
>
> Essentially, yes.
Seems like a conceptually simple model.
>> Mmm... In C, an integer is a "first class" thing, but that doesn't
>> mean you can send it over a network connection, for example. They
>> might mean that these channels only work inside a single running
>> instance of a single program.
>
> If you can send a channel over another channel, then all you need is to
> encapsulate channels over sockets and you're done. If you can't send a
> channel over another channel, then it isn't first class.
I would suggest that sending a channel over a channel is probably
trivial, but sending a channel over a socket is probably *highly* complex...
>> Oh, OK. I assumed they all do what Haskell does
>
> No. Generally, desktop languages that supported threading before
> multi-CPU machines were common either fake it or use OS threads.
Oh. Really? I didn't know that...
Well, now I guess I understand why everybody gets so excited about
Haskell's concurrency support then. :-}
>> Ah, dynamic loading is fun.
>
> It's important for long-running programs, things with plug-ins, etc.
> Even if it's just dynamic linking. Of course, given it's google, they
> might very easily say "crash out if you want to load a different
> implementation of something, because everything we write recovers
> automatically anyway."
It's supposedly one of the big plus points of Java - not that I have
*ever* seen *any* Java program which actually supports plugins, mind you...
As an aside, GHC theoretically is supposed to support dynamic loading.
Good luck making it actually work though...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Seems like a conceptually simple model.
That was the idea. Sort of like Lambda calculus - very simple, easy to prove
things about with the right formalisms. Then it turned into products.
> I would suggest that sending a channel over a channel is probably
> trivial, but sending a channel over a socket is probably *highly*
> complex...
Could be, could be. But you can conceptually make it work without breaking
the language.
> Well, now I guess I understand why everybody gets so excited about
> Haskell's concurrency support then. :-}
That's part of it.
> It's supposedly one of the big plus points of Java - not that I have
> *ever* seen *any* Java program which actually supports plugins, mind you...
At the time Java did it, it was rather new. Nowadays, Java's mechanisms are
fairly lame compared to the competition.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Seems like a conceptually simple model.
>
> That was the idea.
I gathered. ;-)
> Then it turned into products.
LOL.
>> It's supposedly one of the big plus points of Java - not that I have
>> *ever* seen *any* Java program which actually supports plugins, mind
>> you...
>
> At the time Java did it, it was rather new. Nowadays, Java's mechanisms
> are fairly lame compared to the competition.
Question: How many Java programs have you seen that are more than
Tic-Tac-Toe demo programs? ;-)
(Personally, I haven't seen many - although there are a few...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Question: How many Java programs have you seen that are more than
> Tic-Tac-Toe demo programs? ;-)
Quite a few.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 escreveu:
> Question: How many Java programs have you seen that are more than
> Tic-Tac-Toe demo programs? ;-)
>
> (Personally, I haven't seen many - although there are a few...)
A large part of the e-commerce web is powered by java application
servers. The reason you only see old tic-tac-toe java "applets" is
because that's what is left on the web after Sun's goals for desktop
java apps got spoiled by Microsoft with their own incompatible Java runtime.
That said, desktop java apps are still used at a fairly large scale.
Federal Postoffice agency here in Brazil uses one such app for all its
transactions. It has that caracteristic Swing look-and-feel. I gather
banks also rely on java infrastructure heavily. You quite never deal
with it directly, though. Only with the familiar generated HTML.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Question: How many Java programs have you seen that are more than
>> Tic-Tac-Toe demo programs? ;-)
>>
>> (Personally, I haven't seen many - although there are a few...)
>
> A large part of the e-commerce web is powered by java application
> servers. The reason you only see old tic-tac-toe java "applets" is
> because that's what is left on the web after Sun's goals for desktop
> java apps got spoiled by Microsoft with their own incompatible Java
> runtime.
>
> That said, desktop java apps are still used at a fairly large scale.
> Federal Postoffice agency here in Brazil uses one such app for all its
> transactions. It has that caracteristic Swing look-and-feel. I gather
> banks also rely on java infrastructure heavily. You quite never deal
> with it directly, though. Only with the familiar generated HTML.
...so what you're saying is, Java ended up being big server-side rather
than client-side?
Oh, the irony of designing a language that works anywhere, and then only
running it in one place. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> because that's what is left on the web after Sun's goals for desktop
> java apps got spoiled by Microsoft with their own incompatible Java
> runtime.
I think you need to listen to less hype and read more actual accounts of
what happened there. MS's JVM passed more of Sun's compatibility tests than
Sun's did. Java applets sucked *everywhere* from incompatibility, at least
as broken as HTML was, even from V1.0, long before MS wrote their own JVM.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Java applets sucked *everywhere* from incompatibility,
> at least as broken as HTML was, even from V1.0, long before MS wrote
> their own JVM.
Write once, debug everywhere(tm).
Also amusing was the way that every single revision of Java deprecated
massive chunks of the APIs and added entire new ones. And also how all
the APIs were insanely over-complicated and scantily documented.
(Anybody know the difference between Applet.init() and Applet.start()?
Because I don't! How many million methods does Component have?)
I especially liked how in one release they deprecated a set of methods
and provided replacements, and in the next release they deprecated the
new set and UNdeprecated the originals! o_O
I haven't used Java for ages. I wonder if it's calmed down yet?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I especially liked how in one release they deprecated a set of methods
> and provided replacements, and in the next release they deprecated the
> new set and UNdeprecated the originals! o_O
That's OK. The media player I'm interfacing to deprecated a whole slew of
methods in favor of methods they haven't implemented yet. I must say, that's
a first in my experience.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> ...so what you're saying is, Java ended up being big server-side rather
> than client-side?
>
> Oh, the irony of designing a language that works anywhere, and then only
> running it in one place. ;-)
Like, in Sun servers, IBM machines, Windows or Linux boxes? etc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v8 wrote:
>> I especially liked how in one release they deprecated a set of methods
>> and provided replacements, and in the next release they deprecated the
>> new set and UNdeprecated the originals! o_O
>
> That's OK. The media player I'm interfacing to deprecated a whole slew
> of methods in favor of methods they haven't implemented yet. I must say,
> that's a first in my experience.
That's friggin 31337!!
Still, at least they only deprecated rather than *remoted* stuff. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> http://golang.org/
Overhyped? I'm still happy I decided on Python next.
http://www.dalkescientific.com/writings/diary/archive/2009/09/15/100000_tasklets.html
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Hmmm. Interesting. (Three people have told me about this already. :)
That's Google Hype-Generating Marketing Machine at work!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > http://golang.org/
>
> Overhyped? I'm still happy I decided on Python next.
>
>
http://www.dalkescientific.com/writings/diary/archive/2009/09/15/100000_tasklets.html
That's really cool. And it's cooler that spython is faster without even needing
an explicit compilation step. :)
I have to say once they announced go, I wondered how would Erlang compare...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ...so what you're saying is, Java ended up being big server-side rather
>> than client-side?
>>
>> Oh, the irony of designing a language that works anywhere, and then only
>> running it in one place. ;-)
>
> Like, in Sun servers, IBM machines, Windows or Linux boxes? etc
Yeah, but I mean if you're working server-side, you just have to compile
the thing for whatever platform your server runs. You don't need dynamic
runtime portability.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
