Hacker News Reader

Comment by cincinnatus | Hacker News Reader

Sounds like a list of C# benefits. In 2004.

Except for the goroutine and channel, and the type system, and the package system.

Ah you mean Task Parallel Library and NuGet?

I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec.

Goroutine + Channels are vastly different than the TPL. The comparison is so far off that I can't even come up with a clever analogy. There's more to concurrency than threads, and more to communication than locks.

> I didn't realize NuGet let you do remote path import. Nor that it was around in 2004. Nor that it's part of the C# language spec.

Fare enough if you want to limit yourself to 2004 and compiler specific support.

> Goroutine + Channels are vastly different than the TPL

If you take out your Go coloured glasses and read in what TPL does, you will see that what Goroutines and channels are indeed available as Tasks and Queues.

I don't know enough about Go, but Goroutines and Channels sound quite similar to F# agents and mailboxprocessor concepts, which as I understand is not quite the same as TPL. The former tackles concurrency, while the latter is about parallelism. C# 5 is getting there with async/await concepts I guess.

Here's a dining philosophers implementation in F# and Go (among other languages)

http://rosettacode.org/wiki/Dining_philosophers

Well, 'package' system is a big word. It does not have versioning, checksums, or signatures. An import of a package may bring in (1) a version that is API-incompatible; (2) a version that is API compatible but has new bugs; and (3) a version that has been trojaned/backdoored/whatever.

The only solutions is doing your own package management in $GOPATH, tracking a bunch of Git/Mercurial repositories and finding out by hand which commits are sane and which are not.

It's a disaster in the making, really.

C# doesn't build native binaries on all platforms out of the box.

Like any other language.

Don't mix a language with the available implementations.

You can get native binaries with ngen or mono -aot.

The dependency on CLR is no different than relying on libc being available when using dynamic linking.

Its what was left out of Go that makes it great ... e.g. most or all of the Go benefits could probably be recreated in C++ using libraries, but that doesn't make C++ equivalent or as nice as Go for developing in.

C# has a dependency on the CLR, i.e. either the .NET framework or Mono has to be installed.

Implementation != Language

You can't use the language without the implementation. They're bound together. Unless you're suggesting someone's going to write a C# compiler that creates native binaries?

ngen, mono -aot, bartok, IL2CPU ?

Reply on news.ycombinator.com