[go-nuts] Re: My views on Go and why it's better than Scripting
> 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 >``` Since I wanted the best of both interactive data exploration and statically compiled Go, I made the Go interpreter https://github.com/gijit/gi Your students could use it to learn Go interactively at the REPL. Type errors like the example above will be caught: ``` $ *gi -q* gi> *a := 1.0* elapsed: '121.083µs' gi> *a = "a"* oops: 'problem detected during Go static type checking: 'where error? err = '1:5: cannot convert "a" (untyped string constant) to float64''' on input 'a = "a"' gi> ``` -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
My statement earlier is wrong: The Go 1 compatibility approach may be worth mentioning: programs written > in 2009 will still work in 2019 with the state of the art compiler. Go 1 was actually 2012, not 2009. Also Go 2 may start at some point soon, so maybe "programs written in 2012 will still work through at least early 2018 with the state of the art compiler" is closer to correct. Matt On Saturday, March 3, 2018 at 4:19:41 PM UTC-6, matthe...@gmail.com wrote: > > I like Go because it improves on C for engineers in almost every way and > avoids classes, and, at least today, if you have a problem then it will be > solved quickly by the people following the GitHub issue tracker and > contributing to the source code. > > Go avoids complexities such as generics (aka templates) usually available >> in other languages (e.g., C++). > > > This may be a temporary state, a major Go 2 discussion is about adding > generics (https://github.com/golang/go/issues/15292). > > The Go 1 compatibility approach may be worth mentioning: programs written > in 2009 will still work in 2019 with the state of the art compiler. > > Select, channels, goroutines, methods, interface, closures, function > types, and map may be worth mentioning. > > For me seeing a small (<100 lines of code) application more complex than > "Hello, world!" written in other languages then in idiomatic Go would help > drive the point. > > There is hence no need for constantly worrying about `by reference` or `by >> value`. > > > This is actually a tough part of Go when deciding how to define methods > (by pointer or by value), but at least there’s no pointer arithmetic. > > Matt > > On Saturday, March 3, 2018 at 7:56:41 AM UTC-6, Alex Rice wrote: >> >> Hi, thanks for sharing. I am not convinced about the reasons stated why >> Go is better than the other languages you mentioned. I am just learning Go, >> but I have 20 years of experience as a professional developer using various >> languages. I think students, beginners and professionals should use Go >> because of it's developer-first attitude. Ergonomics, I've heard it said. >> >> * productivity >> * enjoyment >> * nice workflow and development tools >> * unix philosophy of small chain-able tools >> >> The lissajous example in the the gopl.io [1] book is a great example. In >> ~50 lines of code, there is a generator of animated gifs of harmonic motion >> curves, which it serves up on http, or write to standard out. How many >> lines of code would the same thing be in C, or in Python? I suspect more >> LOC, and I suspect 3rd party libraries would be involved. >> >> 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go >> >> Cheers, >> Alex >> >> -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
Thanks for sharing your experience! On Tuesday, March 6, 2018 at 4:46:54 PM UTC-8, Rich wrote: > > I am a systems administrator. I find it easier and faster to write a > program in Go than it is to script it in Bash. Since writing scripts is > something most Sys Admins do I've had to write them in Perl, PHP, TCL, > Ruby, etc. and the BIGGEST frustration is that I would get a script written > debugged etc. and I'd go to deploy it to the server. The server doesn't > use the right version, or doesn't have the right package installed, and > hours of additional work are done to get your script to work. On a > production server installing one binary for something like a Nagios alarm I > can get away with on a production system, I can't just go and start > apt-getting or yum installing a bunch of new packages. With Go I install > the dependancies on MY system -- and that system is a Mac. Cross compiling > is trivial (unless the package it used CGO), and I normally generate code > that will run on Windows, Linux, Mac and the 32 / 64 bit variations, and I > can copy that one binary on to the system. No DLLs, no installing extra > packages, it just runs, no dependency or version headaches. > > On Friday, March 2, 2018 at 4:29:45 PM UTC-5, dorival...@gmail.com wrote: >> >> Hi, I could be wrong (please correct me ;-), but here you are what I >> think about Go: >> >> ... >> > -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
I am a systems administrator. I find it easier and faster to write a
program in Go than it is to script it in Bash. Since writing scripts is
something most Sys Admins do I've had to write them in Perl, PHP, TCL,
Ruby, etc. and the BIGGEST frustration is that I would get a script written
debugged etc. and I'd go to deploy it to the server. The server doesn't
use the right version, or doesn't have the right package installed, and
hours of additional work are done to get your script to work. On a
production server installing one binary for something like a Nagios alarm I
can get away with on a production system, I can't just go and start
apt-getting or yum installing a bunch of new packages. With Go I install
the dependancies on MY system -- and that system is a Mac. Cross compiling
is trivial (unless the package it used CGO), and I normally generate code
that will run on Windows, Linux, Mac and the 32 / 64 bit variations, and I
can copy that one binary on to the system. No DLLs, no installing extra
packages, it just runs, no dependency or version headaches.
On Friday, March 2, 2018 at 4:29:45 PM UTC-5, dorival...@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
[go-nuts] Re: My views on Go and why it's better than Scripting
Great feedback, Matt and Wang. Thanks and Cheers!
On Monday, March 5, 2018 at 2:13:29 AM UTC-8, Wang Sheng wrote:
>
> I am c++/C expert, I like because it is easier than C++ and more powerful
> and flexible than C
> with Golang , you would not need consider create/destroy/monitor pthread
> , crazy pointer is not problem also .
> as far as I know , most of golanger is original user of C/C++
>
>
>
> 在 2018年3月3日星期六 UTC+8上午5:29:45，dorival...@gmail.com写道：
>>
>> 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`
[go-nuts] Re: My views on Go and why it's better than Scripting
I am c++/C expert, I like because it is easier than C++ and more powerful
and flexible than C
with Golang , you would not need consider create/destroy/monitor pthread
, crazy pointer is not problem also .
as far as I know , most of golanger is original user of C/C++
在 2018年3月3日星期六 UTC+8上午5:29:45，dorival...@gmail.com写道：
>
> 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
[go-nuts] Re: My views on Go and why it's better than Scripting
I like Go because it improves on C for engineers in almost every way and avoids classes, and, at least today, if you have a problem then it will be solved quickly by the people following the GitHub issue tracker and contributing to the source code. Go avoids complexities such as generics (aka templates) usually available > in other languages (e.g., C++). This may be a temporary state, a major Go 2 discussion is about adding generics (https://github.com/golang/go/issues/15292). The Go 1 compatibility approach may be worth mentioning: programs written in 2009 will still work in 2019 with the state of the art compiler. Select, channels, goroutines, methods, interface, closures, function types, and map may be worth mentioning. For me seeing a small (<100 lines of code) application more complex than "Hello, world!" written in other languages then in idiomatic Go would help drive the point. There is hence no need for constantly worrying about `by reference` or `by > value`. This is actually a tough part of Go when deciding how to define methods (by pointer or by value), but at least there’s no pointer arithmetic. Matt On Saturday, March 3, 2018 at 7:56:41 AM UTC-6, Alex Rice wrote: > > Hi, thanks for sharing. I am not convinced about the reasons stated why Go > is better than the other languages you mentioned. I am just learning Go, > but I have 20 years of experience as a professional developer using various > languages. I think students, beginners and professionals should use Go > because of it's developer-first attitude. Ergonomics, I've heard it said. > > * productivity > * enjoyment > * nice workflow and development tools > * unix philosophy of small chain-able tools > > The lissajous example in the the gopl.io [1] book is a great example. In > ~50 lines of code, there is a generator of animated gifs of harmonic motion > curves, which it serves up on http, or write to standard out. How many > lines of code would the same thing be in C, or in Python? I suspect more > LOC, and I suspect 3rd party libraries would be involved. > > 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go > > Cheers, > Alex > > -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
Thanks for your suggestions! On Saturday, March 3, 2018 at 5:56:41 AM UTC-8, Alex Rice wrote: > > Hi, thanks for sharing. I am not convinced about the reasons stated why Go > is better than the other languages you mentioned. I am just learning Go, > but I have 20 years of experience as a professional developer using various > languages. I think students, beginners and professionals should use Go > because of it's developer-first attitude. Ergonomics, I've heard it said. > > * productivity > * enjoyment > * nice workflow and development tools > * unix philosophy of small chain-able tools > > The lissajous example in the the gopl.io [1] book is a great example. In > ~50 lines of code, there is a generator of animated gifs of harmonic motion > curves, which it serves up on http, or write to standard out. How many > lines of code would the same thing be in C, or in Python? I suspect more > LOC, and I suspect 3rd party libraries would be involved. > > 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go > > Cheers, > Alex > > -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
Hi, thanks for sharing. I am not convinced about the reasons stated why Go is better than the other languages you mentioned. I am just learning Go, but I have 20 years of experience as a professional developer using various languages. I think students, beginners and professionals should use Go because of it's developer-first attitude. Ergonomics, I've heard it said. * productivity * enjoyment * nice workflow and development tools * unix philosophy of small chain-able tools The lissajous example in the the gopl.io [1] book is a great example. In ~50 lines of code, there is a generator of animated gifs of harmonic motion curves, which it serves up on http, or write to standard out. How many lines of code would the same thing be in C, or in Python? I suspect more LOC, and I suspect 3rd party libraries would be involved. 1. https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go Cheers, Alex -- 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.
[go-nuts] Re: My views on Go and why it's better than Scripting
Thanks for your suggestion!
To put it in context, I'm drafting a plan for my colleagues in order to
make a case for using Go in teaching instead of Fortran or C.
On Friday, March 2, 2018 at 1:29:45 PM UTC-8, dorival...@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
