[OT] Lua community and Go language

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[OT] Lua community and Go language

Lorenzo Donati-3
Hi All!

First of all sorry in advance for posting something only mildly related
to Lua.

I've had this curiosity for the last couple of months, after reading
some articles on the current state of Go language and its usage at
Google. According to Google, it seems that Go is helping solve an
increasing number of problems in Google's codebase efficiently and
cleanly. According to their vision (as I get it) Go is *the* next
generation system programming language (and sometimes it seems to me
they would want it to be the next C).

What's the relation with Lua? Since I subscribed to lua-l I've read tons
of posts of experienced high-level developers describing what
language(s) (beside Lua) they use in their projects. Most are C/C++ or
even assembly, but lots of other more "esoteric" languages have been
mentioned as being used in *production* of non-toy projects.


I've never seen on lua-l such statements about Go. Only casual mentions
for more or less toy or proof-of-concepts projects. Neither have I seen
mentions to Go in those PLs "shootouts" that occasionally pop-up in lua-l.

I myself have spent some time playing with it, after reading some posts
of Steve Donovan, but I cannot really say I've become a Go expert! Since
Go is packed with lots of cross-platform "batteries" and a tightly
integrated C-compiler (CGO) it seems to me that it would make an
excellent platform for developing in Lua, too, but it doesn't seem it
has caught Lua developers' attention.


Therefore, I'd really like what's the stance of Lua community regarding
Go: is it too young? Pros vs. Cons? Is it really considered a good
language for SW production by expert, seasoned developers? Is it too
much hype? What's wrong with Go? Do you think is it a language worth of
investing your time on for serious programming?

TIA for all the explanations and opinions any of you will have the
kindness to share!

Cheers!

-- Lorenzo




--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Sven Olsen
So, I've also dabbled in Go; and would be interested in hearing others' impressions of it.

My own sense is that it's a truly excellent language for writing servers -- mostly because it has a well thought out collection of concurrency and exception handling features.  Speaking as a hobbyist, I'd certainly recommend it to other hobbyists interested in rolling simple but efficient servers.  

But while the semantics are lovely, Go's syntax has some warts. The variable definition shorthand makes it easy to write scoping bugs, and the syntax restrictions on newlines seem fairly terrible.  A few months back we had a long thread on lua-l about the changes in lua's newline handling between 5.2 and 5.1 -- and working with Go has left me with a renewed confidence that sensible newline sensitivity is important.  As best as I can tell; Go's parser will throw an error anytime you do something with newlines that makes it vaguely nervousness -- effectively a much more aggressive version of the "Ambiguous syntax" error from 5.1.  And this ends up being a perpetual source of small annoyances.

I still think Roberto et al. went too far in dropping all newline checks from 5.2 -- but Go stands as an excellent example of the problems inherent in the opposite extreme.

-Sven


On Mon, Aug 5, 2013 at 9:57 AM, Lorenzo Donati <[hidden email]> wrote:
Hi All!

First of all sorry in advance for posting something only mildly related
to Lua.

I've had this curiosity for the last couple of months, after reading
some articles on the current state of Go language and its usage at
Google. According to Google, it seems that Go is helping solve an
increasing number of problems in Google's codebase efficiently and
cleanly. According to their vision (as I get it) Go is *the* next
generation system programming language (and sometimes it seems to me
they would want it to be the next C).

What's the relation with Lua? Since I subscribed to lua-l I've read tons
of posts of experienced high-level developers describing what
language(s) (beside Lua) they use in their projects. Most are C/C++ or
even assembly, but lots of other more "esoteric" languages have been
mentioned as being used in *production* of non-toy projects.


I've never seen on lua-l such statements about Go. Only casual mentions
for more or less toy or proof-of-concepts projects. Neither have I seen
mentions to Go in those PLs "shootouts" that occasionally pop-up in lua-l.

I myself have spent some time playing with it, after reading some posts
of Steve Donovan, but I cannot really say I've become a Go expert! Since
Go is packed with lots of cross-platform "batteries" and a tightly
integrated C-compiler (CGO) it seems to me that it would make an
excellent platform for developing in Lua, too, but it doesn't seem it
has caught Lua developers' attention.


Therefore, I'd really like what's the stance of Lua community regarding
Go: is it too young? Pros vs. Cons? Is it really considered a good
language for SW production by expert, seasoned developers? Is it too
much hype? What's wrong with Go? Do you think is it a language worth of
investing your time on for serious programming?

