.net core vs go

[Luca Looz]

I'm a big fan of Go and i have used it for some side projects. I like its performance, built-in concurrency, easy cross platform builds and the concept of being practical and productive.

My company it's currently .net based, we develop all backends (scrapers, rest api, web sites etc) in vb.net and c#.

We want to switch to something crossplatform and stick with it for all new projects. 

My boss discovered Go and he likes it too but i know for certain that .NET core (currently in RC) it's an obvious choice because we don't need to learn a completely different language and development environment.

I would like to use Go but i don't know which arguments can i use to persuade by boss, any hint? 

[Mike Orr]

You’re going to get a lot of useful responses to this Q, but in addition to everything else people say, I’d suggest a little meditation on the following questions:

 

(1) Why - exactly and concretely - do you say "I would like to use Go"? (You answered this at least partially in your post. Is there anything else, perhaps including non-technical factors?)

 

(2) Why - exactly and concretely - do you suspect these reasons would not persuade your boss?

 

(3) From the point of view of your organization’s goals, are the reasons in (2) legitimate, or ill-considered/short-sighted?

    (a) Legitimate could be eg technical virtues of Go don’t outweigh other business-centered factors.

    (b) Ill-considered could be eg boss has her/his own favorite language.

    (c) Short-sighted could be eg giving transition costs too much weight compared to long-term benefits.

 

(4) If, on objective reflection, the answer to (3) is "largely legitimate", then this is an opportunity for your own self-mentoring and personal growth.

 

(5) If the answer to (3) is "largely ill-considered/short-sighted", then how - exactly and concretely - did your self-reflection convince you of this? You’ll find in there some of the arguments you’re looking for.

 

Lather-rinse-repeat after each time you talk to your boss about this, in light of what she/he (and you) actually had to say.

 

Please understand that I'm not out to slant you one way or the other re the answer to (3). Both happen every day, and getting good at distinguishing one from the other is a great skill to develop.

 

Good luck,

Mike

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Looz]

(1) Yes there are non-technical factors too. I just want to ditch .net and use something completely new and non microsoft related. I also want to switch from windows server to linux but this with .net core will be possible too. Currently we mainly develop ios and android apps and the company is splitted in mac and pc users (i'm using a mac for android development and use a windows VM to do some .net stuff when needed)

(2) I suspect it because all of my backend coworkers have only a .net knowledge and a little of html/css/javascript and i'm the only one that have done something in Go

(3) I think that my boss has a legitimate reason for choosing .net core because it offers cross platform development (the main thing that we are seeking) and we can be productive quickly. Even if .net core is in RC we can continue to develop with the classic .net and switch to core gradually. We are in a phase of "changing"  and we are starting to do web apps with angular etc, my boss is also considering nodejs because we can use a single language both server and client side (web)

My will to choose golang maybe it's selfish but i think that in long term Go is a better choice performance wise, license costs (maybe by adopting go we will be more willing to use linux and open software) but also because switching to something new (and better for my point of view) can be an opportunity to loose bad habits in development

[abou...@gmail.com]

Keep in mind that .NET core is still not ready for production, even in RC2 status.  The tools are incomplete.  The runtime is not optimized.  RyuJIT still needs work.

You'll have to get used to new CLI tools, some based on node.js (because not everything integrates with MSBuild yet), work in VSCode or another editor (Visual Studio does not integrate with .NET core yet).

Go is production ready right now and I've been using it to develop in Windows, then cross-compile (very easy) and deploy to QA/demo/production in Debian.  It also requires switching from Visual Studio IDE to other tools but that is expected.

I use it to replace PHP and Python mostly, not .NET.  Some areas you may find lacking in availability of 3rd party libraries and starter kits.

If you absolutely have to deliver a solid Linux-based web project in 3 - 6 months from now, Go might do it for you while .NET core is unlikely to.  If the project deliver date is a year away, .NET core will probably work fine (still a risk though).

You can gradually introduce Go in small projects like RESTful services, command line tools, etc. and see if others like and accept it without committing full-scale. 

[antongiuli...@gmail.com]

IMHO you must consider nodeJs.

[Bogdan Bursuc]

Learning is part of being an engineer and go is easy to learn. It looks scary and awkward at first, but once you dive in you realize it's fast to build things and fast to learn and the community I think it's pretty mature atm with lots of tools evolving. 

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thanks,

Bogdan I. Bursuc

[Sokolov Yura]

<trollmode>
Haxe ( http://haxe.org ) compiles both to C# and javascript. One should add Go backend to Haxe.
</trollmode>

[Sotirios Mantziaris]

Hi,

since i am pretty much you are i can give my 2 cents.

go has some features that make the language really attractive like concurrency, cross-compile, good standard library, easy to learn etc etc.

the problem for me with go is that the tooling is not that good. Keep in mind that when writing c# you are using Visual Studio which is one of the best IDE.

Keeping this in mind i feel that i am more productive and can do more stuff when using Visual Studio. Debugging is a breeze, visualization is too, profiling is crazy etc etc.

Some language features like generics, linq do make a great difference when working!

Since the announcement of .net core the benefits of golang are not that strong anymore since .net core does cross compile, concurrency is really nice (async-await) and they get channels too(see CoreFX Labs), there will be a way to generate on native binary with .net native (this i have to check out better), kestrel (the web server based on libuv) does shows very nice benchmarks and will be posted at some point to https://www.techempower.com/benchmarks/, F# will be available for .net core too, MVC is there and off course you can be right away productive with your previous knowledge. 

I will be still expand my skills in golang but .net core is a really good option. btw release date of asp.net core 1 is end of june 2016. so you can start using it already.

hope this helps

[Eric Johnson]

On Monday, May 16, 2016 at 6:37:20 AM UTC-7, Luca Looz wrote:

I'm a big fan of Go and i have used it for some side projects. I like its performance, built-in concurrency, easy cross platform builds and the concept of being practical and productive.

My company it's currently .net based, we develop all backends (scrapers, rest api, web sites etc) in vb.net and c#.

We want to switch to something crossplatform and stick with it for all new projects. 

This comment makes me think you're planning a step too far. From the description of what your company is doing, you probably have the opportunity to try something new for a specific small project. Pick a project that would benefit from Go, and make a case to your boss that you should try just that project in Go, and learn from it whether or not Go is a fit for your company. In general, it is a terrible idea to re-implement existing code just to move to a new language. This trial project can play out in three ways:

a) It works brilliantly.

b) It works terribly.

