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.
Order by: Score:
I like it
by intangible on Tue 12th Feb 2013 01:31 UTC
intangible
Member since:
2005-07-06

I like most of the things I've seen with Go so far... Seems like it's closer to C or C++ done right with the benefit of hindsight rather than a replacement for scripting languages.
I'd love to see a first rate UI toolkit for Go, it really seems like a good use for it instead of building a monster from C or C++ and _insert_toolkit_here_.

Unfortunately in my day to day job, Java is a better fit (server-side web stuff), but using Go for a REST layer is probably a near future project for me.

Reply Score: 6

RE: I like it
by butters on Tue 12th Feb 2013 03:04 UTC in reply to "I like it"
butters Member since:
2005-07-08

Go was designed to displace Java in server-side web apps. The Go standard library includes a concurrent HTTP server, and Google App Engine provides a complete web framework in Go. REST layers are almost trivial and a few are already available on GitHub and Google Code.

I'd love Go bindings for Qt (imagine signals and slots mapped to channels in Go), but I'm told that it would be prohibitively difficult to implement ;)

Reply Score: 7

RE[2]: I like it
by vivainio on Tue 12th Feb 2013 09:45 UTC in reply to "RE: I like it"
vivainio Member since:
2008-12-26

I'd love Go bindings for Qt (imagine signals and slots mapped to channels in Go), but I'm told that it would be prohibitively difficult to implement ;)


https://github.com/visualfc/go-ui is a start.

You cannot easily replicate exact Qt C++ experience (like Python did), but you can create a nice wrapper anyway.

Reply Score: 5

Comment by kwan_e
by kwan_e on Tue 12th Feb 2013 01:48 UTC
kwan_e
Member since:
2007-02-18

It is blisteringly obvious in hindsight that enforcing visibility at the package level instead of the class level is the right way to do it. Who cares if the other class poking around in your class’s internals is your subclass or whatever?


Which you can already do in C++ and Java, etc. In C++, there's nothing to stop you declaring everything in a class public - which is what a struct is in C++.

The merits of why this is better can be debated, but just because he learnt it one way and never considered the alternative until he came across Go is a poor excuse.

Another example of Go’s modernity is the decision to make the directory the fundamental unit of packaging.


Java does this already.

For example, they straightened out the confusing mess of longs and shorts that had accumulated over thirty years with straightforward names: int8, int16, int32, and int64. There are also unsigned variants (uint8, etc.).


I quite like LLVM's IR for integers. i8, i16, i32 etc.

And what’s up with all the languages that claim all you need are linked lists? I’m sorry, this is not 1958, and you are not John McCarthy.


John McCarthy used lists, but the implementation need not be linked lists. Most LISPs these days don't claim "list only". Even with the traditional LISP list structure, you're not actually limited to linked lists. The ability to create trees with cons cells was realized early.

Reply Score: 4

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 UTC 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 Score: 4

RE[2]: Meh
by moondevil on Tue 12th Feb 2013 08:40 UTC 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 Score: 3

RE[3]: Meh
by satsujinka on Tue 12th Feb 2013 17:30 UTC in reply to "RE[2]: Meh"
satsujinka Member since:
2010-03-11

As I said, I keep meaning to get around to looking at D, but safe by default and meta-programming aren't things that are new to me (so there's not really much motivation to learn.)

Of the things you listed for Rust, sum types are really the only thing I miss in Go... and it's hardly worth learning a language for a feature that can be found better elsewhere.

Really, I only learned Go because of it's built in co-routine syntax. I felt it was as good of a place as any to really buckle down on concurrency (since I don't have to do much/any in my day job.)

Reply Score: 2

RE[4]: Meh
by shmerl on Tue 12th Feb 2013 17:55 UTC in reply to "RE[3]: Meh"
shmerl Member since:
2010-06-08

Rust is more flexible than Go, since it gives an option to manage memory when needed.

Reply Score: 2

RE[5]: Meh
by satsujinka on Tue 12th Feb 2013 18:07 UTC in reply to "RE[4]: Meh"
satsujinka Member since:
2010-03-11