TIA for all the explanations and opinions any of you will have the
kindness to share!

Cheers!

-- Lorenzo




--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Sven Olsen
In reply to this post by Lorenzo Donati-3

> Since Go is packed with lots of cross-platform "batteries" and a tightly
> integrated C-compiler (CGO) it seems to me that it would make an
> excellent platform for developing in Lua, too, but it doesn't seem it
> has caught Lua developers' attention.

At first glance, my impression is that Go would be an awkward partner for Lua -- goroutines like to be lightweight; while the main route for maintaining thread safety in lua is to have a unique state for each thread.  There's probably ways of engineering around that awkwardness -- perhaps by using channels to set up some sort of shared lua-state pool -- but I haven't tried it.

-Sven
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

William Ahern
In reply to this post by Sven Olsen
On Mon, Aug 05, 2013 at 03:08:03PM -0700, Sven Olsen wrote:
> So, I've also dabbled in Go; and would be interested in hearing others'
> impressions of it.

I looked at the Go source code several years ago and ran away in horror. It
made lots of Linux-only assumptions, and had lots of "fix this later"
comments for even the most basic of features which were claimed to be
complete. For a system that was supposedly high-concurrency it's use of
poll() was horrible (and not merely the choice of poll, per se). I'm sure
they support epoll, etc, now, but that wouldn't be encouraging AFAIC.

The larger design of Go is rather nice, particularly its channels
implementation from Plan 9 Limbo (and predecessors). The syntax and other
basic elements, of course, reflect the developers' extreme pragmatism, which
can turn many people off.

But the details are dirty, dirty, dirty, especially compared to Lua. The
Unix/Plan 9 guys are infamous for the "worse is better" motto (not that they
would necessarily own up to it). They take lots of shortcuts based on their
superior knowledge of the existing environment, but which can cause problems
later down the line. It took Unix almost 30 years to become relatively
stable--assumptions break long after people forget the assumptions were
taken.

I wouldn't use Go for anything security related. If hackers take notice it's
going to be bloody for a little while.

That's my opinion, FWIW.

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

steve donovan
In reply to this post by Sven Olsen
On Tue, Aug 6, 2013 at 12:16 AM, Sven Olsen <[hidden email]> wrote:
At first glance, my impression is that Go would be an awkward partner for Lua -- goroutines like to be lightweight; while the main route for maintaining thread safety in lua is to have a unique state for each thread.

It isn't obvious.  I've done a convenient reflection-based way to use Lua from Go (luar) and I'm not sure how to go further and make a happy marriage between coroutines and goroutines.  To be safe, one does need unique Lua states, and then the reasonable thing would be to only share data using channels - not a million miles from LuaLanes.

As for the language, I picked up the basics quickly and tend to use it for binary data processing where I would have earlier used C.

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Gé Weijers
In reply to this post by Sven Olsen
The newline rule in Go is fairly simple: the language definition uses semicolons as statement terminators, like C, but the compiler inserts them automatically if the last token on a line is one that could end a statement, e.g. literals, ")", "}", ","break", "++", etc.
You can safely break up lines after a comma, opening bracket, opening parenthesis, or operator.

fun(a,
      b+
      c,
      &thing{
          1,
          "Foo",
      })




On Monday, August 5, 2013, Sven Olsen wrote:
 
 As best as I can tell; Go's parser will throw an error anytime you do something with newlines that makes it vaguely nervousness -- effectively a much more aggressive version of the "Ambiguous syntax" error from 5.1.  And this ends up being a perpetual source of small annoyances.





--


Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Miles Bader-2
Gé Weijers <[hidden email]> writes:
> the compiler inserts them automatically if the last token on a line is
> one that could end a statement

Nasty...  Go is like a bundle of bad decisions all nicely packaged for
convenient use. ><

-miles

--
Politeness, n. The most acceptable hypocrisy.

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Craig Barnes
On 6 August 2013 15:23, Miles Bader <[hidden email]> wrote:
>
> Nasty...  Go is like a bundle of bad decisions all nicely packaged for
> convenient use. ><
>
> -miles

Semicolon insertion is the only obviously ugly thing I've found with
Go so far. What else is there?

Other than a couple of small warts, I find it a refreshing improvement
over C, although obviously not a replacement.

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Robert Virding
Coming from the Erlang world another bad decision is basing everything on shared memory between goroutines. This really open up the possibilities of synchronisation bugs.

For those interested in combining Lua with concurrency/parallelism is Luerl. It is a Lua implementation in Erlang which makes it easy to run many concurrent Lua "machines".

