Re: [tsc-devel] Rewrite: Programming language

Marvin Gülker | Mon, 25 Sep 2017 17:25:08 UTC

Am 25. September 2017 um 07:47 Uhr -0700 schrieb Taran Lynn <…0@g…>:
> There's a couple of problems I could see with go. Probably #1 is
> dependency management. [...] 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 current dependency management has its problems (too recent versions
required, I accept I have made a big mistake in this regard), but to my
knowledge is the standard way to do it in C/C++. I have build several
open-source projects from source over the years, and apart from using a
different build system (mainly Autotools vs. CMake), this is what is
normal. If you find TSC's dependency management prohibitive, then you'll
find most open source projects' dependency management prohibitive.

I don't share this impression. In fact, I have always disliked
in-language package systems like Ruby's RubyGems or now Rust's Cargo,
because I think that dependencies should be provided by Linux
distributions for security reasons. What benefit does a user have from
having the same library in five versions installed via three different
package managers on his system?

As a Gentoo user, I like to keep my system slim and have no unnecessary
cruft on it. I live fine without systemd, pulseaudio, a desktop
environment and without most graphical programmes. mutt is a great email
programme, by the way, and I still like mailing lists. Compiling a lot
of software from source is natural to me, and I like fiddling with
compilation options. I tell you this to give you an impression of my
attitude towards computer software in general and what you can expect
from me.

> 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.

However we decide to manage dependencies, I hope that the number of
dependencies can be cut down. My experiment with Allegro showed that
integrating C libraries is very easy with Go and does not require
language binding libraries as I know it from Ruby and D, thus avoiding
the creation of additional dependencies.

> 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.

Go has an idiom in that it returns error conditions via a second return
value on a public interface (it supports real multiple return values,
not just parameter returns), thus the problem is not as difficult as in
C, where the returned value and the error indicator usually mix up
(except for POSIX functions, which usually use the clumsy `errno'). If
you feel the need to use exceptions, you can use panic() and recover(),
as long as you do not expose a panic over a package's public
interface. By the way, TSC on many places does not use C++'s exceptions,
because good parts of the code base date back to a time where C++ did
not have exceptions. Most exceptions have been added after SMC was TSC.

Allegro is a C library. It does not have stack-unwinding exceptions and
indicates errors by means of the return value. My `gopong' example does
not check the return values of Allegro's functions, which a real
programme should do of course. Please do not consider `gopong' anything
else than a try of mine to combine Go and C in one program, it
definitely is not good code in any way.

Delete `DejaVuSansMono.ttf' from the build directory and see it
segfaulting because it does not bother checking the return value of
al_load_ttf_font().

> 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.

You are the first person I see who likes C++'s template syntax. I
personally find it unusable and only refer to it where I cannot work
around it easily. I actually expect a modern programming language to not
provide such an awful piece of syntax. Languages without it have been
going along pretty good as far as I can see as they offer different
idioms on solving whatever problem is at hand.

Go can accept any type of value by using the empty interface
`interface{}'. That allows you to build type-agnostic containers or
functions where you need it. And arrays/slices/maps are already
type-independent as you mentioned. I very much like that Go has a
builtin map construct with an unobtrusive syntax.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F