5 ms·
I'd say we've got two different upgrade paths here. D is aimed squarely at the C++ crowd, so the biggest enemy it has right now is that C++11 is actually half-w
by mhd 14y ago
I'd say we've got two different upgrade paths here. D is aimed squarely at the C++ crowd, so the biggest enemy it has right now is that C++11 is actually half-way decent.
Go is a bit more difficult to pin down, demographic-wise, but I'd say it's a mix between C minimalists and Pythonistas and other scripters who want something faster but don't want to go with a JVM-language or go all the way down to bare metal.
This target group as well as Google's pedigree is why you're reading a lot about it at web programmer's forums (like, well, this one), consisting mostly of people who wouldn't (and couldn't) touch C++ with a ten foot pole.
- cageface 14y agoMy interest in Go has a lot to do with static typing. Dynamic languages are great for brewing things up quickly but static typing is just far too useful for catching dumb bugs early and for enabling powerful tooling. Perhaps more sophisticated type systems like those found in Haskell are worth the extra effort but my money is on Go for its simplicity and pragmatism.
- sausagefeet 14y agoThis is why I use ocaml. The type system power to simplicity ratio beats out all other languages I've come across so far.
- agumonkey 14y agoFor what domain ? how is performance ? open question, I'd like to have data beside the languageshootout benchmark.
- sausagefeet 14y agoI do it mostly for networking programs using Jane st a sync. Raw performance is great, on the language shootout it is on par with Go and getting better. For me it has replaced almost every language I would use except for the situations I need C.
- tikhonj 14y agoHaskell's type system may be sophisticated, but it's also very simple. There's no sub-typing of any sort, for example. With a bit of mathematical notation--which may be a little foreign but is not that complicated--you can fit all of Haskell's type inference rules on a single page. These rules specify how the type system behaves and how to infer types! (The type inference, which may seem magical, is just a constraint satisfaction problem and so is easy to specify.) I would not be surprised if Go's typing rules are more complex than Haskell's. All while giving you less static guarantees and less thorough type inference.
- sirclueless 14y agoHaskell has algebraic datatypes and typeclasses. Both of those are more complex than Go's type system, which is more or less just primitives, structs, and interfaces. Haskell's type system may in fact have fewer moving parts, but it has a LOT more emergent complexity than Go's does.
- dualogy 14y ago> Go is a bit more difficult to pin down, demographic-wise, but I'd say it's a mix between C minimalists and Pythonistas and other scripters who want something faster but don't want to go with a JVM-language or go all the way down to bare metal. I think it also appeals to those who first started out programming in Basic but quickly proceeded to Pascal and loved it. At least, that's it in my case. Pascal is the one I'd describe Go as being closest to -- but then I've never been a C programmer. As for Pythonists and scripters, not sure they'd ever be that happy in Go. A lot of their conveniences are "gone" in their experience. Such as custom yield iterators.
- pjmlp 14y agoI keep arguing against the missing support for generics in Go, but on the other hand I see it as a nice C replacement. And before someone answers me with the lack of manual memory management, Native Oberon and Blue Bottle are done in fully GC enabled languages with a little assembly for the boot loader and interrupt controller bindings. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager
- gillianseed 14y agoI don't understand why you continously want to pitch Go as a C replacement. In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact. What exactly are the areas of C use in which you expect Go to replace it?
- Evbn 14y agoSmall fast simple web apps. The point of Go isn't that it replace existing C programs, it is that Go appeals to C programmers who want to extend their rrach, it is that is reshapes C to fit in areas it didn't fit before (and, yes, to not fit in areas it fit before), without being as radically different as Java or Python or Haskell.
- 14y ago