That's fine, but it's not a feature that's unique to Rust. So that's not really going to motivate me.

Edited 2013-02-12 18:13 UTC

Reply Score: 2

RE[2]: Meh
by Jondice on Tue 12th Feb 2013 13:25 UTC 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 Score: 5

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

I have been following it for a while as well. ;)

My strong points in the university were distributed computing and compiler design.

As such I try to keep up with research on programming languages.

Reply Score: 2

RE[3]: Meh
by satsujinka on Tue 12th Feb 2013 17:23 UTC in reply to "RE[2]: Meh"
satsujinka Member since:
2010-03-11

I've started perusing ATS' tutorials but like you I also had syntax issues.

Reply Score: 2

RE[3]: Meh
by vivainio on Tue 12th Feb 2013 19:39 UTC in reply to "RE[2]: Meh"
vivainio Member since:
2008-12-26

By your description, ATS seems like pretty much an opposite of Go, philosophically. Go aims to be pragmatic above all.

Reply Score: 3

RE[4]: Meh
by Jondice on Tue 12th Feb 2013 20:09 UTC in reply to "RE[3]: Meh"
Jondice Member since:
2006-09-20

I think that ATS may be pragmatic, especially in kernel land or "mission critical" code, sort of like a new spin on . Go is probably not the best comparison; I was posting that as a followup on a comment about Rust, D, and C++. More apt would perhaps be as a functional alternative to Ada+SPARK, though my initial impression is that it would have many improvements on these in the way of proof facilities and type system flexibility. But, that's just my impression ... I'm certainly no expert.

Reply Score: 3

RE: Meh
by vivainio on Tue 12th Feb 2013 11:09 UTC 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 Score: 2

RE[2]: Meh
by moondevil on Tue 12th Feb 2013 12:45 UTC 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 Score: 2

My thoughts on Go
by Nelson on Tue 12th Feb 2013 08:25 UTC
Nelson
Member since:
2005-11-29

Syntax:
Very thoughtful and concise, a breath of fresh air from a lot of other languages. At first it seemed confusing but over time I've come to appreciate it.

Read left to right and having the variable be described exactly as read is valuable.

Exceptions:
This is an egregious omission. While it is true that Exceptions encourage bad devs from making non-exceptional situations exceptional, the problem is that it isn't black and white.

My method X may be perfectly fine with accepting a null reference, it may even have a specific code path for dealing with it.

Method Y may fail fast when taking a null because there isn't much it can do with it. It wouldn't make sense to try.

Therefore it is at the discretion of the programmer to decide which instances call for an exceptional situation and which don't.

Defer/Panic/Recover are Try/Catch/Finally/Using in an almost comically worse syntax.

Exceptions are also about proving the end user context at run time to perform corrective action and fix the state to potentially try and recover. Error codes or multi return values on their own don't convey this information.

Goroutines / Channels:
I'm not sure I like this as much as I like async/await operations in C# using the TPL. It seems like a much more natural fit to the language without resorting to channels. I'm not sure I like Goroutine isolation.

I'm not really a fan of blocking to receive from a channel when it is all asynchronous in C# and fits elegantly with the language in the form of return values being coerced from Futures.

consider:


public async Task<int> GetNumberAsync()
{
return 42;
}


it is clear to see the GetNumberAsync() is an asynchronous operation that returns 42 (which may or may not happen immediately)

when I do

var result = await GetNumberAsync();


all the code following this statement gets spun off as a continuation of this operation and the current method returns immediately.

To me it makes async code much less of a disjointed experience when writing it in a sequential fashion. Imagine a chain of awaits in C# vs trying to get a bunch of Goroutines to understand each other via channels that have a non trivial cost.

Still, the intention is a good one. Get people to stop thinking about threads, cores, and pools and start thinking on a higher level. I wonder how their Task (or Goroutine) scheduler compares to the Work stealing task scheduler in .NET

Pointers:
Love the lack of pointer arithmetic. Smart move and +1 for safety.

Overall my problem with Go is that it is just one solution to a multi-faceted problem. Its hard to for example promote asynchrony when you need to maintain support for things like the STD C Lib which destroys the advantages of async code (making async code behave like sync code kills any gains, and degrades perf) and in addition to this, Go requires an IDE effort to make it productive.