c) It is inconclusive.

If you land in category (c), then you've probably got your answer - stick with C#. That's where your company's expertise lies, and the biggest expense your company probably pays in developing these projects is the cost of your developers' time. Obviously, don't sabotage your experiment, either by picking only the best people for this team, or only the worst - try to make your team and its experience align with the rest of your company.

 

My boss discovered Go and he likes it too but i know for certain that .NET core (currently in RC) it's an obvious choice because we don't need to learn a completely different language and development environment.

I would like to use Go but i don't know which arguments can i use to persuade by boss, any hint? 

We are blessed / cursed with too many options for cross platform development. Java, Javascript, C#, Swift, Go, Rust, C++, Haskell, Clojure, Python, and Ruby all seem viable based on your description. I'm guessing you've discarded Python & Ruby because of performance concerns. Personally, I'd discard Java, because the huge changes coming with Java 9 might be seriously disruptive, Oracle is still causing legal troubles around Java, and Oracle has a very poor history of engaging with open source (and doesn't seem to be changing). C++ is probably too complex, and may be difficult to find great developers. Haskell & Clojure also probably suffer from difficulty hiring - unless you have specific libraries or features that align well with those languages. That leaves you with C#, Swift, Go, Javascript, and Rust.

C#, Swift, and Go all have a single major corporate sponsor. This is both a strength and a weakness. On the strength side, it means great support for the really hard parts of making a great language - performance, better faster memory management, documentation, and obscure bugs, just to name a few. Of the three, however, Google's future isn't tied to developer engagement with the language. Which ironically, makes it a stabler choice, because it isn't as likely to change just to chase the latest programming fad. Community outside of Google also seems quite robust. Microsoft does not have a long history with positive engagement with Linux, so that deserves some skepticism (although, to the company's credit, it has changed dramatically over the past few years), and has a long history of making languages not quite conform to standards. Microsoft also has a very long history of trying to lock you in via many subtle and overt means. Makes me skeptical. Apple has a long history of changing Objective-C to fit the latest needs of their OSes, and Swift has already moved to a 2.0 version, so they seem to be keeping to this trend, and thus I wouldn't recommend Swift (yet).

So at least for the corporate-backed languages, looking from the business perspective, the long-term viability of languages based on the historical record of changes seems to favor Go. Google looks like it will not push backwards incompatible changes into the language.

The other languages to consider, then: Javascript & Rust. I don't know anything of substance about Rust. As for Javascript, I know teams that have been successful precisely because they can have developers move from front end to back-end and vice-versa. The Javascript community is driven to continued massive improvement in order to improve the overall experience of the web (driven by corporate interests, and robust competition from open source).

Based on just business considerations, my take: Javascript and Go.

From a technical perspective, it depends on what you're trying to do. Javascript / NodeJS developers rave about how everything is asynchronous. Unfortunately, that very asynchronous nature means that you have to turn your code inside out, waiting for events. My personal preference is to favor linear thinking - our brains seem to be better at it. Which means that Go's model of goroutines and channels works better for larger scales. My experience also suggests that large code bases due much better with static typing, not dynamic typing. Again, benefit to Go.

One final thought - conceptually, Go is a pretty straightforward language. Which I makes it easier to pick up and read someone else's code. For long-term support of a code-base, this is a huge win.

