3 ms·

So far I fail to understand the excitement with Go. Error handling in go feels like going back to 1960s programming. Garbage collection is already implemented

So far I fail to understand the excitement with Go. Error handling in go feels like going back to 1960s programming. Garbage collection is already implemented with high performance in Java and other platforms, what's new? You can use GC with different strategies in C++ as well, if you like, the libs are there. There are many libs to get dynamically managed memory in C. But the author wants to program for embedded devices and my choice there would be to avoid dynamically managed memory for the most part. Coroutines and tons of different concurrency and multiprogramming and parallelism paradigms and strategies are already available for most mainstream languages. Syntax in Go looks like a poorly done copy of Algol-68 (1968, and -surprisingly- a more powerful language.) Why? At least if they would have went with s-expression syntax, they would have enabled metaprogramming and this would have solved some of the problems with missing features. As for use in embeddable devices, the author discards D and other languages for lack of portability to other platforms; but AFAIK embedded devices programming goes to very low level details and thus I can't think how a code that is tied to the specific hardware would be portable, no matter what the language is. I thought Google had smarter language designers. At least Mozilla did a decent effort with Rust. Perhaps Google do have smarter engineers and they actually use Julia, Lisp, and Smalltalk for Google's internal projects...

jackmott 9y ago
Suppose I wanted a GC language that has the following properties: 1. I can compile it to a native executable as the normal workflow (i.e. not with constraints and special cases ala C# / Java ) 2. I can instantiate structs as pointers or value types at will. 3. High performance compiler available (gccgo) 4. Sufficiently large ecosystem for medium sized projects 5. Fast compilation times There aren't many choices there. There is Nim, which I like but still has rough edges. Maybe we can learn from Go that more people would like GC languages that don't require JITs, and give you some control of memory, and that we want this so bad we are willing to accept a rather bare bones language for these features. I would love to have something like ML with these features though.
masklinn 9y ago
> I thought Google had smarter language designers. They do, but you may be misunderstanding the purpose of Go for Google. It's to take recent untrusted grads and have them be quickly "productive" generating reviewable code. It's not an accident that Go's feels a lot like a somewhat improved and simplected Java (1), very much tuned towards network services.
koffiezet 9y ago
> Garbage collection is already implemented with high performance in Java and other platforms, what's new? A simple language that can be used for both 'scripting' projects and larger applications, natively, statically compiled, with a modern standard library aimed at what a lot of "ops" development is currently in need of. Hence the explosion of tools written in Go targeting that field. Maybe it's not suitable for your applications, but there is clearly a market for this. > but AFAIK embedded devices programming goes to very low level details and thus I can't think how a code that is tied to the specific hardware would be portable, no matter what the language is. That depends on the type of embedded stuff. I wrote a ton of embedded code targeting various embedded OS's on POS systems running m86k, MIPS, ARM and other stuff. I was responsible for designing and writing a generic hardware abstraction layer. It took considerable resources, but once streamlined, porting to another platform took about 3 months (if the hw and compiler/toolkit vendor were helpful, otherwise it could take years). It gave us the massive advantage of being able to develop/debug/showcase the application logic on a PC or on alternative hardware, and then finally target the real hardware when the HAL was finished and work out some kinks there, taking another month or so. So yes it's absolutely possible to write portable embedded code. > I thought Google had smarter language designers. At least Mozilla did a decent effort with Rust. Given the adoption rate of Go in the ops field, which incidentally is what Google needs a lot, I'd say they at least got something right.
earenndil 9y ago
> the author discards D and other languages for lack of portability to other platforms ...but it's very portable. It has llvm and gcc backends, supporting whatever platforms those support (all that you're likely to ever use), and it's possible to compile without runtime/gc, for a small enough footprint to run on embedded.
vram22 9y ago
>At least if they would have went with s-expression syntax, they would have enabled metaprogramming and this would have solved some of the problems with missing features. Interesting. Do you think having that syntax would help with developing generics for Go (a thing that I've read a lot of devs feel want to be there in it)?
kazinator 9y ago
> I thought Google had smarter language designers. Really? Knowing that it's the likes of Rob Pike or Ken Thompson? If you had told me ten years ago that these guys are going to make a language for Google, I'd have accurately predicted that it will be exactly the same sort of insipid blub that it is. They are not going to see very far outside of the C + UNIX box, and much of whatever they do see, they will have an allergic reaction against.

jackmott 9y ago

Suppose I wanted a GC language that has the following properties: 1. I can compile it to a native executable as the normal workflow (i.e. not with constraints and special cases ala C# / Java ) 2. I can instantiate structs as pointers or value types at will. 3. High performance compiler available (gccgo) 4. Sufficiently large ecosystem for medium sized projects 5. Fast compilation times There aren't many choices there. There is Nim, which I like but still has rough edges. Maybe we can learn from Go that more people would like GC languages that don't require JITs, and give you some control of memory, and that we want this so bad we are willing to accept a rather bare bones language for these features. I would love to have something like ML with these features though.

masklinn 9y ago

> I thought Google had smarter language designers. They do, but you may be misunderstanding the purpose of Go for Google. It's to take recent untrusted grads and have them be quickly "productive" generating reviewable code. It's not an accident that Go's feels a lot like a somewhat improved and simplected Java (1), very much tuned towards network services.

koffiezet 9y ago

> Garbage collection is already implemented with high performance in Java and other platforms, what's new? A simple language that can be used for both 'scripting' projects and larger applications, natively, statically compiled, with a modern standard library aimed at what a lot of "ops" development is currently in need of. Hence the explosion of tools written in Go targeting that field. Maybe it's not suitable for your applications, but there is clearly a market for this. > but AFAIK embedded devices programming goes to very low level details and thus I can't think how a code that is tied to the specific hardware would be portable, no matter what the language is. That depends on the type of embedded stuff. I wrote a ton of embedded code targeting various embedded OS's on POS systems running m86k, MIPS, ARM and other stuff. I was responsible for designing and writing a generic hardware abstraction layer. It took considerable resources, but once streamlined, porting to another platform took about 3 months (if the hw and compiler/toolkit vendor were helpful, otherwise it could take years). It gave us the massive advantage of being able to develop/debug/showcase the application logic on a PC or on alternative hardware, and then finally target the real hardware when the HAL was finished and work out some kinks there, taking another month or so. So yes it's absolutely possible to write portable embedded code. > I thought Google had smarter language designers. At least Mozilla did a decent effort with Rust. Given the adoption rate of Go in the ops field, which incidentally is what Google needs a lot, I'd say they at least got something right.

earenndil 9y ago

> the author discards D and other languages for lack of portability to other platforms ...but it's very portable. It has llvm and gcc backends, supporting whatever platforms those support (all that you're likely to ever use), and it's possible to compile without runtime/gc, for a small enough footprint to run on embedded.

vram22 9y ago

>At least if they would have went with s-expression syntax, they would have enabled metaprogramming and this would have solved some of the problems with missing features. Interesting. Do you think having that syntax would help with developing generics for Go (a thing that I've read a lot of devs feel want to be there in it)?

kazinator 9y ago

> I thought Google had smarter language designers. Really? Knowing that it's the likes of Rob Pike or Ken Thompson? If you had told me ten years ago that these guys are going to make a language for Google, I'd have accurately predicted that it will be exactly the same sort of insipid blub that it is. They are not going to see very far outside of the C + UNIX box, and much of whatever they do see, they will have an allergic reaction against.