3 ms·
People need to stop trying to force themselves using Go. Yes, good concurrency perks and easy deployment are handy, but Go basically demands people to code 1993
by spriggan3 11y ago
People need to stop trying to force themselves using Go. Yes, good concurrency perks and easy deployment are handy, but Go basically demands people to code 1993 C-Object style since its authors basically rejected 20+ years of type theory. If it feels dirty don't promote that, don't promote a community that is in total denial when it comes to its language shortcomings.
Plenty of alternatives like D,Nim,Vala,Crystal,Erlang and many more. You want the same developer experience as Go (go get,gofmt,golint,go-code...)? then develop the tools for these languages and drop Go. Don't settle for an half baked language just because "it's easy to start with",it's easy to start with because the standard library is dumbed-down. Just look at Go projects on Github where developers spend their time trying to fix the Go std lib in their own code...
- akavlie 11y agoA lot of people are not free to decide that. Go has become very popular in young, mid-size tech companies. Most of the alternatives you listed are too new/fringe/unproven to consider. And, well, they're not made by Google (corporate backing makes a big difference with new languages).
- geodel 11y agoIt is also getting popular with IBM, Comcast, RedHat and of course Google etc which are older and big companies.
- stcredzero 11y agoYes, good concurrency perks and easy deployment are handy, but Go basically demands people to code 1993 C-Object style since its authors basically rejected 20+ years of type theory. If it feels dirty don't promote that, don't promote a community that is in total denial when it comes to its language shortcomings. What languages are popular and what languages are people getting stuff done in? Maybe the people in denial aren't the ones supposedly denying the supposedly "better" paradigm/model/type system? Maybe the ones in denial are the "misunderstood" languages? For our young field of programming, this now qualifies as an old story: A "superior" computer language is misunderstood by the mainstream, and progress is tragically held back. It's happened before, and it will happen again. But I posit it would be better to think of each language as an iteration and to look for lessons learned. As someone who spent time in such a language community, let me point out one such: Technology and paradigmatic superiority are only two ingredients out of many that contribute to the success of a language community. Do outreach. Make your stuff "just work" for the beginner. Be able to solve real problems while not creating too many new ones. Also mind the overarching lesson of all software history: Pragmatism wins the day.
- AnimalMuppet 11y ago> ... don't promote a community that is in total denial when it comes to its language shortcomings. The point of Go was not to be "up to date" on type theory. The point of Go was to have a language that minimized some of the problems that you run into when you try to maintain 10 million lines of code for two decades. The authors/designers of Go didn't feel that "modern" type theory was the key to doing so. Of course, the modern-type-theory people think the Go designers are wrong. Who's right? It's too early to tell. But for what it's worth, I'm pretty sure that the designers of Go have more exposure to modern type theory than the modern-type theorists have experience with maintaining ten million lines of code for two decades.
- spriggan3 11y ago> I'm pretty sure that the designers of Go have more exposure to modern type theory than the modern-type theorists have experience with maintaining ten million lines of code for two decades. See, the problem right here."Go designers know better than everybody else". No they don't. The standard library itself is totally inconsistent and goes against what Go designers themselves promoted as being idiomatic. > The point of Go was not to be "up to date" on type theory. Sure it's a dynamically typed language that mascarades itself as a statically typed one, a bit like C with its void pointers everywhere... Except it doesn't have C macros, which makes it even more painful to program than C.
- XorNot 11y agoThe standard library is abstracting over a lot of non-idiomatic surface area of kernel interfaces.
- _ak 11y agoNobody claims that they know better than everybody else, that's just your words, which you then contradict without the slightest bit of evidence. Truth is, the Go developera have a proven track record over several decades, and that gives their ways of doing things certainly more weight than those of young whippersnappers who have never built several operating systems, programming languages, or other large and complex pieces of software.