KWin Now Requires C++14; Perhaps More Of KDE Will Make Use Of Newer C++?

[boxie]

Awesome for toy applications that don't need high throughput. Golang forces a GC on you that is designed for low latency.
Just allocate a lot of nodes of a linked list or tree and your application will spend most time inside Go's "awesome GC" and slow down your application at the same time. So it will eat a lot of CPU cycles to do work other than the actual work and the application will be many times slower than even a simpler dotnet or Java implementation, for example.

Of course that doesn't mean you cannot throw much more powerful hardware than needed at such a problem. That's the simplest thing to do, right?


The first part, yes, it is a really simple language but for what it does it could be simpler and more powerful.
On the latter part, hell no. There is no function overloading, no generics .. heck, there's not even const structs. Const is just limited to integral types. But not because it's simpler for developers but because it's simpler to implement the language that way. That is the common excuse.
And "error handling" is just a nightmare.

It's just such a limited language, and some of the limitations don't even make sense. They've designed a language where usability was sacrificed for simplicity, though not for the developer that uses the language but for the developers of the compiler/language.

Yes, if you are latency sensitive - if you need to have things done within a certain number of clock ticks, any language that does GC is not a good fit and should not be used.

Your next assertion about Go spending most of its time dealing with GC when you have large data structures sounds wrong to me. do you have an example piece of code that shows this?

If you are writing idiomatic go code, then you will not miss function overloading. remember - it's OO is closer to what OO was originally meant to be, not what C++ turned it into.

Generics is an interesting one, there are times when some form of it would be good, it would remove some boiler plate and a plethora of lib.Func8, lib.Func16 etc methods. This is something that could be on the cards for v2.0

the "But Go doesn't have feature X that I am used to, so it is shit" arguments though in general mute - you could argue that because Rust is not a fully functional language it is shit. This is the whole point of having different languages! different features and different ways of solving problems!

and as for these limitations, what are they?

If you were to sit down and use the language for month or 2, most of your criticisms would melt away as you learnt the Go way of solving problems, just as you would have learnt the way to solve your problems in any other language.

[xnor]

Yes, if you are latency sensitive - if you need to have things done within a certain number of clock ticks, any language that does GC is not a good fit and should not be used.

Well said, and that's exactly why optimizing the Go GC for low latency while sacrificing everything else was/is moronic.
You see, the Go people now tell you that their GC is so awesome that you can use if for latency sensitive tasks...

Your next assertion about Go spending most of its time dealing with GC when you have large data structures sounds wrong to me. do you have an example piece of code that shows this?

I already told you. Just allocate lots of nodes e.g. in a tree structure. It will be several times slower than a Java or dotnet program doing exactly the same work... because the Go GC is so awesome.

The main thing Pike & Co seem to be good at is at marketing. I can remember that when they showed these ultra-short pauses of their improved GC this was marketed at the only metric that counts in GC. One couldn't be farther from the truth...

Same with the "concurrency". Pike marketed it as if they had made this great invention. And channels.
Besides all that nonsense, channels not only limit what you can do, they are also slower than doing it yourself. Heck, Go people were boasting how a message could traverse thousands of channels in a few seconds, when in reality you can do the same work in other programming languages (even python given the right library) in a few milliseconds.

If you are writing idiomatic go code, then you will not miss function overloading. remember - it's OO is closer to what OO was originally meant to be, not what C++ turned it into.

I've seen such "idiomatic go code". It's quite ugly because it's very verbose which is the consequence of not supporting basic concepts such as generics. So you need ugly boiler plate code. It's the same with "idiomatic go error handling". It's just if after if sprayed into the code.

The "simplicity" of the language is what makes it so awkward. And it also makes the code much harder to read than would be necessary.

the "But Go doesn't have feature X that I am used to, so it is shit" arguments though in general mute - you could argue that because Rust is not a fully functional language it is shit. This is the whole point of having different languages! different features and different ways of solving problems!