I'm a fan of their simplified inheritance model, but you need IDE support to make up for the difference in productivity that's provided out of the box. Its hard at a glance to know which types implement which given interfaces.

It'd probably be worth while for them to do something like explicit interface declarations where a class can explicitly state to support an interface and it can be checked in much the same manner they currently do. What they have now seems to be an inference based inheritance model

Edited 2013-02-12 08:26 UTC

Reply Score: 4

RE: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 17:33 UTC in reply to "My thoughts on Go"
satsujinka Member since:
2010-03-11

I'm curious why you feel you need an IDE? Go has been perfectly fine in most editors in my experience.

Reply Score: 2

RE[2]: My thoughts on Go
by Nelson on Tue 12th Feb 2013 18:12 UTC in reply to "RE: My thoughts on Go"
Nelson Member since:
2005-11-29

The language doesn't inherently afford you a lot of the expressiveness of other OO languages in their object model. You can't for example, at a glance, tell which interfaces a given "object" (as loose as the term is used in Go) implements.

That's where I think an IDE and the language can split the difference and make up for that. There are other small instances too like the fact that IDEs can help remove the stigma surrounding some of the more exotic syntax choices. That's valuable too.

it is my belief that a programming language is nothing without the tooling, a complete stack from beginning to end.

Reply Score: 3

RE[3]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 18:15 UTC in reply to "RE[2]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Ah, I suppose we'll have to agree to disagree. While IDEs can be important, I feel a language should stand on its own. Which I feel Go does fine on.

Reply Score: 3

RE[4]: My thoughts on Go
by lucas_maximus on Tue 12th Feb 2013 18:22 UTC in reply to "RE[3]: My thoughts on Go"
lucas_maximus Member since:
2009-08-18

I don't think it does in the first few paragraphs I knew I would absolutely hate it.

Silly implied naming conventions, lack of proper encapsulation just turned me straight off.

Edited 2013-02-12 18:23 UTC

Reply Score: 3

RE[5]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 18:29 UTC in reply to "RE[4]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Personal preferences are bound to differ, but I do write Go in a regular text editor... so take that as you will.

Reply Score: 2

RE[6]: My thoughts on Go
by lucas_maximus on Tue 12th Feb 2013 19:19 UTC in reply to "RE[5]: My thoughts on Go"
lucas_maximus Member since:
2009-08-18

I think my personal preferences are actually important as they are pretty basic criticisms. Which the article basically addresses with "haters will be haters".

While you might be able to write code without an IDE.

I wonder how writing a project would work with Go, with the accessibility modifiers down to the naming convention. While I like naming conventions I do think code should be blindingly obvious to read.

