Many of us have .NET experience, really like C# but have sensible reasons for not recommending it. A Microsoft only stack is nowhere near as flexible as Linux and if you were to reach Stack Overflow's levels of traffic you'll not be able to avoid the need to run a part of your infrastructure on Linux. I seriously doubt Stack Overflow is running Redis, ElasticSearch & HAProxy* on Windows. Unless you already have a team proficient in .NET, there are few good reasons to use it instead of a JVM language.
Indeed we run all of these things (and more) on linux. We use the most appropriate architecture we can come up with at the time. When a better overall option appears, we do that. New information and technology makes our decisions change, that's how brains are supposed to work, I think.
We use linux for: redis, elasticsearch, HAProxy, DNS (bind), nginx, mail (exim) apache, wordpress, mysql, nexpose, backups, puppet, asterix, android builds and our internal mercurial.
As Opserver grows we will be monitoring Windows and Linux with our solution, but simple to setup via polling, or more advanced monitoring via an agent (puppet and DSC configurable/installable). We plan to have agents for both Windows and Linux open sourced, both using a standard communication format so that anyone can write additional agents, or add to them, or...whatever really. We haven't started building this yet, a complete monitoring solution is what we'll be working on over the next 6-12 months. It will be in the open as we go, with lots of internal dogfooding to prove things out.
I imagine that 99% of the users on here won't work on any projects that receive the same levels of traffic that Stack Overflow will get, and as such the worries of scaling to this level aren't really an issue.
For the vast majority of websites that developers will build, the .NET stack is absolutely fine. My only gripe with being a .NET developer is that if your professional experience is limited to a Windows based stack you may find it hard to move over to a Unix-based stack.
Just because you use c# doesn't mean your whole stack needs to be Microsoft. No reason why you could have Windows web-servers running asp.net/c#, but have postgres DB, nginx, memcache etc on linux. Azure seems to be actually encouraging this.
The cost of windows licenses for web-servers is not that much. Avoiding SQL Server is the big win in reducing cost.
All true but there is still quite a bit of inefficiency involved if you need a team that is both proficient in deploying & running Linux infrastructure tools as well as Windows servers.
And given that this discussion is taking place in the comments section of a link to a custom-made monitoring dashboard that quite possibly wouldn't be needed* if SO was a Linux-only shop doesn't exactly devalue my previous statement.
*I have no idea whether this could be replaced with Nagios or Munin
I imagine the Stackoverflow guys are familiar with Linux architectures, they also run the open source forum Discourse[1] which is a Ruby on Rails app that comes with a recommendation to set up and develop in a *NIX environment[2].
Certainly the point is to use the right tool for the job, and I wouldn't dismiss your final comment: having a team proficient in .NET is a great reason to build your tools with/for that platform.
But no, I don't think it would be fair to reply to this article saying "Why didn't they build this for [my preferred language]?"
This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack.
I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.
Sure. Go is pretty much a JVM-less Java. To me, it seems the exact wrong things to take from Java. Go takes the language (Go is a simplified Java, with some modern improvements) - which is only OK, but drops the JVM, which is awesome.
It does have one advantage over the JVM, which is a much shorter startup time. But Java has better performance and far better monitoring tools (as well as dynamic linking and hot code swapping).
I think calling Go a simplified Java is pretty far off the mark. Aside from both aiming at the niche of being sort of "medium-level" languages, for lack of a better term, Go's approach seems very different from Java's.
Objects vs structs and functions, exceptions vs multiple return values, required static vs required dynamic linking, implicit vs explicit subtyping/interfaces, etc.
Structs + interfaces in Go are a re-interpretation of Java interfaces (albeit a major one). It's a different path, but the same philosophy (dynamic dispatch over receiver type + mutable state).
Exceptions vs. multiple return values are two different local decisions made by Go's designers: multiple return values and lack of exceptions. Multiple return values are handy (might find their way to Java one day), but I would call that a feature, not a different approach. As for exceptions, it is my understanding that Go's designers haven't made a final ruling on the subject.
Static vs. dynamic linking are properties of the runtime (native vs. VM) rather than the language. In principle, both Go and Java could support either without any language changes.
Go is most certainly not like C, because C's philosophy is letting the programmer work at the same level as the CPU. Go, if anything, is further removed from the hardware than Java (no explicit control over threads or scheduling, no access to memory fences).
I was mostly referring to the style of programming the languages encourage. Things like multiple return values instead of exceptions are extremely significant in what they imply about how you're intended to code in the languages.
Go tends to be written like a low-level language with very good high-level libraries. You don't have huge class hierarchies; instead you have functions. You don't have a million custom exception types; you just return error codes. Go is obviously closer to Java with respect to some of the things you can do with those concepts (things like switch statements being very general are features of much higher level languages than C, etc.), but as a programmer, you're still writing a switch statement, not a series of polymorphic methods dispatched at runtime. That's what I mean -- Go is very, very unlike Java if you're writing idiomatic code in each.
Not so! Go explicitly exposes indirection, while every Java object is a pointer. The result is that control of what is in L1 with Java is impossible, while memory locality can be forced in Go.
Struct arrays are sorely missing from Java (hopefully they'll be included in Java 9), but other than that, an object is allocated contiguously in memory. In fact two objects allocated by the same thread one after another will be allocated contiguously, so "inner" objects allocated during objects construction will be adjacent to the original object.
Go's designers have said that they wanted to experiment with a more direct approach to memory in exchange for a less advanced GC.
So, you are right that in terms of memory placement issues, Go is more low-level than Java, but it's higher level when it concerns scheduling. All in all, it places them pretty much at the same level. It certainly doesn't make Go closer to C.
I'm learning Go right now by writing a small part of my current project in it. I like it quite a lot (mostly for its concurrency features) but it is actually a surprisingly verbose language compared to Java.
First of all you have this on about every second line:
if err != nil {
return err
}
Method signatures are convoluted because you have to repeat the receiver type for every single method and add (actualReturnType, error) at the end.
Go:
func (MyType* mt) myMethod(s string, i int) (string, error)
Java:
String myMethod(String s, int i)
For functions you want to use in expressions you need a second one that calls the first one and panics instead of returning err.
You can't specify default values for structs, so you often need an extra function that constructs a default instance of the struct and initializes its fields.
And the lack of generics means you have to write a lot of things several times for different types.
Lambdas are very verbose as well. You get no type inference even in contexts where it would be simple to do:
Go:
filter(func(s string, n int) { return len(s) < n })
Java 8 (Scala is similar):
filter((s, n) -> s.length < n)
Function names often have to be longer because there is no function overloading.
Go's simplicity is a double edged sword. Lack of verbosity is definitely not its strength.
Obviously there are many counter examples where Java is more verbose than Go. But they are very well known by now so I'm not going to repeat them here.
It's not popular on HN for a reason. Even if you run everything on Mono, for practical reasons you are tied to Windows as a development platform and that's a major issue for just about anyone who does their development on other platforms.
Not really a fair feature comparison. If db migration wasn't in Rails, ActiveRecord wouldn't work the way it does. You can't say the same about Django's ORM.
I'd be more inclined to recommend VMWare for our in-office needs if I can conveniently move VMs off to an OpenStack supporting public cloud. VMWare's offerings are good enough to compete with any private cloud out there but not having any interoperability with what seems like the future of the open cloud could hurt them.
If you need to learn a framework then PHP loses simplicity, one of the few things its got going for itself. And if your needs validate the use of a framework, you'd probably be better off with RoR or Django.
*https://github.com/opserver/Opserver/tree/master/Opserver.Co...