Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew that when we signed up.
It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node.
I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.
"We are still staying with Python"
"Clojure still works great"
"Erlang backend still runs after 10 years"
"Node.js router still runs ok"
Those don't make compelling HN front page article. So if you read HN the impression is everyone and their grandmother is switching to <LatestFad>
This doesn't make Go a silver bullet. (So don't make that mistake, please!) It just happens to be the right kind of tool for two of the more salient problems right now.
I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming.
There is no silver bullet, polyglot concurrency is the future most likely.
Apart from that JavaScript is brilliant. Few other languages can match it's simplicity.
Python falls through because it doesn't have real lambda.
If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all the niceness of Javascript but almost none of the bad stuff. I say this as someone who is primarily a Javascript developer professionally.
Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP), but there are many that are much better. It's worth noting that everything that is good about Javascript already existed in other languages before Javascript got invented. In fact Brendan Eich has stated that his intention was to create Scheme for the browser. If only he had just used Scheme as it existed, things would have been so much better!
No it doesn't. Been using it for about 10 years can't remember being bothered by lacks of "real lambdas"
> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.
If there would be minor detail we wouldn't have had the "Good Parts" book. And trying to deals with variables in Javascript is pain, var vs no var, what does this do. Really strange weak typing rules.
Adding [] to {} should not produce some random value (what is it NaN or Object), it should throw an exception.
> Few other languages can match it's simplicity.
Wait, were you being sarcastic?
If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.
Python doesn't have real lambda, who cares? That may or may not matter to you, it mostly doesn't matter for me, most of the time.
You've directly commented on a post about how understanding the context in which you use your tools is the crucial factor by totally ignoring the point.
Defaulting to doubles and not having native integral types is not a "minor detail".
True. What it does have though is real closures. Local function definitions with a proper name, capturing lexical state, usable as first class objects. This is a usable replacement for real lambdas, in much the same way functions are used as a replacement for just about everything in Javascript.
There are so many things in Python that have real syntax and language support, and that are lambdas upon lambdas upon lambdas in Javascript.
> Not looking at Go yet? It may be a good time to do so now — everybody else is.
That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat".
Personally, I thought Node.js was a terrible platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example).
Likewise, people will now order their projects in Go whether it makes sense given the requirements or not. 20 years of Go experience will be needed on CVs. And when Go inevitably fails at certain things, "everybody" will move to the next thing - probably Rust, thereby completing the migration away from dynamic scripting.
This is not reasonable, is it?
TJ's blog post is basically like if DHH ditched Ruby/Rails for Go.
> Personally, I thought Node.js was a terrible platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example).
Totally agree with you,nodejs is not a silver bullet.
That happened. So did lots of other stuff. Same as it always was.
And not just because you'd be unfashionable, but because a lot of crucial libraries in these ecosystems will loose maintainers. The Node guy said the other day that (out of his hundreds of libraries) "Koa is the one project I’ll continue to maintain".
If I had any of his packages in production I would be terrified. The fact that he (and other "Node guys") are driving the hype train to Go tells me that I should stay as far from it as possible.
Maybe some ecosystems are much more about the people leading them than they are about the technology behind them. And while this is not something I'd be interested in as a developer, I understand how there could be huge benefits in that kind of lifestyle. I imagine that's a very supportive, creative, and active community to be in.
Looking at some (mis-)uses of Node, maybe that's been the rationale behind some of these frameworks all along. And indeed the first image on the page is of a marching band...
Well "why did you pick this technology?" question is a good way to find out who are you talking to. If they say "webscale" and "callbacks are this new concurrency paradigm" then well, I might not form the best opinion about them.
I suppose it depends on what you are trying to do - if it is looking good to those with fashion sense - better get down them shops. If it's to like, actually build stuff - the feeling of being uncool because of what language you use is a massive distraction to ignore.
I've been learning Go because its a great language for concurrent server systems (and better than node in some areas).
That I feel slightly cooler because of that choice feels a bit like having the right daps (sneakers) at school.
Maybe I don't have any programming talent at all, but I cannot even imagine to rewrite a 'large distributed system' in a week. The not-too-large distributed systems I worked with had years of thinking behind them, I could not even type in the characters of the code in a week.
https://github.com/visionmedia http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
I'd be curious to know how many start ups prototype their first software version with Go.
Note : as a coder that writes a lot of python, seing dropbox switch to Go in parallel to python so often having toxic discussions about python 3 vs 2 is really painful.
There are other reasons C++ developers might have to switch to Go; that's what Rob Pike was referring to when he said that he was surprised that Go wouldn't replace C++. He didn't mean that Go failed to replace C/C++ as the target of optimization from slower languages, but failed to replace C/C++ for those who were already using it.
Go has been explicitly designed to avoid the perceived pitfalls of C/C++ from their experience at Google. It's not a language that fixes C++ like D or Rust, but tries to get to the root of the problem, and the problem they identified was complexity.
I've just been rewriting a thing that was in a monstruous mixture of PHP/Python into a single Go program.
I wrote C modules here and there. Used cffi, that works great so far.
The thing is that those that don't switch languages usually don't write blog posts and those don't end up on HN (sorry for repeating it, I've already mentioned this in a sibling post). So the impression is that that's it Python and Node.js is dead, we should switch to something else.
Presumably in 2 years we'll see "We are switching from Go to <Rust|SomeLispThing|Swift|OtherNewThing>" posts. It won't mean Go won't still work well.
As for 2 vs 3. Yeah I am in the naysayers for 3. Sorry, for fueling the flames. But from my perspective it came too late and it didn't have enough benefits (or rather 2 didn't have big enough warts) so it ended up being very painful. I still plan on staying with 2 for now. We'll see if 3.5 or 3.6 bring about better tempting features and more 3 library ports get stabilized.
Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family.
So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwards.
Regarding Python, I never saw it more than a scripting language for system administration. ML based languages provided a better experience in terms of both performance and productivity.
The languages you list really suck compared to Go. They are ridiculously verbose. Goroutines in particular are really quite nice.
In no universe does Go feel like it's a "bit backwards", and I think you're trying to speak for a group without their input.
Indeed, an implementation I regularly use now is high performance algorithms in C++ (the Intel vectorizing compiler is superb) to function libraries, Go/cgo as the extremely efficient, very easy to write and maintain orchestration/manager.
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
[1] https://tech.dropbox.com/2014/04/introducing-pyston-an-upcom...
[1]: https://tech.dropbox.com/2014/07/open-sourcing-our-go-librar...
FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
The pros are of such value that they more than compensate for the cons: first class facilities for building concurrent programs and distributed systems. These are language features such as go-routines and channels and standard library includes for networking and RPC.
These are so great at what they do that they make programmers like me, who like Go, overlook the suck that comes from the existing typing system.
My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.
I see this repeated again and again. It's wrong.
The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type.
People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.
Erlang is dynamic and has all those features :-)
It's true that the GIL in Python prevents interpreter threads to run simultaneously. But for many use cases it's OK to use gevent or multiprocessing (which share the same interface!). Channels are there in the form of queues, but there's no built-in support for selecting from multiple queues. To emulate that, you need an extra greenlet for each queue.
Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, and another step up from Go in terms of all the facilities for fault tolerant and distributed programming.
Clojure is dynamic and has goroutine and channel constructs through core.async.
* benefits of static typing at low cost to the programmer thanks to type inference and duck-typing,
* intuitive and easy-to-use concurrency model based on channels and go routines,
* functions as first-class objects,
* very good performance,
* clean, concise and simple syntax,
* novel, low-overhead approach to build configuration based on the convention-over-configuration principle (your import statements express all there is to know about how to build your software),
* garbage collector.
I'm sure I forgot more.
In other words, you have been reading about it, but never tried to learn it.
Go is incredibly easy to learn and prevents bugs and cruft as much as possible, makes writing documentation and testing painless and has good performance and concurrency support.
It also has a friendly, practically-minded community.
Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.
Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway.
It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity.
> be pretty ugly and painful
Subjective. I like how it looks and have no pain.
> compared to javascript I can see the advantages though
It is not just "better than javascript". It is as expressive as ruby or python, with as much type safety as possible without giving up clarity or speed. And its type system doesn't require weeks to wrap your head around it.
Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations.
Is this supposed to convince C/C++ programmers? Like "sure your program will run 50% slower and have garbage collection pauses, but it compiles faster!". This just boggles my mind.
I like Go too, but lets not kid ourselves here. Ruby is vastly more expressive than Go. (I'm sure Python is too, but I am not a Python programmer, so I am not in a position to say).
"Getenv returns the empty string and continues. Then Go somehow manages to parse the empty string as an empty JSON list and still continues. Then it tries to interpret the first of the user arguments to the program as the path of the program to run and execs that instead! Utter failure."
I happened to write about it just before Go came out here: http://yosefk.com/blog/what-makes-cover-up-preferable-to-err...
It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage (as in JS's "undefined" string produced from undefined values and propagated, or Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it predates Lisp's exception handling features whereas AREF was added later and indeed complains loudly, etc.
Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration.
Exceptions force API designers to decide whether or not a situation is exceptional enough to force a stack unwind on the caller's end. That's not something that's necessarily decidable from the point of view of the library.
For instance, say you have a function http.get(url). Should a 404 response automatically raise an exception? What about a 301? A network issue? Surely, for a crawler, a 404 is not exceptional enough to merit a hidden goto that unwinds the stack frame (by default). The designer of the http library cannot decide which status code is exceptional in every application.
It's similar with the results of SQL statements, file system access and all sorts of other IO related stuff.
It seems to me that the more complex a system is, the more it needs a very specific error handling strategy anyway and doesn't benefit from library designers' opinions about what is and isn't worth a stack unwind.
That said, I do hate seeing
if err != nil {
return nil, err
}
In my recent experience, it actually bothers me a lot that funcs in the standard library would often rather return nil or the zero-value of a type than change the signature of the func to return (T, err). I don't really care that the docs describe that behavior -- that behavior is an error.
You didn't cite that quote. I am certain whoever said it is doing something silly.
I am using Python daily, and pretty much all performance problems (with my work) can be solved at the database or caching level. I get the impression that Numpy can produce reasonable performance for numeric problems.
In my experience developer productivity is of far more importance to business than language performance (obviously that depends on your domain). I do get asked to speed things up. But I get asked for "something working" by yesterday far more often.
Sadly it doesn't have the advocacy and hoard of developers supporting it and writing libraries for it. Certainly no big company with billions of dollars of revenue. It is unfortunate.
I feel like Google should have just taken it and used it as Go back then. I would have been a good choice.
There is also GNOME's Vala language. More focused on GLib but the idea is the same. C# like language compiles to C. Good performance. But again kind of fringe.
This "fringe-ness" in longer term translates in less libraries/frameworks. With Python if I am starting on something new, I know I can probably find someone that wrote a library related to it. Scientific computing, AI learning, graphics, GUI bindings, http parsing, WSGI middleware, strange protocol parsers, libraries on top of C libs (parse .pcap files) and so on. All are just one search and download away.
With Nimrod (or any new language) I am afraid I would be writing those by hand.
They certainly do, but have we solved the problem of statically linked bugs yet? What happens when the next heartbleed happens?
With a bug in such a central place you'll have to touch everything - could as well rebuild everything, when your processes are prepared for it.
More importantly, I hope the Node community's self-centred "holier than thou" doesn't bleed over, given that Go has (at least so far) kept a fairly high standard of discourse.
That said, I, for one, welcome more contributors to the Go ecosystem. It is a good systems programming language, but it needs a few more "horizontal" libraries to make humdrum tasks (like parsing, accessing databases, etc.) more palatable.
(edit: removed incorrect double negative)
- Lack of decent IDE with intellisense/good refactoring support.
- Libraries seem to be globally shared between projects like rvm rather than in the project like nvm.
Am I wrong, misguided or out of date on these things?
> Lack of decent IDE with intellisense/good refactoring
> support.
> Libraries seem to be globally shared between projects
> like rvm rather than in the project like nvm.
I am aware it is powerful and has as many features as an IDE but seems like it will take a fair bit of time to learn (on top of learning a new language). Eclipse is fairly intuitive by comparison.
Packages are shared across projects in the same gopath, you could run separate gopaths for isolation.
Libraries can be vendored in many ways(virtualenv(gopm), bundler like patching env(goop) or simply by manipulating GOPATH)
https://www.digitalocean.com/company/blog/get-your-developme...
Also:
http://peter.bourgon.org/go-in-production/#dependency-manage...
More discussion:
Haskell's Hackage seems to be full of broken packages.
OCaml seems to be stuck in 1999.
F#/Mono is pretty great, but tough to find quality libraries that work with the tools I use (postgres etc)
Anything I'm missing?
Do I use this thing? http://ocsigen.org/ocsigenserver/ All the docs either don't do what I'm looking for (i.e set up a web server to serve some static files) or are broken links!
OCaml is actually what I'd prefer to use (since I had a blast with SML/NJ)
I'll check out that book, thanks! But I did just skim the ToC and it has nothing about serving HTTP. Serving HTTP is like my #1 use case for anything these days :/
Citation needed. Hackage goes to great lengths to validate packages as much as possible. Other support systems do continuous integration and further validation, if you're looking for well regarded package subsets.
Maintaining 6000+ open source packages is a pretty serious task.
All I want to do is serve an HTTP request.
Edit: I don't think there's anything like type classes either but I'm not 100%.
I'll be gladly left behind.
And rewriting everything from scratch, plus it's a given that node isn't the best tool for data processing..
Node.js is becoming mature, less trendy. I really find it weird how people compare it age wise with Go. JavaScript is way old than Go or other languages. V8 is also older than Node of course. ECMAScript didn't have breaking changes in a really long time. There are many, many implementations. SpiderMonkey has been used on the server side for over a decade now.
Go looks great. There are some rough edges though and whether really good solutions will build up for these things is a really interesting thing to look at.
It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of them fixing problems in amazing ways. I love how great concepts, like node.js streams and pipes are copied to Go and Rust in ways that match their styles, not just blindly.
All these things even influence languages like Java and C++. Who would have known only a couple of years ago that things would emerge in such ways and that it needs some projects with the idea of yet another programming language. What is even more interesting is that a lot of concepts actually stem from Perl... well, not necessarily the language itself, but libraries, modules or Perl6, which arguably was/is a really ambitious research project. It's a bit how many concepts took ages to be ported from Plan 9 to other operating systems.
Anyway. It is great to see how people nowadays look at other projects and don't judge by first impression anymore.
At least it seems like it. Node.js looked extremely awful to me in the beginning and turned out to actually not be (despite its shortcomings and JavaScript, which also turned out to be nicer). On the other hand projects, like Meteor that looked at least okay in the beginning turned out to be way more awful than they looked when I first heard that they don't even support proper REST.
I know, my opinion on this might not be really popular, but it's amazing to see how so many new concepts emerge, even when they seem crazy, sometimes turn out to be crazy, sometimes turn out to be amazing. It's hard to know where we will stand in a couple of years. However, I don't think only one of Rust, Go or Node.js will make the race and I think none of them will look like they do today in one or two years, especially when it comes to their ecosystems. Just because all of them are too young to be judged upon and all of them are changing too rapidly (or new standards are upcoming, as with ECMAScript), so that nobody really has or can develop a deep understanding of the language/framework yet, not even its developers.
What I really hope though is that there will soon be more big projects than just Docker and a bigger ecosystem.