Jump to content

  • Log In with Google      Sign In   
  • Create Account


Does any interest in the Go language still exist?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
48 replies to this topic

#21 Chris_F   Members   -  Reputation: 2226

Like
0Likes
Like

Posted 19 July 2012 - 07:55 PM

Beyond smart pointers and vector types, I have never personally seen a use for operator overloading that I didn't think was inappropriate or unfortunate.

If I designed a language I think I might include OpenGL like Vec types and bignums as built-ins and then leave operator overloading out.

Edited by Chris_F, 19 July 2012 - 07:55 PM.


Sponsor:

#22 King Mir   Members   -  Reputation: 1948

Like
0Likes
Like

Posted 19 July 2012 - 08:23 PM

Yeah operator overloading is nice to have. Java's .equals and .compareTo methods are annoying to use. Also if you ever want to write a class that behaves like a primitive type with a slight addition, it's messy without operator overloading.

The one alternative to operator overloading like c++ is concepts/kinds like in Haskell. Then you could allow operators to be used only to mean one thing, but can write classes that work like primitive types by implementing the same Concept.

#23 davepermen   Members   -  Reputation: 1007

Like
0Likes
Like

Posted 20 July 2012 - 12:26 AM

I hope they stick with it, don't go after any of the Linq / Dynamic / Generic things but instead work on the compiler to make it FAST (runtime).

both link and generics are compile time and thus have ZERO performance issues. they do have tremendous impact on writing code fast, and writing it correct. typesavety rocks.

where you need to go outside of typesavety (especially common in the webworld with json and that crap), dynamic is there for you. it is, again, language sugar that typically is nothing more than a nice dictionary.

so languages helping you code properly and easy are stupid, then? maybe that's the reason nobody cares much about go. those who actually want to do stuff don't consider languages that help a developer a bad thing.
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud


#24 kunos   Crossbones+   -  Reputation: 2205

Like
0Likes
Like

Posted 20 July 2012 - 01:03 AM


I hope they stick with it, don't go after any of the Linq / Dynamic / Generic things but instead work on the compiler to make it FAST (runtime).

both link and generics are compile time and thus have ZERO performance issues. they do have tremendous impact on writing code fast, and writing it correct. typesavety rocks.


what I meant is.. if the Go dev team is concentrated on designing and writing generics, they cannot concentrate to improve the quality of compiled code.
And I think performance should be the entire point in Go. If you add generics and all the other stuff and make it a C#/Python clone what's the point in using Go anyway?
Right now the performances are better than python but they are behind .NET... they should spend all the energy to fix this fact.

There is an interesting thread on the golang-nuts group about the user case for having generics.. at the end, with only some exceptions, all those case are perfectly managed using Go's interfaces and duck typing... so dismissing a language because it doesnt have this feature is pretty close minded IMO and totally missing the point. If you want a language with EVERYTHING and I mean EVERYTHING then take D... again, Go's motto is less is more , and having been coding in Go both in production and hobby code for more than a couple of months now I can say it is a breath of fresh air, everything is so simple, but simple in a different way.. it's simple because the language is so small and well thought out that you _NEVER_ find yourself fighting it.
Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#25 l0calh05t   Members   -  Reputation: 689

Like
0Likes
Like

Posted 20 July 2012 - 01:27 AM

Beyond smart pointers and vector types, I have never personally seen a use for operator overloading that I didn't think was inappropriate or unfortunate.

If I designed a language I think I might include OpenGL like Vec types and bignums as built-ins and then leave operator overloading out.


Off the top of my head: complex numbers, quaternions, dual numbers (automatic differentiation! best when combined with generics), dual complex numbers/quaternions, modulo arithmetic...

both link and generics are compile time and thus have ZERO performance issues.


Except that the Go developers seem to care more about compile time performance than anything else so far.

#26 kunos   Crossbones+   -  Reputation: 2205

Like
0Likes
Like

Posted 20 July 2012 - 01:59 AM

Except that the Go developers seem to care more about compile time performance than anything else so far.


I don't think generics would ruin that either. C# has awesome generics and it compiles in a blink. Only C++ has a problem because of the demented build system from the middle ages.
Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#27 Chris_F   Members   -  Reputation: 2226

Like
0Likes
Like

Posted 20 July 2012 - 04:47 AM

Enough with the talk of generics already. Yes, it would be awesome if Go had generics and they have said that they aren't against including them in Go if they can figure out how to implement them correctly.

#28 davepermen   Members   -  Reputation: 1007

Like
0Likes
Like

Posted 20 July 2012 - 04:59 AM



I hope they stick with it, don't go after any of the Linq / Dynamic / Generic things but instead work on the compiler to make it FAST (runtime).

both link and generics are compile time and thus have ZERO performance issues. they do have tremendous impact on writing code fast, and writing it correct. typesavety rocks.