Overall, though, I'd suggest to both you and your manager, that in fact, the future lies in being multi-lingual. You need Javascript for the front end, but might have better success with something else on the back-end. For mobile devices you may still need to use a "native" language such as Swift or Objective-C. You almost certainly still need SQL. Right there, that's at least four languages. The robust competition around cross platform languages means that we're going to experience somewhere between 5-15 years of these languages competing to win the space. Impossible to guess what will "win" on the far side of that time.

Eric.

[parais...@gmail.com]

There is no debate here, .net comes with 15 years of libraries with battery included . If you're goal is to develop a complex web application with complex business logic, form logic,validation logic, view logic, ORMs and what not, .net core will be a better fit. Go is good for plumbing and writing server infrastructure components that doesn't need ORMs, complex validation schemes and what not. Just have a look at MVC6 then look at Go ecosystem when it comes to http frameworks. There is no equivalent. MVC6 is a sweet spot between JSF and Rails , it embraces dependency injection , Async I/O with Kestrel and you wont need any library but the core framework for most of your work. Hundreds of people get paid to work on asp.net so it is no surprise it is a complete framework with good integration with Windows software if you are in the enterprise space.

Fortunately, Go isn't a tool that requires a lot of investment when it comes to learning or deployment so it can remain in your toolbelt when needed, instead of using a scripting language for instance. 

[Steve OConnor]

Thanks for introducing this topic, its a good read.

Its a proverbial can of worms though, as any "Language X vs Language Y" sort of question is likely to be.  The only thing worse that advice on language & platform wars is career advice  .... so Im going to take the extreme liberty of doing both :)

.Net Core vs Go ???

Its the same as asking about taking a trip into town ... should I catch the bus, or ride my bike ?  Both will get you into town at around the same time, but from there on the differences are innumerable. Personally, Id take the freedom of the bike, and risk getting wet or run over anyday. 

Should we chop up some fresh ingredients and cook a homemade meal, or stick a frozen pizza in the microwave ?  Both options produce a meal. Personally, Id rather know what Im eating.

Convince the Boss ??

I would strongly advise against any attempts to persuade your Boss, let alone adjust the corporate culture that you are currently in. Its do-able, but its too easy for a developer to underestimate the amount of energy needed to pull this off, and besides, it rarely ends well, and cuts deeply into your coding time.  You are going to be one against many, and its going to be a long and sometimes pointless battle. Since there are quite a few people in that company who are invested in MS skillsets, anything different is going to be treated as a threat by many of them.  You will make new enemies for sure. There are just too many things that you simply don't have direct control or authority over in that environment.  

Nothing stopping you from investing your own time outside of work in your own projects though, and having full control over the outcome.  Win or Fail ... it will make you a far better developer all round, and set you up much better for your next project.

Go is low volume but hot in the job market at the moment.  I am seeing some interesting positions becoming available, and the job descriptions tick all the right boxes. "The Market", if you like, appears to be putting a very high value on Go developers.  (ie - they are high calibre positions that carry a good deal of respect and creative freedom ... and that is exactly what you are looking for). 

Whatever you do though, don't follow MY advice, unless you really want to walk in my shoes, and experience the same ups and downs that I have chosen. Same goes with any other advice.  But while we are at it, if I was in the same boat as you,  I would choose to start working on my next move at this point.  Do a great job where you are, but forget about trying to change them. Get really good at what you enjoy doing, make your experiments and mistakes in your own time, and cultivate your next move to a company that is in more in line with your own goals and view of the future.  

Trust your gut, walk your talk, and don't be afraid of failing.

Start looking around I reckon.  

If your current Boss is any good, then take him with you too  :)

[Tim Hawkins]

He mentions that they have a bunch of Web scrappers,  this kind of task is heavily concurrent, something that .net is not know for, but golang is. We are a php house, but we are switching to go for this one reason, our new internal stack wil be based on php frontend,  golang based microservices layers, and mysql, elasticsearch and mongo based data stores.

We also run Windows and Linux servers,  we are continually having problems with our windows systems stalling becuase the predominate pattern for services there is to build a "windows service",  which suffers from issues with leakage of resources, deadlocks etc.

The predominate pattern on linux for services that don't have a listener, is to use cron driven tasks that execute a fixed amount of work and then die, freeing up all resources except persistent ones like disk space.  This makes them very much more reliable. Golang has good support for building listeners too.

--

[Sotirios Mantziaris]

Dear Tim,

We are a .Net house and we are running "windows services" for months without having any problem. Sql Server, which is a very robust RDBMS, is a windows service and runs rock solid for years. So the issues you mentioned are mainly your own code issues.

Windows has a feature called Task Scheduler where you can schedule anything to run on a schedule if that is what you want.

The claim that .Net is not heavily concurrent is not true either. You can use TPL (Task Parallel Library) and run a really solid and performant concurrent programming model with ease. 