I find it difficult enough (I don't have TFS access to force naming convention conformance ... yet) to get 4 devs to use the same naming conventions.

Maybe Go isn't meant for this, but then I wonder who its target audience is then?

Edited 2013-02-12 19:20 UTC

Reply Score: 3

RE[7]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 19:29 UTC in reply to "RE[6]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Previously you hadn't given me much to work with (i.e. what silly naming convention,) but now I think I can actually address your points.

So for starters, it's not really a naming convention. If someone doesn't uppercase their functions/variables/etc. then it's unavailable. You don't really have a choice in the matter, it must be capitalized if you want to use it. (which makes it not a naming convention since there's no choice in the matter.)

So since it's a requirement it quickly becomes very obvious whether something is available or not. This maybe takes some getting used to since caps in other languages are ignored.

As far as I can tell, the Go community doesn't have any issue with it (even on projects) so it doesn't seem like this is a big deal.

Reply Score: 3

RE[7]: My thoughts on Go
by Alfman on Tue 12th Feb 2013 19:35 UTC in reply to "RE[6]: My thoughts on Go"
Alfman Member since:
2011-01-28

lucas_maximus,

"I think my personal preferences are actually important as they are pretty basic criticisms. Which the article basically addresses with 'haters will be haters'"

Your absolutely right, the author attempts to deflect criticism with immature ad-hominem quotes like the following.

"Controversial with [Internet controversialists]. People who complain about this are complainers. Features like this are useful because they let you know who likes to complain about things for no good reason. Go has a lot of features like this."

I find the attitude unfortunate because it seems to detract from an otherwise reasonable overview of the language.

Reply Score: 3

RE[4]: My thoughts on Go
by Nelson on Tue 12th Feb 2013 18:57 UTC in reply to "RE[3]: My thoughts on Go"
Nelson Member since:
2005-11-29

Don't get me wrong, I love Go and I think it does stand on its own, and while it has weaknesses, it also has clear advantages, in a neat simple little package.

Go is simple. The compilers are simple to deploy and cross compiler. The inheritance story is dead simple. They seem to be carefully planning out design before throwing in features willy nilly (Generics, Exceptions, etc.) .

I just think it'd be augmented by an IDE. Without one its still perfectly usable, these are just nit picks.

Reply Score: 3

RE[5]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 19:04 UTC in reply to "RE[4]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Ah, yes then I suppose we agree. I read your previous post as "Go isn't very good without an IDE"

Reply Score: 2

RE[6]: My thoughts on Go
by Nelson on Tue 12th Feb 2013 19:28 UTC in reply to "RE[5]: My thoughts on Go"
Nelson Member since:
2005-11-29

That's my fault, I tend to be rather hyperbolic.

Reply Score: 2

RE[2]: My thoughts on Go
by moondevil on Tue 12th Feb 2013 20:20 UTC in reply to "RE: My thoughts on Go"
moondevil Member since:
2005-07-08

I'm curious why you feel you need an IDE? Go has been perfectly fine in most editors in my experience.



For example, list all the interfaces the following type does support:

type Example struct {
afield int
}

func (e *Example) MyMethod () int {
}

Without the help of a tool that searches all visible interfaces and checks if Example fullfils the required set of methods, it is not possible by reading the code to know which set of interfaces are supported by Example.

Reply Score: 3

RE[3]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 20:40 UTC in reply to "RE[2]: My thoughts on Go"
satsujinka Member since:
2010-03-11

You don't need to know all the interfaces Example implements. You just have to know what the interface you're using requires and if your object has it.

In other words, you're looking at the code backwards compared to how Go works. Which may be an issue if ideal mental models of Go end up being backwards compared to other languages.

Reply Score: 3

RE[4]: My thoughts on Go
by moondevil on Tue 12th Feb 2013 20:59 UTC in reply to "RE[3]: My thoughts on Go"
moondevil Member since:
2005-07-08

You don't need to know all the interfaces Example implements. You just have to know what the interface you're using requires and if your object has it.


How do you do it without reading the full code that relates to Example struct, specially if it happens to be scattered across multiple files?

The solution proposed in multiple discussions in gonuts is to try to compile and see if it works and fix missing methods as required. Very helpful.

Reply Score: 2

RE[5]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 21:09 UTC in reply to "RE[4]: My thoughts on Go"
satsujinka Member since:
2010-03-11

All of Example's methods have to be in the same package as Example. Ideally, Example should be in its own package. Ideally, an object shouldn't require more than 1 file to specify. Ideally, there should be some documentation.

So bad architecture/design choices aside... There's no reason a grep can't take care of this, but it's usually just as fast to compile (and it gives better information.)

Besides, you don't have to read all the code. You can easily pick up Example's methods by scanning function declarations.

The design choice of inferring interfaces is a sound one. It allows you to add/remove/restructure interfaces without having to modify your objects. Yes, you have to remember more or get an IDE, but it makes life much easier, especially in the prototyping stages of development when interfaces aren't yet stable.

Reply Score: 2

RE[6]: My thoughts on Go
by moondevil on Tue 12th Feb 2013 21:26 UTC in reply to "RE[5]: My thoughts on Go"
moondevil Member since:
2005-07-08

You sound like you never did code development on enterprise level reading code developed by people all across the world.

Those advices only work if you're developing on your own or a very small set of developers.

Reply Score: 2

RE[7]: My thoughts on Go
by siride on Wed 13th Feb 2013 04:18 UTC in reply to "RE[6]: My thoughts on Go"
siride Member since:
2006-01-02

Exactly. These people who say that IDEs are useless have never really used them, nor worked on very large projects.

Sure, you can do most everything you can do in an IDE without an IDE. And you can write assembly instead of C, or machine language in a hex editor if you want to. You can use Perl scripts to spelunk through code and produce static reference listings. If you want to...

But I want to get work done. And I like being able to jump around my code with keyboard shortcuts that are only made possible because the editor/tool I'm using actually understands the structure of my project and the language I'm coding in (beyond basic syntax highlighting). And I like being able to step through code while looking at the project in the same tool I develop it in, instead of using esoteric commands in a command line-only tool that show you very little context at any given point in time. Sure, you can do it...but why when there are better tools? Use the right tool for the job.

Reply Score: 2

RE[7]: My thoughts on Go
by satsujinka on Wed 13th Feb 2013 10:14 UTC in reply to "RE[6]: My thoughts on Go"
satsujinka Member since:
2010-03-11

On the contrary that's exactly what I get paid for.

I would appreciate it if you don't try to undermine my credibility when all I've done is answer your questions.

Reply Score: 2

RE[6]: My thoughts on Go
by lucas_maximus on Wed 13th Feb 2013 16:35 UTC in reply to "RE[5]: My thoughts on Go"
lucas_maximus Member since:
2009-08-18

All of Example's methods have to be in the same package as Example. Ideally, Example should be in its own package. Ideally, an object shouldn't require more than 1 file to specify. Ideally, there should be some documentation.

So bad architecture/design choices aside... There's no reason a grep can't take care of this, but it's usually just as fast to compile (and it gives better information.)


Bad architecture will always exists, this is because not all developers are created equal.

Besides, you don't have to read all the code. You can easily pick up Example's methods by scanning function declarations.


Or you can just look at the top of the file for something like "implements".

The design choice of inferring interfaces is a sound one. It allows you to add/remove/restructure interfaces without having to modify your objects. Yes, you have to remember more or get an IDE, but it makes life much easier, especially in the prototyping stages of development when interfaces aren't yet stable.


You do know how tools like rename work in IDEs don't you?

It makes this benefit moot.

Edited 2013-02-13 16:40 UTC

Reply Score: 2

RE[7]: My thoughts on Go
by satsujinka on Wed 13th Feb 2013 19:30 UTC in reply to "RE[6]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Rename still isn't as flexible.

For example, in Go if you are using someone else's objects, you can still create interfaces that those objects implement, without needing to modify those objects (you don't even need their source code.)

Reply Score: 2

Cross-compiling
by Laurence on Tue 12th Feb 2013 12:37 UTC
Laurence
Member since:
2007-03-26

I'd like to add something that's not already been commented on:

Go is a dream to cross compile with. eg I can write a program on x86 Windows, test it and then compile it for a Linux ARMv6, still on the Windows PC, and just copy the ELF over. No code modifications what-so-ever.

I know this can all be done in C++ and scripting languages as well. But Go makes the process significantly easier than C++ (in regards to the more complicated programs), with significantly less code than Java and compiles unlike scripting languages.

So while Go isn't perfect, it offers me the best balance between writing speedy code and having quick run times. Go is now my "minimum fuss" language.

Edited 2013-02-12 12:41 UTC

Reply Score: 5

RE: Cross-compiling
by moondevil on Tue 12th Feb 2013 12:47 UTC in reply to "Cross-compiling"
moondevil Member since:
2005-07-08

Go is a dream to cross compile with. eg I can write a program on x86 Windows, test it and then compile it for a Linux ARMv6, still on the Windows PC, and just copy the ELF over. No code modifications what-so-ever.


This is only possible if you restrict yourself to the base library and Go pure code.

This is nothing new, cross-compiling exists since the dawn of computing.

Reply Score: 3

RE[2]: Cross-compiling
by Laurence on Tue 12th Feb 2013 14:10 UTC in reply to "RE: Cross-compiling"
Laurence Member since:
2007-03-26

I really wish people would read before arguing...

This is only possible if you restrict yourself to the base library and Go pure code.

Yet that's exactly what the context of this thread is about. We're not talking about some imaginary examples of Go which break convention; we're talking about Go code written as Go code is designed. And that means using non-OS specific API calls in the base to build extended non-OS specific Go libraries.

Go is designed with portability in mind. C++ wasn't. So while C++ can be portable, it's much easier to write portable code in Go.


This is nothing new, cross-compiling exists since the dawn of computing.

Thank you for telling me what I'd already categorically stated in my post.

My point was Go makes the process much less painful, not that it's the only language to have ever supported cross-compiling.



These days you can do pretty much anything in pretty any language. So the choice of language boils down to productivity (time spent coding, compiling, porting, etc) vs performance (raw execution speed, memory usage, etc) and sometimes even performance is a non-issue. So my point was this: Go enhances productivity. Which is why it's my new go-to language.

Edited 2013-02-12 14:20 UTC

Reply Score: 5

RE[3]: Cross-compiling
by Alfman on Tue 12th Feb 2013 18:17 UTC in reply to "RE[2]: Cross-compiling"
Alfman Member since:
2011-01-28

"Go is designed with portability in mind. C++ wasn't. So while C++ can be portable, it's much easier to write portable code in Go."

I actually agree with moondevil's point. While the c++ ecosystem is filled with tons of incompatible libraries/frameworks across tons of platforms, the c++ language itself doesn't impose significant portability issues, in fact it's highly portable. I think you ought to be blaming the C++ frameworks for portability issues rather than the C++ language itself.

Now in the end this difference may be mute because we really do need the C++ frameworks in practice, but I think it's important to recognize because without a central authority for coordination of one common framework, all languages have the potential to devolve into the situation C++ finds itself in with incompatible local frameworks. I can see it now: "microsoft foundation classes for Go", haha.



Personal anecdote:
Even the JDK, with the most portable framework I've ever used, wasn't perfect. For a university project we were using java to control serial ports connected to early bluetooth prototypes. The JDK worked perfectly from windows, but we needed to adopt a custom serial port driver for spark workstations (oh delicious irony).

Reply Score: 3

RE[4]: Cross-compiling
by lucas_maximus on Tue 12th Feb 2013 18:29 UTC in reply to "RE[3]: Cross-compiling"
lucas_maximus Member since:
2009-08-18

I did a bit of work with OpenBabel for my dissertation (I made a very simple Java app) and was going to release it open source (probably a "do what you f--king want license") with a few bug fixes and a general code clean-up.

The JNI interface was a PITA to link up on Linux and I didn't even attempt it on OpenBSD. The Java interface was generated by SWIG bindings and they were totally different to the Windows versions. It might have been something to do with SWIG but I just gave up there as I was just going to spend maybe an afternoon getting a decent release.

(There was only a few thousand lines of code, and most of it was pretty decent other than some novice mistakes I made at the time).

In the end it bit-rotting in my dropbox. I think I might build a swing front end for it and stick it up on my personal site for anyone who wishes to use it on the OpenBabel google group and if they are inclined they can port it to another OS themselves. I don't really have the time, nor the inclination.

Edited 2013-02-12 18:33 UTC

Reply Score: 2

RE[4]: Cross-compiling
by Laurence on Tue 12th Feb 2013 18:35 UTC in reply to "RE[3]: Cross-compiling"
Laurence Member since:
2007-03-26


I actually agree with moondevil's point. While the c++ ecosystem is filled with tons of incompatible libraries/frameworks across tons of platforms, the c++ language itself doesn't impose significant portability issues, in fact it's highly portable. I think you ought to be blaming the C++ frameworks for portability issues rather than the C++ language itself.

I appreciate what you're saying, but these days frameworks are as integral part of the language as the language itself. eg what would be the point of C# if it wasn't for .NET? Or Java if it wasn't for JRE? Or even Python if it wasn't for it's modules?

I genuinely do like C++ - I'm not trying to argue that one language is a "better" language than the other. But it is fair to say that because of the core frameworks and because of the Go compiler, Go is an easier language to port.

Now in the end this difference may be mute because we really do need the C++ frameworks in practice, but I think it's important to recognize because without a central authority for coordination of one common framework, all languages have the potential to devolve into the situation C++ finds itself in with incompatible local frameworks. I can see it now: "microsoft foundation classes for Go", haha.

That's a very interesting point. We do see this problem in some other languages as well.


Personal anecdote:
Even the JDK, with the most portable framework I've ever used, wasn't perfect. For a university project we were using java to control serial ports connected to early bluetooth prototypes. The JDK worked perfectly from windows, but we needed to adopt a custom serial port driver for spark workstations (oh delicious irony).

hehehe interesting stuff ;)

I'm not a fan of Java personally (to be frank, it's the language I hate the most). But that boils down to personal more than anything. "each to their own" as they say hehe

Reply Score: 3

RE[5]: Cross-compiling
by Alfman on Tue 12th Feb 2013 19:07 UTC in reply to "RE[4]: Cross-compiling"
Alfman Member since:
2011-01-28

Laurence,

"I appreciate what you're saying, but these days frameworks are as integral part of the language as the language itself. eg what would be the point of C# if it wasn't for .NET? Or Java if it wasn't for JRE? Or even Python if it wasn't for it's modules?"

True, Go is young and has a beautiful framework now, but what about in a few years? After "getting around" and putting on a few pounds, she might start to look like grandma Perl ;)

Exaggerated a tad for comedic effect. The following link makes me laugh and cry simultaneously...
http://www.perl.com/pub/2003/03/13/datetime.html#perl%27s_built...

Reply Score: 2

RE[6]: Cross-compiling
by Laurence on Wed 13th Feb 2013 09:59 UTC in reply to "RE[5]: Cross-compiling"
Laurence Member since:
2007-03-26

hehe Perl is actually one of my favourite languages.

I guess at the end of the day, no language is perfect and only as powerful as the developer. eg I used to dismiss Javascript as a a toy until one clever developer built a Linux virtual machine[1] with it - which is far more sophisticated than anything I've ever done in C++.