Robert

----- Original Message -----

> From: "Craig Barnes" <[hidden email]>
> To: "Lua mailing list" <[hidden email]>
> Sent: Tuesday, 6 August, 2013 4:54:22 PM
> Subject: Re: [OT] Lua community and Go language
>
> On 6 August 2013 15:23, Miles Bader <[hidden email]> wrote:
> >
> > Nasty...  Go is like a bundle of bad decisions all nicely packaged
> > for
> > convenient use. ><
> >
> > -miles
>
> Semicolon insertion is the only obviously ugly thing I've found with
> Go so far. What else is there?
>
> Other than a couple of small warts, I find it a refreshing
> improvement
> over C, although obviously not a replacement.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Gé Weijers


On Tuesday, August 6, 2013, Robert Virding wrote:
Coming from the Erlang world another bad decision is basing everything on shared memory between goroutines. This really open up the possibilities of synchronisation bugs.


Most of the time goroutines communicate over typed channels, Go is loosely modeled on Hoare's CSP, and so is Erlang. The difference is that Go also allows other methods. The prudent software engineer will avoid shared memory whenever it's feasible.




--


Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

steve donovan
On Wed, Aug 7, 2013 at 1:18 PM, Gé Weijers <[hidden email]> wrote:
Most of the time goroutines communicate over typed channels, Go is loosely modeled on Hoare's CSP, and so is Erlang. The difference is that Go also allows other methods. The prudent software engineer will avoid shared memory whenever it's feasible.

Yep, it's pragmatic and you have to be a grown-up and your good choices - definitely a descendent of C ;)

For any goroutine/coroutine Lua integration, data over channels is the way to go (pun not intended)  One day soon, if the weather worsens (as Ralph knows ;)).  Not quite the average Sunday afternoon hack, because I have to keep the semantics of three languages in my head at once....



Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Rena
In reply to this post by Craig Barnes
On Tue, Aug 6, 2013 at 10:54 AM, Craig Barnes <[hidden email]> wrote:
On 6 August 2013 15:23, Miles Bader <[hidden email]> wrote:
>
> Nasty...  Go is like a bundle of bad decisions all nicely packaged for
> convenient use. ><
>
> -miles

Semicolon insertion is the only obviously ugly thing I've found with
Go so far. What else is there?

Check out how it handles dates: http://golang.org/src/pkg/time/format.go

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Lorenzo Donati-3
On 08/08/2013 0.40, Rena wrote:

> On Tue, Aug 6, 2013 at 10:54 AM, Craig Barnes <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 6 August 2013 15:23, Miles Bader <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > Nasty...  Go is like a bundle of bad decisions all nicely packaged for
>     > convenient use. ><
>     >
>     > -miles
>
>     Semicolon insertion is the only obviously ugly thing I've found with
>     Go so far. What else is there?
>
>
> Check out how it handles dates: http://golang.org/src/pkg/time/format.go
>
> --
> Sent from my Game Boy.

Ah! Yes!

I never looked at the implementation, but the way you specify dates is
*WEIRD*.

I've always thought it was difficult to remember all those C time format
strings (%H, %Y, %whatever...) ... until I saw Go time package!
At least most C placeholders make sense.

I remember I spent half an hour to try to understand why a stupid
20-liner didn't work - then I reread very carefully the docs just to
discover that I gave for granted they used C-like format strings (mental
note to myself ALWAYS RTFM - you really *never* know :-)

I had to reread the API docs of Time.Format a couple of times before my
brain accepted the fact that they wanted me to remember a SPECIFIC date
(wait, ... was it 5 seconds or 5 minutes? And the year? ugh!)

Let alone all those magic numbers sprinkled all over the code!!!
The rationale behind that choice is utterly incomprehensible to me. What
should the advantage be of writing:

fmt.Println(time.Now().Format("2006-01-02 03:04"))

instead of say (made up syntax):

fmt.Println(time.Now().Format("%Y-%m-%d %H:%M"))

Supposed readability? For an absolute newbie in programming maybe, but
any mediocre programmer should be well aware of the meaning and
advantages of symbolic representations.

<hyperbole> That's even worse than sprinkling math code with 3.14
numbers instead of some PI constant. In this latter case, at least, 3.14
is a well known beast. </hyperbole> :-)


WEIRD!


--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

steve donovan
On Thu, Aug 8, 2013 at 3:20 PM, Lorenzo Donati <[hidden email]> wrote:
fmt.Println(time.Now().Format("2006-01-02 03:04"))