This will scale very nicely with the cores of your machine. Especially when using Parallel.For which does some optimizations.

Long story short. Please try to be correct on your claims since you are sounding like you don't know windows and .net that much. no harm intended. 

Kind regards

[Luca Looz]

Thank you all for your interest in this, in the end it is more a business decision than a bare ".net core vs go" comparation.

I have talked with my boss and i think that we will have a long-term plan like this:

1. Keep working with classic .net
2. Acquire knowledge about open rdbms (mysql/mariadb,postgres etc) and replace sql server
3. Meanwhile for small "isolated" projects and if the team agrees use golang and linux servers
4. As soon as .net core matures gradually switch to it and to linux servers where possible
5. Draw conclusions about where we got

[francoi...@gmail.com]

Hi Sotirios

I have always been someone trying to balance out the "developer productivity" vs "runtime efficiency". By only using a coding language/framework because you can code much quicker in it is almost 99% of the time going to bite you in the *** later. Sure if you just want to "prototype" something it doesn't matter. But how often does the prototype not become the starting point and turn into the "legacy" black-box nobody want to touch.

Consider for instance something like Gitlab written in Ruby vs Gogs (with Drone CI) both written in golang.

Gitlab requires about 2GB Memory (minimum) to run in production with as little as 10 users. If you have less than that Gitlab will feel really, really slow and even sometimes run into "out of memory" errors.

Now Gogs on the other side uses about 20MB of memory. Sure, Gitlab is at this point more mature than Gogs but is it sustainable? Consider having to host these two on DigitalOcean for example. You will need at least the 2GB Droplet for Gitlab whereas the 512MB Droplet will be more than sufficient for Gogs. You can even turn it up a notch. If you want to host 20 instances of Gitlab or Gogs. For Gitlab you will need 20 of the 2GB Droplets, adding up to $400/month. But for gogs the SINGLE 512MB will still be sufficient at $5/month.

Now that is enough on the Memory side. Golang can be built as a "static binary" which means the SINGLE binary file contains everything about the the application. Consider this article: https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/, where the static linked binary is a mere 5.6MB in size. If you take .NET you will probably need IIS and the .NET Framework on top of your application.

Golang also actually include the http server in this 5.6MB of static binary. So no need for another layer like IIS.

Just a handy tip. There are "awesome lists" of about any framework and language out there:

• Curated list of them all: https://github.com/sindresorhus/awesome
  
• Golang: https://github.com/avelino/awesome-go and https://github.com/golang/go/wiki/Projects 
• .NET Core: https://github.com/thangchung/awesome-dotnet-core

[Sotirios Mantziaris]

Hi,

i too use go and i see all the benefits that you are mentioning. I was only pointing out what was wrong in the post about windows...

BTW You don't need IIS to run .Net Core. There is a new web server named Kestrel (check this video https://vimeo.com/172009499) which performs very well.
So creating docker containers is straightforward too. You just need more files to deploy instead of one and if you automated this it should not matter!

BTW There is a project research named .Net Native which will eventually create on static linked binary!!!

I do not have any idea about memory consumption on .net core., this would be nice to check out! Comparing ruby with go is a little off, since ruby is not known to be performant and cheap on memory.

Creating apps with both is very nice. go gives you what you have mentioned. .net core almost the same with better tooling (Visual Studio rocks)

[Jan Mercl]

On Wed, May 18, 2016 at 4:06 PM Sotirios Mantziaris <smant...@gmail.com> wrote:

> The claim that .Net is not heavily concurrent is not true either. 

A Go program executing 100k goroutines needs 200MB or 400MB RAM for stack, depending on version, so it can run just fine. A .net program trying to execute 100k threads will OOM way before reaching a even a small fraction of the goal.

--

-j

[Francois Hill]

Hi, yes I agree with the fact that Visual Studio is one of the best IDE's out there. But in general tooling, golang has a great set too. I suggest you check out VS Code with golang extension, pretty neat! And on top of that VS Code is cross-platform too. 

[Sotirios Mantziaris]

This is actually my go setup along with delve for debugging.

--

Kind Regards,

S. Mantziaris

[Sotirios Mantziaris]

Hi Jan. The correct analogy here are not threads but Tasks from the excellent Task Parallel Library in order to compare Apples with Apples. 