what I meant is.. if the Go dev team is concentrated on designing and writing generics, they cannot concentrate to improve the quality of compiled code.
And I think performance should be the entire point in Go. If you add generics and all the other stuff and make it a C#/Python clone what's the point in using Go anyway?
Right now the performances are better than python but they are behind .NET... they should spend all the energy to fix this fact.

There is an interesting thread on the golang-nuts group about the user case for having generics.. at the end, with only some exceptions, all those case are perfectly managed using Go's interfaces and duck typing... so dismissing a language because it doesnt have this feature is pretty close minded IMO and totally missing the point. If you want a language with EVERYTHING and I mean EVERYTHING then take D... again, Go's motto is less is more , and having been coding in Go both in production and hobby code for more than a couple of months now I can say it is a breath of fresh air, everything is so simple, but simple in a different way.. it's simple because the language is so small and well thought out that you _NEVER_ find yourself fighting it.

there you have a point.

yet, i never fight against c#. i left c++ because it was always me against the language. c# is totally simple, though. and it's very fast in both compilation speed, and runtime performance.

but enjoy your fun with go. no problem there.
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud


#29 kunos   Crossbones+   -  Reputation: 2205

Like
1Likes
Like

Posted 20 July 2012 - 06:21 AM

yet, i never fight against c#. i left c++ because it was always me against the language. c# is totally simple, though. and it's very fast in both compilation speed, and runtime performance.


I agree, C# right now is the most productive and mature language out there, with the best tools and the best balance of productivity and performance... and always the language I suggest to learn and use whenever possible.
But Go is a possibility for the future and IMO it shows a huge potential.

Edited by kunos, 20 July 2012 - 06:43 AM.

Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#30 davepermen   Members   -  Reputation: 1007

Like
1Likes
Like

Posted 20 July 2012 - 06:28 AM

heard that from too many languages. but, we'll see.
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud


#31 Telastyn   Crossbones+   -  Reputation: 3726

Like
0Likes
Like

Posted 20 July 2012 - 06:33 AM

I am very, very interested in seeing how structural typing is accepted by programmers, and how much it hinders runtime performance since that should be directly applicable to Tangent.

#32 dilyan_rusev   Members   -  Reputation: 902

Like
0Likes
Like

Posted 22 July 2012 - 12:13 PM

I am too busy right now to do hobby projects, but once I'm done with my dissertation I will definitely love to try out go. For me, the huge benefits are Pascal-like declaration (I like that language a lot), the short declaration & assignment operator (:=), the simpicity of loop and control statements (no () and always {}), and, most importantly, interfaces.

About C# compilation time. Uugggh what? Fast? Faster than C++ (anything is faster than that!), but not fast at all. With quite good hardware for its time, the projects I worked on compiled for at least 20 minutes (full). The way to combat this is to create more projects, so that you can utilize conditional compilation. But then if you dare touch anything in the base components, you can wait forever.

#33 kunos   Crossbones+   -  Reputation: 2205

Like
0Likes
Like

Posted 22 July 2012 - 12:35 PM

With quite good hardware for its time, the projects I worked on compiled for at least 20 minutes (full).


woooah... That's quite a bold statement my friend. What kind of application was that? Skynet? Are you sure there wasn't any module in managed C++ getting compiled in the solution?
In my experience C# compile time is pretty much instantaneous.
Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#34 dilyan_rusev   Members   -  Reputation: 902

Like
0Likes
Like

Posted 22 July 2012 - 01:23 PM

Unfortunately, yes :) It was a CMS. The older version contained something like 50 projects. External dependencies are embedded via source, so we can be immune to the changes of upstream. Add unit & integration tests, add sample projects, and it quickly builds up. Plus, to protect yourself from the stupidity of the user, you might want to embed a lot of resources, which takes compile time, too. The new version didn't have any conditional compilation that I am aware of, but the older implemented product lines via #ifdef-s, which added some more pain.

#35 Telastyn   Crossbones+   -  Reputation: 3726

Like
0Likes
Like

Posted 22 July 2012 - 02:22 PM


With quite good hardware for its time, the projects I worked on compiled for at least 20 minutes (full).


woooah... That's quite a bold statement my friend. What kind of application was that? Skynet? Are you sure there wasn't any module in managed C++ getting compiled in the solution?
In my experience C# compile time is pretty much instantaneous.


I've had it not be instantaneous; though it usually takes quite a bit to get there. Even with ~1m LoC, running the entire suite of unit tests, and doing almost all the FxCop rules on build I've never seen more than 10 minutes on a developer laptop.

I suspect that some build process or disk thrashing was involved to get it 20 minutes bad; something...

#36 dilyan_rusev   Members   -  Reputation: 902

Like
0Likes
Like