It is very .. eccentric. Rob Pike is very proud of this idea ;)

I guess all languages have their weird bits, although I can no longer tell what's weird about Lua.  A feeling of weirdness is just cognitive indigestion - obviously I've just got used to things as they are.

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Lorenzo Donati-3
On 08/08/2013 15.37, steve donovan wrote:
> On Thu, Aug 8, 2013 at 3:20 PM, Lorenzo Donati
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     fmt.Println(time.Now().Format("2006-01-02 03:04"))
>
>
> It is very .. eccentric. Rob Pike is very proud of this idea ;)

VIP people can do whatever they like with their toys ;-)

But the ancients had a lot to say about hubris being the sin of the
mighty ones ... :-)

>
> I guess all languages have their weird bits, although I can no longer
> tell what's weird about Lua.  A feeling of weirdness is just cognitive
> indigestion - obviously I've just got used to things as they are.
>

Well, yes. Every language has some. As a general rule of thumb I like
languages which try to come close to natural language (Chomsky hierarchy
permitting) without being too verbose at the same time.

So i tend to interpret the line

fmt.Println(time.Now().Format("2006-01-02 03:04"))

approximately as:

  print a line containing the current time formatted as ...

and till this point it is fairly good, but then comes the distractor

... as "2006-01 ...etc."

so my brain starts thinking why this special date must be there. Why not
"1990-02...etc". It is just the wrong bit of information. Wrong because
it doesn't belong there. It has nothing to do with the code I'm writing.
It is an arbitrary artifact of the API design. Just smoke in your eyes.
No more helpful than "%Y-%M .. etc.", but in this latter case there is
no distracting factor, it is evident it is a template for something and
not a sort of "date literal". FWIW they could have chosen to parse also
"YYYY-MM-DD HH:SS", or "year-month-day".

Moreover it fails miserably on such simple things:

fmt.Println(time.Now().Format("I drank 15 bottles of beer in 2006") )

which prints:

  I drank 23 bottles of beer in 2009

instead of:

  I drank 15 bottles of beer in 2009

Debug this! You get the point. :-)

So whenever you must construct non trivial messages involving dates you
end up doing more work!

I wonder if Pike's idea has some followers. Maybe it's me, but I really
cannot see any advantage beside screaming to a non programmer reading
the code "hey, look at me, I'm a date!" (and only in the most simple
cases, as the above trivial example shows).



--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Lua community and Go language

Lorenzo Donati-3
On 08/08/2013 17.23, Lorenzo Donati wrote:

Ahem, a note is needed, because of the funny output:

>
> which prints:
>
>   I drank 23 bottles of beer in 2009

This above is the output I got from Go home page "Try Go" applet (they
should update the clock on their server!)

>
> instead of:
>
>   I drank 15 bottles of beer in 2009
>


--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

printf is a crappy language in a crappy language (was Re: [OT] Lua community and Go language)

Jay Carlson
In reply to this post by steve donovan
On Aug 8, 2013, at 9:37 AM, steve donovan wrote:

> On Thu, Aug 8, 2013 at 3:20 PM, Lorenzo Donati <[hidden email]> wrote:
>> fmt.Println(time.Now().Format("2006-01-02 03:04"))

> It is very .. eccentric. Rob Pike is very proud of this idea ;)

It is a cute idea, but just like printf, it's a symptom of a lack of expressive power at compile-time.

Famously, the Pascal runtime cannot be implemented in terms of itself. C is much better, but originally had no standard mechanism for functions with a variable number of arguments either; there was no way of writing your own printf.
An informal mechanism and then a standard were created, and they're designed to barely handle printf/scanf, and forwarding of those varargs.

Most C compilers these days have special mechanisms hooked up to the printf/scanf functions to warn of mismatches in type between the format string and the arguments. So there's a special case again: you can't write your own replacements with the same functionality, especially if you are in the -Werror camp, where warnings are treated as errors.

What time.Format and printf/scanf have in common is that they use raw strings as little languages compiled and evaluated at runtime. Why strings? Because other kinds of literals are too painful to express, usually. Here's some fake Go code:

import "time"
import . "time/format" // hate-magnet[1]