i have a little stupid source code (https://github.com/mantzas/headon) that run in parallel n tasks and the equivalent in go.

dotnet run 1000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 1000000

1000000 in 00:00:00.8903075

 

go.exe -tasks 1000000

Task to execute: 1000000

1000000 in 3.9731993s

when running higher number of tasks like 10000000 i get:

λ dotnet run 10000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 10000000

10000000 in 00:00:07.9395814

the same in go had the following result:

eating all my memory and crashed

BTW the dotnet memory consumption is around 700 MB. 

When using dotnet's Parallel.For we have even better results

λ dotnet run 10000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 10000000

10000000 in 00:00:00.8419129

and the memory consumption is around 7MB!!!

i have tested the same in Linux so i could say the following based on the above:

dotnet has a better implemented concurrency library allowing only some tasks to run concurrently (POOL) and it is by a lot faster than goroutines.

in go you can shoot yourself in the foot easily.

Please review my code for any mistakes i made and let me know.

[Wojciech S. Czarnecki]

Dnia 2016-10-08, o godz. 23:55:08
Sotirios Mantziaris <smant...@gmail.com> napisał(a):

> Please review my code for any mistakes i made and let me know.

> private static void Work(int i){
> var t = string.Format("Task {0} done!", i);
> }

Above construct is a NOOP and almost certainly did not went to executable.
Probaly even your 'for (int i = 0; i < tasks.Length; i++)' block had been
optimized away, as there is no work to do as seen by compiler.

So in .net version you measure only the tasks array allocation/init time:

> var sw = Stopwatch.StartNew();
> var tasks = new Task[taskCount];
> sw.Stop();

In an era of multicore and aggresive optimizers microbenchmarking is moot.

--
Wojciech S. Czarnecki
^oo^ OHIR-RIPE

[Sokolov Yura]

Can you measure with sleep after sprintf (both in .Net and Go version)?
Let it be sleep for 1 millisecond. Or 500 microseconds.

[Sokolov Yura]

Doesn't it possible that .Net optimize out string formatting at all? Cause it is never returned and has no side effect.

Doubdtfully Go will optimize out fmt.Sprintf.

Anyway, I think .Net core garbage collector just more efficient for extremely short living objects. Does it has as short GC pause as Go for huge heaps?

[Sotirios Mantziaris]

Since i don't know if "dotnet run" does optimize code, you may got a point there. changed the code to return a string from the function and use Task<string>. 

Result:

dotnet run 1000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 1000000

Task 961 done!

1000000 in 00:00:01.1604266

Still much faster than go!

[Jan Mercl]

On Sun, Oct 9, 2016 at 10:37 AM Sotirios Mantziaris <smant...@gmail.com> wrote:


> Still much faster than go!

That basically compares the cost of creating like 4 threads to creating 100k goroutines.

--

-j

[Sotirios Mantziaris]

Tasks are run on the thread pool (i mentioned this) which contains a lot of threads (i dont remember the exact number, which is based on the cpu cores plus something). 

And i was comparing the concurrency framework with all the bells and whistles and not tasks and goroutines directly.

From what i understand goroutines are not threads either. There is a manager that handles which one runs on which thread, just like the implementation of .net.

[Jan Mercl]

On Sun, Oct 9, 2016 at 11:06 AM Sotirios Mantziaris <smant...@gmail.com> wrote:

> From what i understand goroutines are not threads either. 

That's the whole point for the original claim. there's not way .net could ever cope with 100k threads. If you want to compare apples to apples, the Go version should run only about GOMAXPROCS goroutines. Also, be sure to make some real work in the goroutine and collect and output its results (sum for example) to avoid optimizing it away.

Anyway, then the comparison would become that of picking a random task to run on a thread vs a full blown goroutine scheduler with the complete ready/running/wating state handling.

BTW: How are .net channels doing? ;-)

--

-j

[Sotirios Mantziaris]

I am waiting for the final implementation to check them out. Looks promising.

--

Kind Regards,

S. Mantziaris

[Sokolov Yura]

Here is results for my version https://github.com/funny-falcon/headon
I utilize results by computing hash and summing it it main thread.

.Net still faster and uses less memory. But not dramatically faster. But dramatically less memory.

It is pitty.

Here is results for .NET:

headon/parallelism/dotnet$ /usr/bin/time dotnet run -c Release 10000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 10000

10000 in 00:00:00.0110531, hash = 0xb64c05b4

0.62user 0.07system 0:00.58elapsed 119%CPU (0avgtext+0avgdata 66744maxresident)k

0inputs+48outputs (0major+17542minor)pagefaults 0swaps

headon/parallelism/dotnet$ /usr/bin/time dotnet run -c Release 100000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 100000

100000 in 00:00:00.0846664, hash = 0x829de33c

0.70user 0.06system 0:00.67elapsed 113%CPU (0avgtext+0avgdata 66776maxresident)k

0inputs+48outputs (0major+20086minor)pagefaults 0swaps

headon/parallelism/dotnet$ /usr/bin/time dotnet run -c Release 1000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 1000000

1000000 in 00:00:00.9544900, hash = 0xde68528c

1.57user 0.12system 0:01.57elapsed 107%CPU (0avgtext+0avgdata 124912maxresident)k

Here is for Go using channel for result passing:

headon/parallelism/go$ /usr/bin/time go run main.go -tasks 10000

Task to execute: 10000

10000 in 54.893915ms, hash = 0xb64c05b4

0.34user 0.03system 0:00.21elapsed 177%CPU (0avgtext+0avgdata 30120maxresident)k

