This was essentially my thinking in choosing Go to write my
bioinformatics library in - mainly because much of our code will be
written and maintained by students, but we want good performance as
well.

Some of my thought about this are in this paper https://www.biorxiv.org
/content/early/2014/05/12/005033

Dan

On Fri, 2018-03-02 at 12:07 -0800, dorival.pedr...@gmail.com wrote:
> Hi, I could be wrong (please correct me ;-), but here you are what I
> think 
> about Go:
> 
> INTRODUCTION
> Computers and software were initially developed for scientific
> computing; 
> e.g., ALGOL and FORTRAN from the 1950s! Therefore, several computer 
> languages and libraries have been invented and are used in
> scientific 
> computing to date.  Nonetheless, when programming a new scientific 
> simulation, the question about computational efficiency versus ease-
> of-use 
> remains open. Here, we aim to shed light on a suitable answer to
> this 
> question---TL;DR use Go and Gosl!
> 
> One would say that scripting (interpreted) languages might provide
> the 
> convenient platform for computations as long as care is taken to
> send 
> intensive tasks to functions pre-compiled with high-performance
> languages. 
> This strategy fails to create an easy-to-use environment because the 
> programmer needs to think when and where those tasks should go.
> Considering 
> that this kind of decision is essential for performance, we argue
> that 
> scripting language is not the best solution.  Furthermore, we argue
> that 
> scripting is the worst tool for teaching new programmers in
> scientific 
> computing.
> 
> We argue that only experts should use scripting languages (scripts)
> for 
> computer programming because beginners cannot understand how
> dangerous the 
> flexibility of scripts can be. For example, the assignment of
> variables 
> with the same name to different types is often a cause of
> misunderstandings 
> and failures. To make this problem even worse, failures due to wrong
> types 
> are not captured at runtime---certainly not at compilation time
> (there is 
> no compilation time in scripts). In other words, the interpreter is
> too 
> permissive.  The scientist, if aware (rarely the case with students),
> will 
> investigate the numerical output and, after much work, will find the
> source 
> of the error. Therefore, this situation is not ideal. To exemplify,
> the 
> following is allowed in Python (or Julia---similar syntax):
> 
> ```
> a = 1.0
> a = "a" # OK in Python or Julia
> ```
> 
> In the following code, Go will detect the error with a message such
> as 
> `./test.go:5: cannot use "a" (type string) as type float64 in
> assignment`:
> 
> ```
> package main
> func main() {
>     a := 1.0
>     a = "a" // not accepted in Go
> }
> ```
> 
> The problem propagates in scripting languages when developing 
> objected-oriented code. For example, a member data of a class can be 
> entirely modified by `anyone`, `anywhere` in Python! This issue
> completely 
> defeats the purpose of encapsulation in OOP.
> 
> In summary, scripting (e.g., Python) and alike (e.g., Julia, Matlab) 
> languages are excellent for the expert programmer only who can
> understand 
> what is going on. However, they are very misleading to the beginner.
> In 
> other words, the strictness of compiled languages DOES help to learn 
> computer programming. Furthermore, the tools for working with
> compiled 
> language often take advantage of well-defined types. The shift
> towards type 
> declaration is so apparent that new languages and strategies are
> being 
> invented to overcome these issues. For example, TypeScript and
> Javascript 
> (ES6) combined with FlowType have been recently developed and have a
> fast 
> adoption among web developers. It seems that no new large project
> will use 
> non-typed Javascript code.
> 
> GO LANGUAGE
> Go is a modern programming language created by Google engineers in
> 2007, 
> including Robert Griesemer, Rob Pike, and Ken Thompson. The language
> was 
> later made public as open source in 2009. Go has since grown
> exponentially 
> attracting a large number of co-developers and users. The primary
> goal 
> leading to the introduction of yet a new language was the combination
> of 
> efficiency (like C/C++) with ease of development (like Python). There
> are 
> other several innovations and advantages in Go when compared with 
> mainstream languages such as C/C++/C#/Java/Python/Ruby/Lua. 
> Also, Go automatically detects Fortran and C files which helps
> taking 
> advantage of good existing code.
> 
> The vocabulary in Go is quite small compared to other languages,
> making 
> easy to have an overview of the syntax and available commands. Go
> avoids 
> complexities such as generics (aka templates) usually available in
> other 
> languages (e.g., C++). Go also tries to avoid unnecessary complexity
> by not 
> taking `in the language` advanced OOP concepts such as polymorphism, 
> multiple inheritances, and others. Moreover, Go is somewhat pragmatic
> in 
> the sense that, if an operation can be made much more
> straightforward, 
> although slightly orthogonal to the central paradigm, this operation
> will 
> be carefully defined and adopted in the language specification.
> These 
> features, thanks to the unquestionable expertise of the core
> developers, 
> made Go an enjoyable language to work with.
> 
> One limitation of some other languages is code organization and
> package 
> development. For example, C/C++ require the use of `#ifndef`,
> `#define`, 
> `#endif`, or `#pragma once` everywhere to prevent code being included
> more 
> than once. In fact, it is frustrating at times to find how to deal
> with 
> this situation in C/C++, noting that the developer has to worry about
> what 
> code goes in the header (.h, .hpp) or in the (.c, .cpp) files.
> Moreover, 
> the cyclic nature of `imports` using C/C++ can be a nightmare.
> 
> In Python, the organization of packages sometimes lead to situations
> where 
> the naming becomes very confusing. For example, we cite the case
> with 
> matplotlib.pyplot or pylab or other packages called
> mypackage.mypackage 
> that we find around. As another example, in Julia, module definition
> is 
> messy, because the user (programmer) has to decide among the files to
> be 
> included versus module definition. In summary, package definition is
> not 
> simple in Python or Julia.
> 
> On the other hand, Go was designed from the beginning to be multi-
> modular, 
> prevent cyclic dependency, and made package definition simple. In Go,
> the 
> solution is based on how the directories are organized. For example,
> each 
> directory is a package, and all files in the same directory belong to
> that 
> package. When importing code from other packages, the full path (like
> URL) 
> of that package is used. There is no need for `header` files in Go! 
> Moreover, the coding of one feature can span multiple files in the
> same 
> directory. Go comes with a set of tools to build applications and
> even 
> download third-party code.
> 
> Go also has a strict convention for code formatting. In other words,
> there 
> is only one way to format your code in Go---using braces starting at
> the 
> end of the line with the `standard` indentation. In this way, a true 
> `standard` exists for Go codes which makes sharing straightforward
> and 
> quite pleasant; e.g., no one argues about the positioning of braces 
> anymore! Moreover, the strict code convention and specification in
> Go 
> largely facilitates the development of auxiliary programming tools
> to 
> process code. For instance, the import field in source code can be 
> automatized as is done with the excellent goimports tool. Many other
> tools 
> (e.g., vet, lint) take advantage of Go conciseness.
> 
> Because files and directories in Go follow a well-defined
> specification, it 
> is very easy (and fast) to find definitions, code lines, files, and 
> packages (libraries) in Go projects. The compiler in Go benefits from
> this 
> organization and indeed helps with Go being very fast to compile
> code---you 
> can run Go code as if it was a scripting language! Furthermore, the 
> excellent specification and organization in Go helped with the
> creation of 
> many other tools to assist in Go code development.  For instance, we 
> mention the `goimports` and `gorename` that automatically import all 
> dependencies as you type and rename a variable in all code derived
> from a 
> particular library.
> 
> Furthermore, also thanks in part to how well the Go specification
> and 
> conciseness were invented, there are several other useful and fast
> commands 
> for handling Go code. For instance, we mention the commands `go run,`
> `go 
> build`, `go install` and `go get` that perform the operations of
> running 
> the code, building the code, installing the code and downloading
> (and 
> compiling) external dependencies automatically.
> 
> One particular innovation in Go is the concept of concurrency that
> can lead 
> to easy-to-write parallel algorithms. Also, Go is a garbage-
> collected 
> language that makes easier the code development with fewer worries
> about 
> dangling pointers. Go is in part compiled in Go language and has a 
> reasonably comprehensive standard library, including tools for
> sorting, 
> templating, encodings, cryptography, compression algorithms,
> mathematical 
> functions (e.g., for complex numbers), image tools, and even web
> servers. 
> Furthermore, Go uses the concept of unit tests very well and even
> includes 
> tools to assist in benchmarking. Also, Go comes with tools to
> prepare 
> examples and to automate the documentation---there is no need for
> Doxygen!
> 
> The Go language syntax resembles that of C/C++/Java (C-class) but
> has 
> significant differences. One fundamental difference is the way
> variables 
> are declared. The type definition comes after the variable name.
> This 
> difference seems strange at first to C-class programmers, but it
> makes 
> sense. In fact, it makes reading easy, where one would read `variable
> and 
> anotherVariable` are `float64` in `variable, anotherVariable 
> float64`---there is no need to type float64 twice (or ten times...).
> The 
> syntax is particularly convenient when declaring multiple function 
> arguments.
> 
> Go uses curly braces to define scope but has a strict rule regarding
> where 
> the braces can be put and how to deal with indentation. This approach
> makes 
> the code consistent and easy for collaborations.  Also, with the help
> of 
> the tools called `goimports` and `gofmt`, the workflow is
> straightforward. 
> Go allows some constructions similar to the `range` command in Python
> and 
> does not require the use of parentheses in repetition commands as in 
> C-class.
> 
> There is only one repetition command in Go: the `for` keyword.
> Compared to 
> C-class languages, the syntax of the `switch` command is simpler and
> more 
> powerful. Because of that, the programmer is induced (positively) to
> use 
> `switch` over `if` when there is more than one decision branch.
> 
> Go code can be directly executed as in: `go run hello.go`. The code
> could 
> be built first with `go build hello.go' and executed (Linux) with 
> `./hello`. But this last approach is only necessary when deploying
> the 
> final application. In fact, Go can be used as scripting (using `go
> run` 
> like `python`).
> 
> Variables are defined in two ways: the first one requires the command
> `var` 
> and the second one uses the assignment operator `:=` which
> automatically 
> understands the data type. Another great advantage of Go when
> compared to 
> many other languages is the standardized auto-initialization of all 
> variables to their `zero` default value. For instance, numeric
> variables 
> declared with `var` are always zero and strings are always empty.
> This 
> feature can be exploited with advantage by the programmer who may
> consider 
> variable names such that everything starts zeroed already. For
> instance, 
> instead of creating a `silent` variable that needs to be set to
> `true` all 
> the time, it's more convenient to use a `verbose` variable that is
> always 
> `false` already.
> 
> One type that is extensively used in Go is the `slice` of integers or
> real 
> numbers represented by float point numbers (64-bit version; aka
> `double` in 
> C-class). Slices in Go are a view to an internal sequence of values;
> i.e., 
> slices record the start and end positions in memory. Therefore,
> slices can 
> be passed into functions with minimal overhead. There is hence no
> need for 
> constantly worrying about `by reference` or `by value`. Pointers can
> also 
> be used in Go. We use pointers whenever a user-defined structure is
> to be 
> modified by the called function. In Go, the slice notation `S[s:E]`
> means a 
> view to array `S` starting at `s` and ending at `E-1`, inclusive.
> 
> In conclusion, code written in Go is beautiful, concise and with a
> very 
> clear logic.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to