But that's not my argument. That it doesn't do X is just the first premise of a much larger argument.

and as for these limitations, what are they?

Package management, generics, inconsistent "special" behavior of core language elements, error handling, ... the list goes on an on. Just see the link posted earlier for code examples of how messy "idiomatic go code" can be and how it can have behavior contrary to what a beginner (who Go was designed for) might think should happen.

Also for the lulz: go generate. Pike is a madman.

If you were to sit down and use the language for month or 2, most of your criticisms would melt away as you learnt the Go way of solving problems, just as you would have learnt the way to solve your problems in any other language.

I've used it for a couple of weeks now and all my initial excitement has faded. I thought that less is more but sometimes less really is less.

I still can't believe it. To quote Jordan Zimmerman, Senior Software Engineer at Elasticsearch: "for programmers coming from modern environments such as Python, Ruby, Java, etc., Go is a tremendous step backwards and a huge missed opportunity."

[boxie]

Well said, and that's exactly why optimizing the Go GC for low latency while sacrificing everything else was/is moronic.
You see, the Go people now tell you that their GC is so awesome that you can use if for latency sensitive tasks...

I am sure you can use it for some latency sensitive tasks, it all depends on what that latency requirement is. But even so, if you are counting clock ticks the language you use would depend entirely on the compiler and it's ability to make things happen.

I already told you. Just allocate lots of nodes e.g. in a tree structure. It will be several times slower than a Java or dotnet program doing exactly the same work... because the Go GC is so awesome.

The main thing Pike & Co seem to be good at is at marketing. I can remember that when they showed these ultra-short pauses of their improved GC this was marketed at the only metric that counts in GC. One couldn't be farther from the truth...

for the first time in probably a decade I wrote a linked list toy application using pointers and sure enough I saw the GC pause. Now, if we were to write that same thing as an indexed array we end up with something like

Time to allocate linked list: 129.535719ms
Time to allocate indexed array: 2.816478ms

So, in summary, don't do data structures with lots of pointers, it's bad for performance.

Same with the "concurrency". Pike marketed it as if they had made this great invention. And channels.
Besides all that nonsense, channels not only limit what you can do, they are also slower than doing it yourself. Heck, Go people were boasting how a message could traverse thousands of channels in a few seconds, when in reality you can do the same work in other programming languages (even python given the right library) in a few milliseconds.

Channels are not fast. this has been known for a very long time. if you *need* to do lots of things all at once really really fast, the same adage has been true for a very long time - DIY and prepare to optimise.

for your more pedestrian needs of signalling though, channels work fantastically.

The thing Golang brought to the table was an easy to use language that allowed people to do multiple things at once really easily. after years of PHP and Ruby, this was a breath of fresh air

I've seen such "idiomatic go code". It's quite ugly because it's very verbose which is the consequence of not supporting basic concepts such as generics. So you need ugly boiler plate code. It's the same with "idiomatic go error handling". It's just if after if sprayed into the code.

The "simplicity" of the language is what makes it so awkward. And it also makes the code much harder to read than would be necessary.

This is where I am going to disagree with you based on something subjective. I personally prefer having to deal with errors right then and there. The whole being explicit makes it much easier to debug, and that is a real win from a developer point of view when doing any sort of parallel programming.

I will agree however that some form of generics could be a good addition and that it would indeed DRY up the code

But that's not my argument. That it doesn't do X is just the first premise of a much larger argument.

... but you have spent so much time making it?

Package management, generics, inconsistent "special" behavior of core language elements, error handling, ... the list goes on an on. Just see the link posted earlier for code examples of how messy "idiomatic go code" can be and how it can have behavior contrary to what a beginner (who Go was designed for) might think should happen.

umm, golang has package management built in? works quite well too!
the special behaviour one is a valid criticism
error handling (IMHO) is good

Also for the lulz: go generate. Pike is a madman.

that he is

I've used it for a couple of weeks now and all my initial excitement has faded. I thought that less is more but sometimes less really is less.