0inputs+2464outputs (0major+17786minor)pagefaults 0swaps

headon/parallelism/go$ /usr/bin/time go run main.go -tasks 100000

Task to execute: 100000

100000 in 568.61465ms, hash = 0x829de33c

1.85user 0.12system 0:00.76elapsed 260%CPU (0avgtext+0avgdata 268676maxresident)k

0inputs+2464outputs (0major+77815minor)pagefaults 0swaps

Project/headon/parallelism/go$ /usr/bin/time go run main.go -tasks 1000000

Task to execute: 1000000

1000000 in 6.251455405s, hash = 0xde68528c

18.74user 1.17system 0:06.52elapsed 305%CPU (0avgtext+0avgdata 2708028maxresident)k

0inputs+2464outputs (0major+668978minor)pagefaults 0swaps

And Go result with using array for result passing and sync.WaitGroup for synchronisation:

headon/parallelism/go$ /usr/bin/time go run mainwait.go -tasks 10000

Task to execute: 10000

10000 in 9.313603ms, hash = 0xb64c05b4

0.19user 0.02system 0:00.17elapsed 127%CPU (0avgtext+0avgdata 30356maxresident)k

0inputs+2472outputs (0major+14299minor)pagefaults 0swaps

headon/parallelism/go$ /usr/bin/time go run mainwait.go -tasks 100000

Task to execute: 100000

100000 in 581.959038ms, hash = 0x829de33c

1.96user 0.12system 0:00.75elapsed 277%CPU (0avgtext+0avgdata 230132maxresident)k

0inputs+2472outputs (0major+69227minor)pagefaults 0swaps

headon/parallelism/go$ /usr/bin/time go run mainwait.go -tasks 1000000

Task to execute: 1000000

1000000 in 6.258064822s, hash = 0xde68528c

18.75user 1.26system 0:06.54elapsed 306%CPU (0avgtext+0avgdata 2784356maxresident)k

0inputs+2472outputs (0major+686800minor)pagefaults 0swaps

воскресенье, 9 октября 2016 г., 12:17:51 UTC+3 пользователь Sotirios Mantziaris написал:

[Sokolov Yura]

Finally made Go fast and not so memory hungry! :-))))

 

Using one buffered channel per result: https://github.com/funny-falcon/headon/blob/master/parallelism/go/mainmulti.go

 

headon/parallelism/go$ /usr/bin/time go run mainmulti.go -tasks 10000

Task to execute: 10000

10000 in 9.948716ms, hash = 0xb64c05b4

0.20user 0.02system 0:00.18elapsed 130%CPU (0avgtext+0avgdata 30748maxresident)k

0inputs+2464outputs (0major+13034minor)pagefaults 0swaps

headon/parallelism/go$ /usr/bin/time go run mainmulti.go -tasks 100000

Task to execute: 100000

100000 in 149.616735ms, hash = 0x829de33c

0.67user 0.06system 0:00.32elapsed 227%CPU (0avgtext+0avgdata 60592maxresident)k

0inputs+2464outputs (0major+28922minor)pagefaults 0swaps

headon/parallelism/go$ /usr/bin/time go run mainmulti.go -tasks 1000000

Task to execute: 1000000

1000000 in 1.537953634s, hash = 0xde68528c

5.31user 0.46system 0:01.72elapsed 334%CPU (0avgtext+0avgdata 384608maxresident)k

256inputs+2464outputs (1major+125570minor)pagefaults 0swaps

воскресенье, 9 октября 2016 г., 12:47:48 UTC+3 пользователь Sokolov Yura написал:

[Sokolov Yura]

It looks like .Net version never uses more than 1 core.

If I made hash function slower, .Net version starts to be slower.

Within 1 core there much less to synchronize.
How can I increase number of cpu core used for default Task queue?

[Jan Mercl]

On Sun, Oct 9, 2016 at 11:47 AM Sokolov Yura <funny....@gmail.com> wrote:

> .Net still faster and uses less memory. But not dramatically faster. But dramatically less memory.
It is pitty.

The code is not making a reasonable comparison because it creates N goroutines. It should create only GOMAXPROCS goroutines and use no channels and use no WaitGroup. Then it would be roughly equal to what .net does.

But we are already far away from what was my point. Nevermind ;-)

--

-j

[Sotirios Mantziaris]

You are adding the hash calculation to the mix which skew the results, but the end result is the same.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/_6K8SpMFsTM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sokolov Yura]

> The code is not making a reasonable comparison because it creates N goroutines. It should create only GOMAXPROCS goroutines and use no channels and use no WaitGroup. Then it would be roughly equal to what .net does.

> But we are already far away from what was my point. Nevermind ;-)

I've tried to get close to it with version "channel per result", see my message above.

And we are measuring typical way to do coding. Only few people in a world will copy same internal construction .Net uses.

Fixed code for .Net, so it uses more CPU cores.

Now it uses more CPU, and Go version "channel per result" now looks not bad compared to.
New results:

headon/parallelism/dotnet$ /usr/bin/time dotnet run -c Release 10000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 10000

10000 in 00:00:00.0216859, hash = 0xb64c05b4

0.67user 0.05system 0:00.58elapsed 124%CPU (0avgtext+0avgdata 65364maxresident)k

0inputs+48outputs (0major+18283minor)pagefaults 0swaps

headon/parallelism/dotnet$ /usr/bin/time dotnet run -c Release 100000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 100000

100000 in 00:00:00.1708238, hash = 0x829de33c

1.01user 0.09system 0:00.78elapsed 140%CPU (0avgtext+0avgdata 66756maxresident)k

0inputs+48outputs (0major+26606minor)pagefaults 0swaps

parallelism/dotnet$ /usr/bin/time dotnet run -c Release 1000000

Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Task to execute: 1000000

1000000 in 00:00:01.6099377, hash = 0xde68528c

4.46user 0.19system 0:02.17elapsed 214%CPU (0avgtext+0avgdata 128232maxresident)k

0inputs+48outputs (0major+61664minor)pagefaults 0swaps

[Wojciech S. Czarnecki]

Dnia 2016-10-09, o godz. 02:06:01
Sotirios Mantziaris <smant...@gmail.com> napisał(a):

Excuse me for a bit of 'ad personam' tone, it is not meant to be mean.

> And i was comparing the concurrency framework

You did not though.

> with all the bells and whistles

But your code used none. [e.g. custom data passed to .net task]

Your present microbenchmark code at most compares malloc and printf
implementations (and .net optimizers). In fact it is not even
concurrent: https://blog.golang.org/concurrency-is-not-parallelism.

In simplest words: concurrency is all about doing usable things in
one task while other one awaits for some (slow) things to happen.
The pseudo-parallelism is just a byproduct.

If you really want to compare _speed_ of the products of two compilers
you need to compile the same code with both. It is easy.

But if you really want to compare _speed_ of the products of two compilers
of different PLs you need to implement the same heavy concurrency in both PL.
This is not that simple goal. Sometimes it even is not achievable (ie.
in comparing java vs. erlang).

> From what i understand goroutines are not threads either. There is a
> manager that handles which one runs on which thread, just like the
> implementation of .net.

Unlike .net Task every goroutine is given its own stack from the creation
time. So it is prepared to do some real work just in time it will execute.

DotNet, by specification, may even use a single task instance: "The number
of Task instances that are created behind the scenes by Invoke is not
necessarily equal to the number of delegates that are provided. The TPL may
employ various optimizations, especially with large numbers of delegates."
[https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110).aspx]

If you still want to compare PLs, do reimplement some (heavily concurrent)
real solution avaliable in golang ecosystem in C# (you do know intimately)
Then you might compare both in production.

[Sokolov Yura]

Oh, in fact Go version is now faster :-) (look results above)

But uses more memory.

воскресенье, 9 октября 2016 г., 13:22:18 UTC+3 пользователь Sokolov Yura написал:

[Sotirios Mantziaris]

You are correct about the concurrency, no hard feeling. thank god this was no tech interview! ;)

BTW i just found this 

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=go

It looks like .net core seems to be comparable to go (and better in some cases). And it is only preview 2!

My general feeling .net core which is not statically linked can hold its ground very well!

This was unexpected for .net and unfortunate for go (which will get better with their improvements in GC etc). 

[Henry]

Go is a relatively small language, so it should be easy to learn especially if you are already familiar with other programming languages. Go's binary generation is also pretty good and it gets better with each release.

The major hurdle of a .net shop switching to other platform/language is usually the non-technical ones. A typical .net shop usually have a significant investment in .net and the tools around it. Moving to another language (eg. Go) often means throwing away those existing investment.

[0xc...@gmail.com]

I have been managing Windows based environments for well over a decade and .Net is one of the most slowest stacks I have ever seen.

