Tiobe Index: Go language at all time high and in the top 10
tiobe.com
tiobe.com
I think that the problems that Google were trying to solve with go are particularly relevant to the open source community. In particular simplicity encourages more contributors.
The way I see it is that the big open source go projects (eg docker, kubernetes, terraform, etc) have made go popular and a good choice for code within companies who now want to hire go engineers.
There are lots of little reasons for go's success in the open source world like gofmt, integrated testing, quick compile times, easy to read, godoc, single binary deploy, excellent support on all major platforms etc. In short it is really well engineered.
Go projects seem to be really well engineered in general and make for reliable Lego bricks for building bigger things out of. (Go dep and vendoring have helped here.)
Personally speaking go brought back the joy of programming for me getting useful stuff done (like rclone) quickly with minimal fuss and maximum reliability.
Long may Go continue in the top 10!
Of course, this is extremely beneficial to Google: they get a community of people developing free libraries for them. But for the rest of us, it's an enormous drain of mindshare that could be devoted to more general-purpose languages.
This is a tradeoff, increasing bugs and debugging time in exchange for faster compilation. I believe the developers when they say this makes sense in a 1 billion line codebase like Google's, but I've worked on 1 million line codebases and at that size debug time vastly outweighs compilation time in i.e. C#. I'm actually in a good passion to evaluate this because I worked in both C# and Java with and without Generics. Most codebases are far fewer than 1 million lines.
There were other big problems with Go last time I checked, but I haven't looked at it much in a while, so I won't venture to say more since those things might have changed.
I've also had a large (5M+ lines) C++ project that would need to be complied 3-4 times to do things like CI and automated testing. So each build taking 1-1.5 hours, which is not crazy, because of rebuilding code that is static 99% of the time mean that it is worth it to me.
Just because a 33-year old language has problems doesn't mean Go is the best solution.
Did u try use any parallelization ? I am curious because i am working on a "smart" parallelizer builder
Lack of genetics makes the code easier to read. Much better with interfaces. Check this out http://blog.jonathanoliver.com/golang-has-generics/
The author makes the common mistake of assuming that subtype polymorphism can be a full replacement for parametric polymorphism. It isn't, and neither is parametric polymorphism a replacement for subtype polymorphism.
The article you linked is deeply confused. He complains about a complicated generic type that he never encountered, and it's not clear if he's even used generics at all. He also says that if he needs to reuse something later he'll just implement an interface (huh?).
I'm afraid that's not a well-informed article. The assumption that the main use case for generics is collections is very limiting, for example. That might have been one of the original motivations, but today generic types are widely used for countless data structures and algorithms, and even modelling entire patterns of computation in languages like Haskell. They let you prove a lot more useful properties than just not inadvertently trying to pull a foo out of a set of bars.
Particularly this:
>Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
>What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.
>But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive
(He then continues to rant about inheritance, without mentioning generics again.)
So basically, Go does not have Generics and one of the creators justified it by conflating subtype polymorphism, parametric polymorphism and ad-hoc polymorphism (inheritance, generics and interfaces in oop terms).
I happen to agree with Rob Pike that inheritance is a bad way to model things in most cases, but that's a non-sequitur argument against generics.
I also think his arguments about composition is weak, especially compared to how function composition works in Haskell. The Doug McIlroy-quote he pulls out fits great with point-free style haskell, and parametric polymorphism/generics is extremely useful for this.
(To be fair, he has since said that it is a weakness that might change: https://blog.golang.org/slices )
Error handling and control of the flow. Functions as first class citizens with real closure.
Dynamic tracing.
Etc etc
But i do know what are the advantage of Go you want because i personally do not see a lot in it. Different pov i guess.
Scala is yet another language running on a JVM and its syntax is almost as bad and clumsy as Java. Most benchmarks put it on par with Go in terms of performance.
I just don't see a point in using these languages when Go is just as capable, more simple, compiled to binaries (and can even run on bare metal in some cases), runs on more platforms, has much better editor support, and is just more fun to use in general.
For practical reasons I just bear with C++. Use it as necessary.
I would rather not bear with another complicated language, unless there are compelling reasons.
I think it's unlikely that Scala can be useful to me in the near future, because there are so many good alternatives.
functional language with hoards of issues
>TypeScript
javascript
>F#
essentially vendor locked to windows
If you by "essentially" mean "not at all". You've been able to run F# on Mono for ages, and now you can run it on either Mono or .NET Core.
But you wouldn't want to, because for a very long time Mono was horribly buggy, and no library or application cared for supporting it. It may be better now in terms of .Net itself, I am not sure how it looks like in terms of community support for non-windows usage.
https://stackoverflow.com/a/41578645/6767912
and this
https://github.com/NuGet/Home/issues/2880
tells me it's not production ready (yes i've even tried compiling mono from source).
I was lamenting that so much mindshare is devoted to go instead of a more general purpose language, not claiming there's a more convenient language. If that mindshare had been devoted to another language, there's no telling what language would be as convenient as go. But most developers care about more than convenience.
indeed
At that scale it must be a nitghmare to use third party code. Hell they even invented their own system programming language.
We've seen some more languages that cover this particular niche in recent years, but they aren't yet mature and/or lack backing.
The biggest problem here is garbage collection. Garbage collection (or other forms of automatic memory management) has traditionally been necessary for functional languages and (as a matter of practicality) popular for interpreters and JIT-compiled languages, but has often encountered hostility and rejection among users of imperative, natively compiled languages. Go was simply one of the first languages to hit that niche and reach a sufficient level of maturity.
Putting up with Go's idiosyncrasies then became simply a tradeoff.
And the fact that D development appears to be focusing on @nogc rather than fixing the GC issues also doesn't help.
[1] Such as https://pointersgonewild.com/2014/09/09/ds-garbage-collector...
You are fighting a lost battle, go has already won
It's a leading indicator rather than an overall measure of popularity.
* Delphi / Object Pascal is still a thing.
* Ruby has fallen below Go and even Perl. FFS, it's barely holding on vs. assembly language.
* Scratch at #19 makes me happy.
* Rust is still far behind Fortran, Ada, and most interestingly D with which it more directly competes.
They kidding us. There is no better answer I think. Is there?
For JVM Scala, Kotlin and Groovy add up to 1.2% share, while Clojure is not in top 50.
I'm not sure what that means, but I'm skeptical. Java for example shows a steady decline over the whole span of the graph. Then in 2015 it has a massive surge, then in 2016 a massive decline. C shows a similarly enormous decline , of over 50% in 2016. Did the amount of C programmers really drop by half in 2016?
"The ratings are based on the number of skilled engineers world-wide, courses and third party vendors".
but effectively count search engine hits on "+foo language" (https://tiobe.com/tiobe-index/programming-languages-definiti...) on quite a few sites, over half of them Google properties, so they probably double-count a lot, and including IMO weird choices such as eBay.com.
So, even disregarding the question whether that can lead to ratings "based on the number of skilled engineers world-wide, courses and third party vendors" any tweak Google makes to their search algorithm hugely affects their results.
Their subtitle is "July headline: Golang at all time high and in top 10"