Posted 22 July 2012 - 03:02 PM

Well, you almost never have a full build. You very, very rarely change the external dependencies. Compiled resources get changed more often, but we didn't link explicitly to the resource project so that you don't have monstrous build times. I don't remember if MSBuild/Visual Studio supported parallel compilation, but I guess that could have cut down the compilation time substantially. On most occasions, you would only have to rebuild the product code base and unit tests, which took just a few minutes. The pain was when you get from TFS, because we used strong versions and assembly signing. That is, if you have A depending on B, but B is built with the previous version, you will get an error, and will have to do full rebuild to force VS to use matching versions. Didn't happen very often, but it did. That usually meant coffee time.
As for the build server, it was the standard thing - delete build directory, get latest version, build, run unit tests, send emails with results. Those ran on every check-in. They lagged quite a lot, because unit tests took forever to run (a little before I left, unit tests alone took 47 minutes on my machine, and faster on the build server).

#37 phantom   Moderators   -  Reputation: 7058

Like
0Likes
Like

Posted 22 July 2012 - 03:42 PM

As for the build server, it was the standard thing - delete build directory, get latest version, build, run unit tests, send emails with results. Those ran on every check-in. They lagged quite a lot, because unit tests took forever to run (a little before I left, unit tests alone took 47 minutes on my machine, and faster on the build server).


The thing is when people say 'instant build times' they are generally talking about projects which the majority handle - chances are with the projects you are talking about with the features you are using you won't see better compile times with any language; certainly C++ is going to be worse due to it's model, but Go or a language like it, assuming you perform some kind of verification that you are compiling against the same versioning as you are with C#, is not likely to come out much better simply because if you are forcing the same compile rules you are likely to be disk IO bound more than anything.

This is much like our data build system at work; originally we had a Python based system which would build up a graph of nodes of work with dependencies before building. As the project got more data so this process got slower and slower until it was taking nearly 5 minutes before it started to build. We rewrote it in C# so that it now starts work in around 10 seconds however it still took a long time to build all the data (one track takes ~40mins from clean for 3 platforms, all tracks ~3 to 4 hours) which people still complained about so now I spend around 5mins a day explaining that while it starts work faster you are still limited by the large amounts of data you have to shift about.

So, dragging this back to the point - if you are triggering rebuilds on the same rules then chances are you'll be IO bound still and thus not see any improvement on any language which compiles.

#38 MrDaaark   Members   -  Reputation: 3551

Like
0Likes
Like

Posted 22 July 2012 - 04:30 PM

Go is a language I play with on my Android Tablet while I'm waiting around for my laundry to finish. I haven't gone any further with it than just typing stuff into the GoLang.org site and watching the output.

I like the simplicity or the syntax, and having the GoFmt program to structure the source to the preferred/official style. It's nice when there is one style, and one way to do things, so I can just read code at face value, and not try to figure out which way the writer is trying to be too clever for his own good before I can even see what the code does.

It still seems like a toy language for now though. Just one of many random experiments at Google that may end at any time. It would be nice if they supported it for Android development.

#39 dilyan_rusev   Members   -  Reputation: 902

Like
0Likes
Like

Posted 22 July 2012 - 05:15 PM

@Daaark - you seem to be right. That is more or less my experience with go as well :) Maybe it is because I've had to deal with a very messy and big code bases, but I do love the idea for interfaces they have. There is something very similar in Python with classes that have write and read methods (I don't remember how they call it in Python, but it was used as a basic interface for streams/files).

Although there seem to be at least somebody that is using go in production, although all panelists seem to be from start-ups, no more than a few years old. I don't think I'd heard about any of them, but I haven't heard about a lot of stuff, so that doesn't mean anything :D

There is another video from Google I/0 2012, where the Google Go team do Q&A session. I don't remember the timing of the question, but basically they answered that there are no plans for Android mapping. The general summary is that they wanted a stable version so that they can promote and use go internally at google to justify the time spent developing it. You've got the Google App Engine, and a few general-purpose libraries & bindings. There doesn't seem to be a complete UI toolkit. There is a GTK+ binding, which is incomplete, and there doesn't seem to be any activity for the past two months, which is unusual for a new library that is incomplete. I really want to do my Ubuntu apps in go and not python. I don't have the time anyway, so it is not a huge loss. There are a few libraries for Windows, but I haven't looked into how complete they are, since we have WPF & friends on Windows ;).

#40 MrDaaark   Members   -  Reputation: 3551

Like
0Likes
Like

Posted 23 July 2012 - 04:58 PM

I think it's a great language to recommend for people wanting to learn programming. It lets people get their feet wet with simplified C-Style syntax, and there is nothing to install. You just type everything into GoLang.org, and watch what happens. Easy and harmless. You can even share your work, paste-bin style.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS