Re: [tsc-devel] Rewrite: Programming language

Taran Lynn | Mon, 25 Sep 2017 14:47:52 UTC

There's a couple of problems I could see with go. Probably #1 is 
dependency management.
The current dependency management system is still experimental 
https://github.com/golang/dep, and not widely adopted.
However, considering current C/C++ dependency management is essentially 
"have the user manually install
the correct software and version" go's dependency management could still 
be a huge benefit to ease of adoption of TSC.

The error passing can also get tedious, not just to write but also to 
read as well. This didn't become
apparent in the gopong example (allegro seems to leave error conditions 
undocumented), but
become more of on issue on a larger project.

The last point is that go lacks templates (a.k.a. generics). This isn't 
much of a problem though, as arrays
and maps are builtin to be generic. Since we mainly use generics for 
std::vector and some XML parsing,
this isn't a huge deal compared to if we used some sort of specialized 
containers.

On 09/25/2017 07:09 AM, …9@g… wrote:
> Wait, is writing the game in Go up in the air????
>
> Oh god...
>
> --
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
> http://refi64.com
>> On Sep 25, 2017 at 6:57 AM, <Marvin Gülker 
>> <mailto:…r@p…>> wrote:
>>
>> Hi,
>>
>>
>>
>> I have further investigated Go and am positively surprised. The
>>
>> integration with existing C libraries is the easiest one I have seen
>>
>> until now. cgo (the tool used for it, ships with Go itself) is able to
>>
>> parse C header files fully automatically. Add
>>
>>
>>
>>      /*
>>
>>      #include <your/header/here.h>
>>
>>      #include <stdlib.h>
>>
>>      ...
>>
>>      */
>>
>>      import "C"
>>
>>
>>
>> to your Go file and you can directly (!) use the C functions in the
>>
>> named headers without having to write mapping functions for the most
>>
>> part. Only some edge cases require you to write C code (most notably
>>
>> accessing members of unions, though some raw byte magic in Go could work
>>
>> around that). cgo is even able to parse simple macros and transform them
>>
>> into a Go equivalent.
>>
>>
>>
>> It is not possible to integrate C++ (or any other language) directly. It
>>
>> however is possible to bridge to a C++ or other language library via a C
>>
>> interface; in this regard, Go is not different from Ruby.
>>
>>
>>
>> Am 24. September 2017 um 15:09 Uhr +0300 schrieb Lauri Ojansivu <…x@x… <mailto:…x@x…>>:
>>
>> > I have programmed with Go about 3 months previously, and it's really
>>
>> > nice.
>>
>>
>>
>> Okay, this sounds good. I find it easier to work with than C++, though
>>
>> it feels a little like writing object-oriented code in C, because one
>>
>> has to mention the receiver explicitely in a method. The "backward" type
>>
>> notation needs some accustomisation, I am still making this mistake
>>
>> again and again. One thing I specifically dislike about Go's syntax is
>>
>> the forced curly else clause, as in the following:
>>
>>
>>
>>      if ... {
>>
>>      } else { // << `else' cannot be on its own line
>>
>>      ...
>>
>>      }
>>
>>
>>
>> This bogs me. When I work on `if/else' I mentally draw a straight line
>>
>> up the code to find the matching `if' and the curled braces confuses me,
>>
>> which is worse especially with long `if/elseif/else'
>>
>> statements. Luckily, there is a remedy for the latter: a bare `switch'
>>
>> statement. For `else' alone, I can live with it. The language was not
>>
>> made specifically for me after all.
>>
>>
>>
>> > It compiles very fast, and can crosscompile fast to Windows, ARM etc very
>>
>> > nicely from Linux etc.
>>
>>
>>
>> I have not tested crosscompilation yet, but I believe you if you say it
>>
>> works. I will take a look on it later on. What I did test was native use
>>
>> of Go on Windows, and I am satisfied by what I found. Go works
>>
>> flawlessly with MSYS2, it even is contained in the standard
>>
>> repositories. cgo works as well, and it has no problems linking to a
>>
>> C library compiled with MSYS2's gcc; I have not yet tested the Win32API,
>>
>> but if it can link to normal libraries, I see no reason why it should
>>
>> not be able to work with the Win32API.
>>
>>
>>
>> For my tests, I wrote a simple Pong game in Go that uses Allegro[1]. The
>>
>> game is available on GitHub[2] and compiles as-is both on Linux and on
>>
>> Windows using a standard `go build'. The game is not a beaty in code
>>
>> organisation and has problems if you have a good graphics card, because
>>
>> the ball moves with 1px per frame (i.e. the faster your graphics card,
>>
>> the faster the game). But it's not a serious game anyway, so I did not
>>
>> feel like fixing those problems, it's goal is to demonstrate
>>
>> cross-platform use of Go with a C library linked.
>>
>>
>>
>> Greetings
>>
>> Marvin
>>
>>
>>
>> [1]:http://liballeg.org
>>
>> [2]:https://github.com/Quintus/gopong
>>
>>
>>
>> --
>>
>> Blog:https://www.guelkerdev.de
>>
>> PGP/GPG ID: F1D8799FBCC8BC4F
>>
>>
>>