ISO8601 = TimeFormat{YYYY, MM, DD, Lit{"T"}, HH, Lit{":"}, MS, Lit{":"}, SS}
Kitchen = TimeFormat{Hh12, Lit{":"}, MS, PM}
RFCTime = TimeFormat{HH, Lit{":"}, MS, Lit{":"}, SS, Lit{" "}, TMZ}
// Tired of retyping stuff?
s_ = Lit{" "}
RFC1123 = TimeFormat{Wkday, Lit{", "}, DD, s_, Mon, s_, YYYY, s_, RFCTime}

Where various YYYY types as well as TimeFormat itself all implement a common formatting interface.

I don't know about you, but in this case I think expressing structure as structs seems a lot more painful than just chucking everything into a string. Which is too bad, since I already had enough "everything is a very weakly typed string" in my Tcl years. Aren't these higher level languages supposed to be higher level?

For Lua, the safest thing is to compile the specs at module load time:

local RFCTime = TimeFormatter"HH:MS:SS TMZ"

function yow()
  if rarely_taken_conditional then
    io.write("Yow! It's ", RFCTime(os.time()), ".")
  end
end

which means you'll find out you screwed up your MM/MS/MN syntax *before* rarely_taken_conditional becomes true.

But for composition you need something like this:

local RFC1123 = TimeFormatter$"Wkday, DD Mon YYYY $RFCTime"

where $"" is syntactic sugar of the general form

  $"abc $foo def" => {"abc $foo def", foo=foo}

to be able to work in the lexical environment.


Jay

[1]: This is one of those times for a block scope for those "import * from blargh" statements.. All symbols from blargh would become first in lookup order in some limited spot, without spraying the rest of your code with them. _ENV is very nice....
Reply | Threaded
Open this post in threaded view
|

Re: printf is a crappy language in a crappy language (was Re: [OT] Lua community and Go language)

Dirk Laurie-2
2013/8/13 Jay Carlson <[hidden email]>:

> What time.Format and printf/scanf have in common is that they use
> raw strings as little languages compiled and evaluated at runtime.
...
> I don't know about you, but in this case I think expressing structure
> as structs seems a lot more painful than just chucking everything into
> a string.

>From the title, I thought you were inveighing _against_ printf/scanf.
>From the message itself, it seems you nevertheless regard them as the
lesser evil.

Or am I misunderstanding you totally?

Reply | Threaded
Open this post in threaded view
|

Re: printf is a crappy language in a crappy language (was Re: [OT] Lua community and Go language)

Jon Akhtar
One of the first things you do when learning to program is simple IO.

Try to write printf yourself. In C without any libraries except the ones you may choose to write while implementing printf.

I have seen OO's answer to printf. That was funny. both in C++ and in Java early on. If you don't like printf or its ilk - which encode their state machines in a readable format - what do you like? I think you haven't yet thought it through from the viewpoint of the programmer who is not a language nerd.




On Tue, Aug 13, 2013 at 6:18 AM, Dirk Laurie <[hidden email]> wrote:
2013/8/13 Jay Carlson <[hidden email]>:

> What time.Format and printf/scanf have in common is that they use
> raw strings as little languages compiled and evaluated at runtime.
...
> I don't know about you, but in this case I think expressing structure
> as structs seems a lot more painful than just chucking everything into
> a string.

>From the title, I thought you were inveighing _against_ printf/scanf.
>From the message itself, it seems you nevertheless regard them as the
lesser evil.

Or am I misunderstanding you totally?


Reply | Threaded
Open this post in threaded view
|

Re: printf is a crappy language in a crappy language (was Re: [OT] Lua community and Go language)

steve donovan
In reply to this post by Jay Carlson
On Tue, Aug 13, 2013 at 8:18 AM, Jay Carlson <[hidden email]> wrote:
For Lua, the safest thing is to compile the specs at module load time:
local RFCTime = TimeFormatter"HH:MS:SS TMZ"

Well, TimeFormatter could throw a wobbly if it was passed something that didn't make sense.

Penlight's Date.Format is a step in the right direction:

http://stevedonovan.github.io/Penlight/api/modules/pl.Date.html#Date.Format

But it does not blow up (or even return a proper error) if passed nonsense.  So, work to be done (in particular, the default formatter without an explicit string tries way too much)

I understand the context you're coming from - that there are too many _untyped_ strings floating around with structure which is only checked when they are 'interpreted'.

I do like string interpolation tactics like "$YEAR-$MONTH-$DAY". Some languages allow string interpolation that respects the lexical environment, (so in Moonscript it would be "#{YEAR}-#{MONTH}-#{DAY}") but even without language support (a) these strings can be checked by a suitable formatter constructor and (b) allows for formatting tables.
123