That being said, I just finished configuring ASP.net Core Module on IIS (it's just been released) for a client and it's still dog slow (particularly the app startup in IIS).

Not to mention the single core limitation.

Microsoft has been recently seen jumping into OSS bandwagon by releasing VS Code, the .Net Core, Powershell for Linux and native Linux containers for Windows. Seems like they are desperate to get into this market, which they had been blatantly ignoring for many years!

Looking at "Fast" description at https://www.microsoft.com/net/core/platform, I can see how Microsoft is concocting lies to up-sell their product. These are same people who once accused OSS community as communists ;)

Like Henry said, Microsoft toolchain is only good if you are stuck with its existing investment, just like StackOverflow etc.

To me, it's all the baggage that comes with the stuff they keep renaming and reinventing.

[Sotirios Mantziaris]

I do not agree with the above. Let me explain:

• First of all asp.net core and it's new web server kestrel should be used behind nginx or similar. Hiding it behind IIS is slow because of IIS and not because of kestrel. Check out the new https://www.techempower.com/benchmarks... which show not the best, but not the worst either... No 10 in the plaintext category is pretty good if you ask me...
• I don't even know to what you mean by saying single core. Are you referring to .net? IIS?
• The people that once called OSS community communists are not in charge anymore...  It's like saying that German's are by default bad because of you know who i mean...
• First Microsoft is closed source, evil corp etc and people where angry... Then MS goes almost full blown open source embraces almost everything and still people are angry... Conclusion, people are angry anyways.
• Not every .Net Developer use only the MS toolchain, and with core you can use anything a go/java/ruby developer uses... 

My personal note is the following: 

MS does not have the best stuff around... but they have a pretty good understanding of creating good developer tools and boost productivity

If you have used Visual Studio and Sql Server Management Studio then you know what i mean.

This is where, for my taste, go has a lot to learn ... and BTW i use Visual Studio Code for my go development with delve as debugger. The next Visual Studio will support go natively...

Things are getting way better for us devs and this is a win-win situation.

[Golden Ratio]

So basically what you are saying is that we need another OSS tool to fix sluggishness in current Microsoft toolchain? 

No, thank you :) The next generation app developers would just like to avoid the sluggish part and the slow operating system altogether :) 

Well, we all know why Microsoft is all of a sudden in OSS frenzy. They want to profit from it. Not that anything is wrong with it, but this is their only goal. 

Best stuff around and you refer to VS Code? They just copied the core parts from Atom's Electron without contributing anything back. 

[Sotirios Mantziaris]

• I did not mention windows at all... so what's with that???
• And about the profit? they allow you to run your code on Linux and MS does not get a dime? The point is that you can develop .net core and don't pay anything to MS.
• Yes VS Code is based on Github's electron framework, which is used by many others which may not contribute either.
• Electron is also based on node, chromium, v8 etc...

I think we should stay on topic which is .net core vs go and contribute to the discussion.

[Golden Ratio]

I think you are being naive. You don't pay in terms of running the code per-se, but to get other parts of their toolchain that generally go together with the whole baggage, e.g. MSSQL, OS, support, updates, etc. That's the whole point.

This would take the conversation in another direction and then you'll complain again. The point here is that the .Net stack is still very slow, whether you admit or not because I have seen it a million times ;) 

[Dave Cheney]

I think this discussion has served its purpose with respect to what this Go discussion forum can provide. Please conclude this debate.

Thanks

Dave

[Sotirios Mantziaris]

I am currently moving one of my applications to .net core. Currently i use Redis for caching, PostgreSQL and Nginx. All run in Linux except my Rest Service which runs in Windows.

After the move to asp.net core i will host the application in Linux, probably docker. Could you point me to the one place where Microsoft will make money out of this?

My point is that you assume that every .net developer use by default Sql Server, IIS etc but that is simply not true. 

Check out the https://www.techempower.com/benchmarks/. This has nothing to do with admitting it or not. check some facts.

Check out http://web.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/ which is a implementation of a MMO Game which run on asp.net core and windows server 2016 nano.

I know it will not make any difference to you so i will conclude the debate as pointed out by Dave Cheney. 

Thanks

On Wed, Nov 16, 2016 at 10:51 PM Golden Ratio <0xc...@gmail.com> wrote:

I think you are being naive. You don't pay in terms of running the code per-se, but to get other parts of their toolchain that generally go together with the whole baggage, e.g. MSSQL, OS, support, updates, etc. That's the whole point.

This would take the conversation in another direction and then you'll complain again. The point here is that the .Net stack is still very slow, whether you admit or not because I have seen it a million times ;) 

--

Kind Regards,

S. Mantziaris

[visua...@gmail.com]

Good show. Being a lone warrior.

Some hate Microsoft so badly for no apparent reason while they seem to love Apple ! :) There is no reason for such hatred - given their love for Apple or even Google.

.Net Core is solid and Go feels totally "incomplete" to me. You cannot model an abstraction that easily - and am not sure how well it goes for mainstream enterprise software development. The problem is "fanboyism". The OP is a "fan" of Go and hence wants the Company to develop in Go. This is precisely the problem in the OSS world. 

They have "staunch" ideologies and their choice of technology is based more on the "ideology" rather than technical grounding. They then invent technical reasons to justify their ideological choice. 

This is precisely why I don't take opinions from hardcore OSS guys that seriously (Read - the typical "Microsoft" hater).

.NET Core is blazing fast. If Go had not been there, probably it would have been the natural choice for all the devs now. Go provides an option and for that reason it is good. There is nothing "unique" or "exclusive" in the language. GoRoutines are not exactly OS Threads. GoRotines are scheduled by Go runtime. .NET Core Task<T> is not exactly a thread either. It is controlled by IOCP on Windows (not sure how they implemented for Linux). .NET Core's threading model is extremely solid and battle tested.