11–20 of 330 posts
Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.
What's wrong with JVM?
Without a definition of "succeed", this cannot be argued against or agreed to. Like every other language, Go will be used by some people and not used by other people.
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.schem...
Go was designed to create low-level stuff with high-level language and it does not need features beyond that. It has enough features to satisfy some extreme low level tasks. If you want high-level programs then write them in your favourite scripting language. I prefer coffescript due to its expressiveness but I realise that t is not everyone's cup of tee.
However, for low-level programming and where I know static compilation and performance is a key, I will go with go. Why? Because it will take me 10 times longer to do it in C. And although I like C, I will not kill myself to use it unless I am really have to.
P.S. my company has done some amazing stuff with go, docker, fleet and coreos in a very short time. I have no doubt it would have taken us much more time if we had decided to use something else.
Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…
Isn't the issue that people who generally like Go read and write articles like this? ;-) The same is said by PHP devs:)
The problem with this idea is that, for the exact same goals, there could be a much better design for the language and much better implementation of various details.
You don't need to be Haskell or anything. Just Go + generics for example would result in a much cleaner language (no special casing for things like "make" for example), a vastly improved code library and data structures story, etc. This horse has of course been beaten to death (including by people working extensively with Go, so it's not like some "outsider's misconception" as some dismiss it).
If Go succeeds is because noone else with the same kind of visibility and resources tried to compete in this space (easy concurrency, static builds, fast compiles, static, fast-ish, decent batteries included etc).
You have e.g. Rust which is incomplete and too complex, Nim which is too niche, from very small vendor (a guy) and has some bizarro ideas, and that's pretty much it. That said, Swift might make a dent in this area when its Open Sourced if it has nice tooling.
Whether you like Go or not depends on whether you think of software development as engineering or as craft.
> To understands why Go is the way it is you need to know why it came to exist in the first place: "The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source" The problem with this idea is t…
Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.
Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.
What's wrong with JVM?