I still can't believe it. To quote Jordan Zimmerman, Senior Software Engineer at Elasticsearch: "for programmers coming from modern environments such as Python, Ruby, Java, etc., Go is a tremendous step backwards and a huge missed opportunity."

These three languages have been around since the early 90's and have not stood still. While I have never used Python or Java in anger, I have had plenty of experience with Ruby and I am not a fan. I have the feeling that Ruby is the modern Perl - awesome for its time, but in hindsight...

If you go looking to criticise any language you are going to find plenty of ammunition.

[xnor]

So, in summary, don't do data structures with lots of pointers, it's bad for performance.

If you're forced to use Go that is, which limits you in what you can do. (A data structure with linked nodes typically is not chosen for fun but for performance reasons or specific requirements.) Even other GC languages like Java or dotnet handle equivalent programs with the same number of node allocations a lot better.

The thing Golang brought to the table was an easy to use language that allowed people to do multiple things at once really easily.

No, that was a goal. But to be more precise, it was to create a simple and deliberately limited language that young "Googlers" - you know those fresh out of school that have maybe learned Java and are incapable to understand brilliant languages (quoting Pike here) - can understand.
The plan 9 history of the language also tells us a lot. It e.g. explains why their own compiler (NIH!) produced horrible code for years.

But even given the goal you mentioned I don't see how that was reached though, because as soon as you start sharing data you will run into data races. But hey, there's another tool to help you find races at runtime.
The doc page says differently but you actually should understand the Go memory model if you want to write anything with goroutines that are not simple toy programs. Otherwise you will not understand what is happening and why things are going wrong.

Also, if the goal you mentioned was the main goal then there's no reason for Go. Other easy-to-use languages (especially for "Googlers") already do this.

I personally prefer having to deal with errors right then and there.

That's nice if you prefer that, but Go limits you to that anyway. And if you miss an err or have a data race ... then code just continues to run happily, unless it panics.
Is it fair to say that such preferences are masochistically inclined?

... but you have spent so much time making it?

Nope, that's just your strawman.

umm, golang has package management built in? works quite well too!

It seems you don't even understand what package management is. Import "X" is not package management.
But it seems Go folk have finally come around and plan to adopt dep for package management in the future.

While I have never used Python or Java in anger,I have had plenty of experience with Ruby and I am not a fan.

My sympathies. Given that I'd also ditch it for Go. Not because Go is so great but compared to Ruby...
Are you a web developer, or is programming a hobby?

[boxie]

My sympathies. Given that I'd also ditch it for Go. Not because Go is so great but compared to Ruby...
Are you a web developer, or is programming a hobby?

Been a developer (both web and system) for... (*counts on fingers*, *takes of shoes and socks...*) for 17 (ish) years now (started with a start up before the .com bubble burst).

I also like taking an opposing argument and running with it!

I would just like to say that all the points you have made are valid and well thought out. Some are stylistic (e.g. forcing to error handle right then and there), some are to do with how the language was setup (the hand waiving magic parts) and some are about language features (I too hate having to type cast and int to a int32).

A personal bugbear for me with Go is that it will complain bitterly about trying to add an int to an int32, but is quite happy to let you shift left 10 on a byte, that was an interesting bug hunt!

as for package management - I have been using getgb.io and letting that take care of my vendor dependencies for me.

Perhaps my favourite feature of Golang though is that is compiles to a static file that makes it very easy to deploy. As I have done lots of sys admin with Ruby/Php and to a lesser extent Python - this is a killer feature! deploy is just an SCP (and maybe an init file of some description)!

One feature of more recent languages in general that I am not a fan of is this focus on "expressiveness". which is short for "I am going to make the syntax as short as possible and allow you to chain things together". this falls down really quickly as you write "write only" code i.e. stuff that is really fricken hard to grok a year or 2 later when you have to maintain it again. Do you have enough experience with Rust to tell me if this is a problem?