Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
Thread beginning with comment 552196
To read all comments associated with this story, please click here.
Meh
by moondevil on Tue 12th Feb 2013 06:36 UTC
moondevil
Member since:
2005-07-08

I really wish I could like Go, specially given the Oberon influence the language has, but they just left too much out:


- exceptions

panic/recover feels like a hack

- enumerations

Possible using typed consts with iota, but it feels bad when compared with languages that have language support for enumerations.

- generic types

Most likely it will never get them.

- direct use of OS APIs, without the need of writing wrappers

Requires the use of CGO and a C compiler, while the majority of languages with native compilers allow direct binding to foreign code via some form of extern declarations

- only static compilation is available;

Complicates some plugin architectures, which is debatable given security concerns.

Does not allow for open source licenses that forbid the use of static linking in commercial software.

- no support for meta-programming;


As for some of the good things:

- fast compilation

Nice that they keep on mentioning it. Modula-2 was doing it in 1978, like any language that followed it in the Pascal family.

Only C and C++ suffer from lack of compilation speed.

- the PR about go routines and channels

Similar features are available as library concepts in more powerful languages.

- interfaces

The only feature Go interfaces have over Java and C# interfaces is that you are not required to directly reference them. This also complicates tracking down which interfaces a given type supports without help of an IDE like LiteIDE.


I spent one year doing Go projects on the side (2011), even did an initial contribution to the windows package for os.user, after realizing I would be better off with D and Rust.

Edited 2013-02-12 06:42 UTC

Reply Score: 5

RE: Meh
by satsujinka on Tue 12th Feb 2013 07:28 in reply to "Meh"
satsujinka Member since:
2010-03-11

I took a look at Rust awhile ago... but it just didn't look like a fun language to use. So I'm curious about why you find it more suitable than Go.

D is one of those languages that I keep meaning to poke at, but never get around to (because there's really nothing there except nicer syntax.)

As for Go:
I don't care for exceptions. Multiple returns with an error works well in my opinion.
I don't frequently use enumerations.
Generic types would be nice (or rather better polymorphism support in the same vein as Haskell's would be nice, but then again most of my complaints with Go end up being "well if it was more like Haskell...".)
CGO is certainly a weak point of Go's...
I have no great desire for dynamic linking, so I really don't care if only static linking is available by default.
I'm not a huge meta-programming fan... so the lack there isn't a big deal to me either.

To me, the nicest thing about Go is its standard library and documentation. I also like its clean syntax (for a C-like language.)

Reply Parent Score: 4

RE[2]: Meh
by moondevil on Tue 12th Feb 2013 08:40 in reply to "RE: Meh"
moondevil Member since:
2005-07-08

I took a look at Rust awhile ago... but it just didn't look like a fun language to use. So I'm curious about why you find it more suitable than Go.


- Macros
- Proper type inference a la ML
- generics
- non nullable types
- sum types
- exceptions

The only thing I don't like in Rust is the Perl syntax influence in how pointers get declared.

D is one of those languages that I keep meaning to poke at, but never get around to (because there's really nothing there except nicer syntax.)


It is really a better C++, not only syntax.

You get to do meta-programming with proper language support, not the C++ template hacks.

Safer than C++, because you are require to state which code is unsafe. In C++ even if you restrict yourself to the safe language constructs, you need a static analyzer to proof it.

Whereas D is safe by default unless you make use of system modules/sections.

Go strides exited already in D before Go was created.

Additionally both languages have:

- some form of automatic memory management
- modules
- support for concurrency
- follow the school of thought where the developers have the same facilities as the compiler writers to create data structures.

Reply Parent Score: 3

RE[2]: Meh
by Jondice on Tue 12th Feb 2013 13:25 in reply to "RE: Meh"
Jondice Member since:
2006-09-20

You may want to check out the ATS language, though I'm still warming up to the "look" of the syntax. No time to post my thoughts, so here's the blurb from their site. (There's also a kernel and some linux drivers written in ATS):

"ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in the framework Applied Type System, which gives the language its name. In particular, both dependent types and linear types are available in ATS. The current implementation of ATS (ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see The Computer Language Benchmarks Game for concrete evidence) and supports a variety of programming paradigms that include:

Functional programming. The core of ATS is a functional language based on eager (aka. call-by-value) evaluation, which can also accommodate lazy (aka. call-by-need) evaluation. The availability of linear types in ATS often makes functional programs written in it run not only with surprisingly high efficiency (when compared to C) but also with surprisingly small (memory) footprint (when compared to C as well).

Imperative programming. The novel and unique approach to imperative programming in ATS is firmly rooted in the paradigm of programming with theorem-proving. The type system of ATS allows many features considered dangerous in other languages (e.g., explicit pointer arithmetic and explicit memory allocation/deallocation) to be safely supported in ATS, making ATS a viable programming language for low-level systems programming.

Concurrent programming. ATS, equipped with a multicore-safe implementation of garbage collection, can support multithreaded programming through the use of pthreads. The availability of linear types for tracking and safely manipulating resources provides an effective means to constructing reliable programs that can take advantage of multicore architectures.

Modular programming. The module system of ATS is largely infuenced by that of Modula-3, which is both simple and general as well as effective in supporting large scale programming.

In addition, ATS contains a subsystem ATS/LF that supports a form of (interactive) theorem-proving, where proofs are constructed as total functions. With this component, ATS advocates a programmer-centric approach to program verification that combines programming with theorem-proving in a syntactically intertwined manner. Furthermore, this component can serve as a logical framework for encoding deduction systems and their (meta-)properties.

What is ATS good for?

ATS can enforce great precision in practical programming.

ATS allows the programmer to write efficient functional programs that directly manipulate native unboxed data representation.

ATS allows the programmer to reduce the memory footprint of a program by making use of linear types.

ATS allows the programmer to enhance the safety (and efficiency) of a program by making use of theorem-proving.

ATS allows the programmer to write safe low-level code that runs in OS kernels.

ATS can help teach type theory, demonstrating concretely the power and potential of types in constructing high-quality software."

Edited 2013-02-12 13:28 UTC

Reply Parent Score: 5

RE: Meh
by vivainio on Tue 12th Feb 2013 11:09 in reply to "Meh"
vivainio Member since:
2008-12-26

Goroutines are not really available as simple libraries in other environments, since they don't map 1:1 to OS threads.

Python equivalent would probably be "Greenlets".

Reply Parent Score: 2

RE[2]: Meh
by moondevil on Tue 12th Feb 2013 12:45 in reply to "RE: Meh"
moondevil Member since:
2005-07-08

Goroutines are not really available as simple libraries in other environments, since they don't map 1:1 to OS threads.


You mean co-routines, continuations, Java Tasks, .NET tasks, C++11 futures, Win32 fibers and many other examples?

All of those do a M:N mapping of tasks to threads.


Edit: added some extra information

Edited 2013-02-12 12:50 UTC

Reply Parent Score: 2