[1] http://bellard.org/jslinux/

Edited 2013-02-13 09:59 UTC

Reply Score: 2

RE[7]: Cross-compiling
by Alfman on Wed 13th Feb 2013 16:12 UTC in reply to "RE[6]: Cross-compiling"
Alfman Member since:
2011-01-28

Laurence,

In this sense all languages are equal because they're all turing complete. I find javascript is quite a good language but often times it's used in contexts it really isn't very well suited for because it's the only language available. The document object model has alot of evolutionary baggage and it's virtually impossible to optimize for native performance, but we are stuck with it in the foreseeable future.

I liked perl as well, after all it is the gold standard for regular expressions and fundamentally incorporates IO in novel ways. I prefer it infinitely over bash shell scripting (UGH). But the number of competing frameworks/libraries in CPAN (117K) is overwhelming, consequently perl code is many times more fragmented than C++. I like CPAN's moto though "Stop reinventing wheels, start building space rockets". I wonder if it's meant sarcastically because the horse has already left the stable a long, long time ago.

Reply Score: 2

A solution in search of a problem
by FunkyELF on Tue 12th Feb 2013 14:31 UTC
FunkyELF
Member since:
2006-07-26

It seemed that fast compilation times was a goal of the language. If it was a side effect, then great, but I think they were trying to address a problem that nobody really had.

I'm upset that Google abandoned the Unladen Swallow project to make Python faster and integrate LLVM. Had their new Go language targeted LLVM I'd be less upset.

Reply Score: 4

Valhalla Member since:
2006-01-24

It seemed that fast compilation times was a goal of the language. If it was a side effect, then great, but I think they were trying to address a problem that nobody really had.

Actually I recall the Go authors stating that indeed compilation speed was an issue for them in their large C++ projects at Google which made it a focus for Go.

Had their new Go language targeted LLVM I'd be less upset.

Ehh, why would it matter? Anyway, the Go devs looked at both GCC and LLVM as backends but found them both too large and slow and instead wrote the Go compiler from scratch.

There is GCCGo which I suppose is largely a stopgap solution to offer better optimization and support a larger range of architectures while the official toolchain matures.

Reply Score: 2