From Node.js to Go
bowery.io
bowery.io
- The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see.
- I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.
- The tooling for Go is excellent: More languages need something like "go fmt".
- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...
- I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. The only issue is parsing JSON when you're not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier).
- Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.
Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B).
But really, this is a rather tired flamewar that gets beaten to death literally every time a post about Go makes the front page, and there's really nothing more that can be said about it. Either program in idiomatic Go, which means using the language as it's designed (ie, without generics, at least in its current form), or don't, but it's very tiresome to see this argument rehashed again and again.
[0] https://en.wikipedia.org/wiki/Continuous_track#mediaviewer/F...
Well, sure, I guess you can pound a screw into things with a hammer but you're missing the point.
1) Methods with names that indicate the parameter types. 2) Method calls on objects to convert some internal struct data from one type to another. 3) Something I haven't thought of that doesn't involve losing a handle on your type.
So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a functional language as far as I can tell. So, yeah, it isn't as intellectually elegant, but it also isn't really that hard to deal with.
The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically.
If you are still not convinced, one of the things you can do with generics is say "these two parameters have the same type". In Go the best you can do is say "these two parameters are subclasses of something", which is less precise.
You want to use different screws? You're on your own.
Sorry. In the spirit of Go, you're not allowed to re-use this analogy; you're going to need to write another different one that can perform a similar function.
It's ok if you copy and paste some of the text from the first analogy and structure it similarly, though.
Which would be just as bad as for a car, since the things that drive and guide a tank tread are wheels (drive wheels and road wheels.)
Go doesn't take any approach to writing generic code at all.
And then the code I've seen is littered with "interface {}".
That's a pretty big thing to give up, and I don't get the point. Something like F# gives you high level features (and green threads if you want) with fair perf, and Rust gives you a fair amount of language with C perf.
Analogies are almost always useless diversions, but this one is particularly ridiculous.
People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust). It is obviously working pretty well, and that "non-negotiable" point turned out to not be a showstopper.
A car without wheels? If we have to abuse analogies, more like a car with a manual transmission. People can have hysterics about how will they ever eat their burger while they drive, but somehow some people manage.
I have written hundreds of thousands of lines of Rust code for Servo, the Rust compiler, and other projects. Of course it's a less mature language, but people are building plenty of solutions, including production solutions, in Rust.
;)
I'm one of the people who is currently making a working solution in Go. Are generics the equivalent of missing wheels? Probably not, but I am absolutely finding it a present and persistent pain point that I don't have something like that or even just overloaded function/method signatures, and instead have to frequently repeat a lot of rewritten code scattered full of lots and lots of if/else cases.
Life could be worse. But the fact that people are shipping doesn't mean it's a language in which people aren't finding a specific missing features to be a problem.
This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it for no external reason, but somehow it benefits their project. This is in contrast to, for instance, JavaScript (which debatably has its own merits) where if you want to script on the web client, that's your choice, love it or leave it. In the Go domain, there are countless alternatives.
I find it hard to even express clearly why Go feels so...natural and productive. But it does. And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach. Somehow it works.
If we need to stick with vehicle analogies, it's more like someone is using a dumptruck to move massive piles of Earth, but complaining that the steering isn't as light as their car.
And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language. Doing the typical "make a library that solves all problems" sort of thing. When I am using Go it is almost always for a specific, practical requirement (as duct tape between processes, to orchestrate some high performance C code, etc), and it just...isn't a problem. It really isn't. Unless you're making library code it just isn't this issue it is held to be.
You're registering this objection on the basis of JS's privileged status in the browser; I'm invoking it because of The Fine Article's comparison with JS on the server, where it's adopted as voluntarily as any other language -- and where, yes, despite claims that event-driven/callback scattered code are worse than what Go offers, people are able to get things out the door anyway!
And that's true of Node, it's true of PHP, it's true of Java, it's true of most languages people have moved to Go from.
The claim that being able to ship in a language doesn't mean it's wart-free is a pretty solid one, and that's what we're talking about.
> I find it hard to even express clearly why Go feels so...natural and productive. But it does
Does it? I've been working in it for 8 months and... nope. Doesn't feel unusually productive. But I guess your subjective opinion that you can't explain should trump everyone else -- after all, we're using "specious logic!"
> And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach.
Ah, yes. It's like Java:
"I liked programming in Java mainly because I found it very relaxing. With a bad language, like say Fortran or csh, you struggle to do anything at all, and the language fights with you every step of the way forward. With a good language there is a different kind of struggle, to take advantage of the language's strengths, to get the maximum amount of functionality, and to achieve the clearest possible expression.
Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle. In Haskell or even in Perl you are always worrying about whether you are doing something in the cleanest and the best way. In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated, and the only thing you can do is relax and keep turning the crank until the necessary amount of code has come out of the spout."
http://blog.plover.com/prog/Java.html
> And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language.
Really?
> it just...isn't a problem. It really isn't.
Oh. Sorry, then. I'll just realize that the unpleasantness I've encountered working with it really isn't there, and I'm not focusing on solutions.
You misunderstand my argument. If someone is begrudgingly complaining about JavaScript in the browser, well they have a legitimate gripe because they really have no option (beyond various compiles-to-javascript kludges). If those same people used nodejs, on the other hand, which many people do, they clearly found some compelling reason to do so. In the case of node it was that it made code very easily, and by default, asynchronous, instead of the classic .NET/PHP synchronous model. There was a benefit, and people gained from it.
Really?
Why are you using Go? Are you solving a real problem? Did you say "here is my itch, and I am using Go to scratch it?" I have never seen, in these discussions, people solving actual problems complaining about Go. Instead it's the code tourists who want to do some flippant, vaguely directed project and then add "Go Guru" on their resume to give credibility to their complaints.
Apparently. I have no idea why JavaScript's position in the browser is relevant at all to the point that being able to ship in a language isn't evidence that its featureset is ideal.
I do invite you to argue the point further, though. And please continue to ask questions like this again:
"Why are you using Go? Are you solving a real problem?"
Yes, please do imagine out loud that everyone who's critical of Go is just not building real software in it. Hell, follow your "argument" to its natural consequence: anyone not using your personal flavor of Blub is probably just farting around.
There is absolutely nothing drawing anyone who doesn't want to use Go into using it. There are zero external forces or dependencies that are making you build solutions in Go.
So when you come telling a tall tale of your peril with Go, it just stinks. Do you understand? You can, from the outside looking in, have criticisms of the language, but when you try to add authority to your claims by manufacturing great experience, it sounds absurd.
The relevance of JavaScript -- and this really doesn't seem that difficult, though I think you're trying to be difficult -- is that, to reiterate, people have to bear it regardless of their feelings about it, so there are a lot of people who despise JavaScript but ply their trade in it daily. There is zero parallel with Go, where there is absolutely no reason for anyone to ever make use of it if it doesn't offer some significant advantage to their project.
Or because of the hype (and that they didn't know any better), which is quite common in the industry nowadays, unfortunately.
In a similar fashion, the Go designers were surprised that, what they thought was a C++ replacement, did not attract C++ programmers.
But even so, I agree the wheels analogy is too extreme. I'd maybe say that it's like hearing that a car uses two motors instead of a differential -- "weird, I thought we solved that problem a while ago..."
However, I still think the out of the box performance is great and for problems that don't require generics it is a very good option. I especially like the static compiling feature that makes deployments more straightforward. Handling HTTP requests and performing routing, dispatching requests to other services reliable async way is the biggest use case for me using Go. It can totally be written in any other language(Rust), if using generics is a must.
Rust's type system has most of the bells and whistles of C++, plus some new ones. It's clever, well thought out, sound, and bulky. Rust has very powerful compile-time programming; there's a regular expression compiler that runs at compile time. I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. I shudder to think of what things will be like once the Boost crowd discovers Rust.
The lack of exception handing in Rust forces program design into a form where many functions return "Result" or "Some", which are generic enumeration/variant record types. These must be instantiated with the actual return type. As a result, a rather high percentage of functions in Rust seem to involve generics. There are some rather tortured functional programming forms used to handle errors, such as ".and_then(lambda)". Doing N things in succession, each of which can generate an error, is either verbose (match statement) or obscure ("and_then()"). You get to pick. Or you can just use ".unwrap()", which extracts the value from a Some form and makes a failure fatal. It's tempting to over-use that.
The lack of exception handling in Go yields too many "goto" statements. There's also a tendency to turn the panic/recover mechanism into an exception system. This has roughly the problems of C's" longjmp".
As a practical matter, Go now has most of the libraries you need for server-side programs. (Not GUI programs, though.) Rust has only very basic libraries, and they're not stable yet. The language hasn't quite settled down. People are writing and porting libraries at a good pace, and this problem will be solved.
That is the core reason why there are no generics in Go. Not because the Go team thinks they're a terrible idea, but because they think cruft is a terrible idea.
The default answer to a new feature is "no". When everything seems to be going fine without generics (except for internet flamewars), the answer stays "no".
I find the community's insistence that Go does not have them because they somehow make programming worse to be fairly ludicrous, when there are much more practical reasons. Obviously you can write useful code without generics (C does not have them), but that does not make them useless, or "cruft", or an undesired feature (unless you simply choose to believe that every single person complaining about them does not use Go): you can also write useful code without many other features that Go does have.
There was at one time a fad for extending C with macros like that. Fortunately for program readability, it didn't last.
While `try!()` is a macro and not a core language feature, most of the macros in the standard library can be treated as such. So a Rust programmer will know that `try!()` can return, just like a Java programmer knows that `throw` returns early.
Besides, macros are syntactically distinguishable in Rust. When you see that exclamation mark, you have to rememeber that it's a macro and might be doing arbitrary compile time things along with arbitrary token tree expansion.
function addKey(input, key, value) { input[key] = value; return input; }
- create two versions of the same function, one for Objects, 2nd for Arrays
- use any as a type of input - this will work, but you will loose most of the benefits of type checking, e.g. you will be also able to pass Number as an input and compiler won't complain, it will be detected as error only on runtime and other things (your function will also return any so further on in the program you won't know what type is used).
With generic it's easy, you write the function once and when you call it you tell what types are used:
// definition:
function addKey<X,Y,Z>(input:X, key:Y, value:Z):X { ... }
// call:
var a = addKey<Array<string>,Number,string>([],0,"fubar");
Array<double> means the only element you will encounter is a double.
Array<ISomeInterface> means the only element you will encounter is of type ISomeInterface.
hence, you can express part of some code's requirements via the types that a function,class exposes and/or requires.
these requirements can then be checked at compile time.
without this you have to defer the "checking" to runtime.
For example, bufio.NewReader would probably, in a language with generics, be phrased as a type with respect to a type parameter. Something like (in bastard Haskell)
class Reader a where
Read :: a -> [Char]
newReader :: (Reader a) => a -> BufioReader a
package bufio
func NewReader(r io.Reader) *Reader
This subset of generics covers a wide range of software components, even if it doesn't include the usual container types.
With Go, polymorphism is done with interfaces. Composition is done with embedded fields (and the very convenient method promotion).
That's ridiculous. Plenty of people can appreciate the trade offs between "no generics" and "generics." There's nothing "non-negotiable" about it.
I was drawn to Go initially because of its promises around concurrency, but this is why I stayed. Within less than a month, I was as productive in Go as I was in Python, despite the fact that I had been programming in Python for several years at that point.
> - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.
For what it's worth, Docker has more or less replaced this need for me. I know it doesn't actually do "dependency management" in the traditional sense, but by the time that ad-hoc vendoring no longer works, I've found it's already time to start using Docker for deployment for other reasons anyway. At this point, it's just as easy to use Docker to manage the dependencies at the application level while developing as well.
That's not really surprising. Go is actually pretty similar to Python in a lot of ways, the most obvious being the set of built-in data structures.
They are just third party tools that aren't integrated into the language. Which for me is perfectly acceptable. There are sometimes legitimate reasons for formatting code different to what the language creators believe.
I'm now inclined to believe that a basically free way to avoid bugs and make things like code review easier and more productive is worth the minor cost of people having to break out of old ruts.
People have been using standard code formatters in Eclipse/IntellIj for what decades now ?
If that were true, the frictional problems I mentioned would not be the rule in every other language. Even something like Python, where PEP-8 has been recommended strongly by the community for many years and has widely available validators and automatic reformatters, still has perpetual low-level debates about this.
In languages like C, where there are multiple well-established conventions, you can still find bitter arguments going on over things like optional braces because there are still tons of bad programmers out there who think it's preferable to ship massive bugs every few years than type two extra characters.
> I get lost trying to figure what
> the happy path behavior is.
if x, err := doSomething(); err != nil {
} if err := doSomething(); err != nil {
return fmt.Errorf("something failed: %v", err)
}
x, err := doSomething()
if err != nil {
return fmt.Errorf("something failed: %v", err)
}
log.Print(x)The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.
Not having a strong type system is not a fault per say it's just that I need a strong type system as a feature(indispensable for me).
For me choosing between Go and Rust is mostly because of the type system.
If Go works for you then it's fine. Although if you want to find out how type system can help you, it's a different story.
Please elaborate. What exactly do you mean?
I think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs, a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type system is perfectly adequate there.
Other programmers write libraries, functionality that is meant to be used by other programmers to build their code upon. In this case, you rarely know the context in which a user of your library will use it, therefore you cannot really make any decision about types. This is a big reason why people like having parametric polymorphism.
The constant arguments that we see online probably comes from people writing programs and people writing libraries arguing with one another without understanding the context in which the other writes code.
> Other programmers write libraries, functionality that is meant
> to be used by other programmers to build their code upon.
> In this case, you rarely know the context in which a user of
> your library will use it, therefore you
> cannot really make any decision about types.
Tried Lua? Your opinion interests me ..
This post sadly doesn't really go into much details that bowery.io is trying to solve, how Go fits that and why Node was so bad.
A basic crud webapp would probably be better suited towards node and it's larger list of libraries supporting that kind of stuff.
On the other hand, building you own messaging queue or doing heavy mathematical processing might be better suited for Go.
That sounds like it's actually very difficult to support multiple operating systems. As a developer I never, ever want to write any OS-specific code. Sure, that's sometimes required, but saying that the solution is to have multiple files, each for a single OS, doesn't sound good. It's a lot better to abstract the OS away. Node.js does this quite well. Seemingly a lot better than Go.
Besides, Node.js doesn't need to be compiled for each system. This alone makes Node.js better for writing code for multiple operating systems.
>Go is a compiled language so distributing applications for use on multiple platforms is just easier.
I disagree. You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform. (The probability is as high as it is for Go assuming no extra work for a new platform). Sure, each platform needs to have Node.js, but Node.js is supported in most platforms.
]] Performance (AOT compiled languages will typically out perform JIT compiled language
]] user interface (is this going to be a command line app? Does it need a GUI? And if so, what frameworks are supported and do they need any OS specific boiler plate code?)
]] required runtime environment (does your language tool chains support compiling to a native binary (Windows PE / Linux ELF) or do you need a language runtime environment? And if the latter, what's the likelihood of the target OS having said framework pre-installed?)
I'm not trying to take anything away form Javascript / Node, but it loses as many points as it wins. And frankly both languages fail compared to some other languages too.
Personally I mostly target Linux and FreeBSD, but the majority of my Go tools will compile for Windows with zero code changes (the standard Go libraries actually do abstract away most OS specific discrepancies) and all of my code works on Linux and FreeBSD without any Linux / BSD specific code. So I think the issues of different files for different OSs is overstated anyway.
I didn't argue anything about performance. Go might have better performance than Node.js, but that doesn't make Go better for cross-platform distribution! They are separate factors. If performance is your top priority and Go has better performance than Node.js then choose Go while acknowledging that it's possible that Node.js has better cross-platform code distribution support.
>user interface
I didn't make any arguments about that either.
>required runtime environment
Now that's relevant when it comes to cross-platform distribution. Node.js has that covered pretty well.
>I'm not trying to take anything away form Javascript / Node, but it loses as many points as it wins
My comment was not about Node.js vs Go as a whole, it was about developing cross-platform software.
>So I think the issues of different files for different OSs is overstated anyway.
If you look at the core issue here, it's that theoretically speaking "all things equal" Go and Node.js needs about as much work to implement a new feature that works with most platforms. However, on top of that Go requires a compilation step for every supported platform, and that's not required for Node.js.
However, Node.js requires someone to compile the Node.js environment for each supported platform. For most cases that's already done.
This is my core argument that Node.js does cross-platform development better. It's one of the things that Java and C# got right.
as I said, it's very naive to blanket claim that node is better for cross platform development.
If I'm completely honest, i find people who say languages are definitively better at boardly defined subjects are usually lacking objectivity. Programming can seldom be summarise so easily without losing all precision.
Your argument is theoretical. In practice, people are finding Go apps easier to deploy. Reality trumps theory.
Why is reality trumping theory? With Go you one artifact, the executable, which runs on its own and you're done. With Node, you don't and you're not done, and even with the incredibly minimal bit of Node stuff I've touched (keybase.io, one of the minifiers), I still had to fight with Node to get it to run. Sorry, this one is easy to objectively call: Go produces artifacts that are easier to deploy. It doesn't matter how you try to talk around that fact, it simply is not the case that you ship one file with Node and are done; that is at best the best case when all the stars align and the wind is at your back.
You may not, but if you want something to work on multiple platforms that someone else has not abstracted, you have to do it anyway. When you do, you may want something more orthogonal than cpp macros.
With Go, you never, ever have to write any OS-specific code. From a single source, you can build executables compiled for different operating systems.
In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation.
> You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform.
You're missing the point about distribution. Let's say you write a non-trivial command line application, and want to distribute it to your clients. With Go, you can distribute your program as a self-contained executable file. Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the Windows, OS X, etc. executables. The cost is negligible.
Compare that to Node. How are you going to distribute your Node app to clients? Is every client going to install Node on their personal computer? Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway. What happens when the network has a hiccup and npm doesn't download your dependencies correctly, or they try to upgrade your dependencies and everything breaks?
If you plan on distributing your Node code, you're pretty much limited to distributing it to other Node developers. That's not going to work for everybody.
Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."
>Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the Windows, OS X, etc. executables.
Except when the developer only compiles for Windows and Linux, but someone wants to run the code on Mac os X.
>Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway.
You don't need NPM. You can fetch the dependencies and include that with the installer. There's a downside to that, though, which is binary-packages with npm.
> Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."
Both the article and the poster you're replying to are correct. You almost never have to write OS-specific code, but you can write it if you feel there's a benefit to it. Much like Node doesn't make you write C++ code but allows you to do it when you feel it's necessary. The article's main point was, I'm assuming, alluding to Go's build tags which are much more elegant than the traditional pre-processor directives used in the C/++ world. They give you a powerful expression language for targeting specific runtime environments that lets you separate out your OS-specific code in a very clean way.
When it comes to distributing an application, there's another advantage that Go has over Node. One of the common ways that people are distributing server applications these days is as Docker images. It solves the problem of users needing to understand npm quite nicely for a Node application, but makes the distributable artifact significantly larger since it includes the bulk of an OS alongside the application code. With Go's ability to create a statically-linked binaries, you can build your Docker images "FROM scratch" and images can be as small as 2.5m.
It actually depends what you want to do. Since Go tends to be low-level, there may be a moment where your code goes into syscall land, in which case you're going to be OS-specific.
The most recent example I have in mind is mmaping a file: see https://github.com/edsrzf/mmap-go: there is a windows- and a unix- specific version. If you're using something else, you're out of luck (with this package at least)
There is a syscall package, but it's just piling up a lot of syscalls with already some OS-specific stuff. It is going to be so much of a burden to manage that the Go team plans to abstract this in a new package (https://golang.org/s/go1.4-syscall)
How is this a true statement? Ease of distribution isn't a function of a language's runtime environment (native vs interpreter).
It's not to say there aren't meaningful differences across targets you need to account for, but it is "just easier" in my experience.
So while you can't get a single binary with an interpreted language (you need the shared runtime), however you can also get shared libs using a compiled language.
I've found doing cross platform development using NodeJS significantly easier than using C++ (of course I had to use compilers that didn't default to IEEE 764).
So old.
Offtopic nitpick: of course you can, just combine the runtime with the code and wrap it all in a single executable. E.g. http://www.py2exe.org does exactly this.
I would have thought it'd be possible to emscripten compile something like tinyC, and make a C compiler you could naturally fit into the node ecosystem to build native libraries.
I imagine node.js for IBM i or z/OS to have similar issues.
I also install git bash and conemu to have bash on Windows which makes things much better. I don't use windows console.
What you want is maybe something like Beego.
Apart from my own opinion of Rails (I'll pass, thanks), it's also worth considering that Go, again a systems language, may not always be appropriate for typical web development. That's not a rule by any means. Just pick the right tool for the job.
Here we go.
Which I find very disappointing. One thing that I learned, if some standardization happen and you have to use it, it will cause you pain eventually.
Obviously, there is honey-moon period and a clear path what to do if you only got "one" standard, but the author will eventually there is no free-lunch. The standard will be insufficient for some his usecases and then what....
Node.js out of the box embraces multiple solutions - I know this can be overwhelming, but it gets better over time not worse. When you know, the trade-offs between the different choices, you feel empowered to pick the best tool / lib for the job.
There's also the point of simplicity at which it actually doesn't matter how something is accomplished, only that it is, which is where the Node.js ecosystem falls apart. Too many libraries with half-baked feature sets, each new library built because the developer didn't like the last one.
I once let a team split in two for a week to separately build the same product using two competing UI frameworks, before our final decision. The simpler, more opinionated framework won, hands down at the end of one week, being far more productive with the least effort. But, over subsequent years, we found the framework far too restrictive, requiring convoluted solutions when problems strayed from the straight and narrow, leaving our code base littered with painful hacks.
"User authentication" can mean 1,000 different things, maybe if you clarify your use case, people can suggest solutions.
you mean like 4 different things... and even those have common components
[1] https://github.com/codegangsta/negroni [2] https://github.com/pjebs/restgate
I must say, writing an API and some other services (SMTP pipe listener) was much nicer in Go than Authentication.
There is gorilla/sessions for sessions, but there's a lot to be desired here. A weak secret here means other people can decrypt the SessionStore Blob and possibly get secret information as a passive attacker or authenticate as another user. This sessionstore passphrase is the key to your entire webapp.
There's also nothing built in to Go for CSRF tokens, and HTMLTemplates are nice for preventing XSS but a pain in the butt for embedding, generating, and storing/regenerating (depending on how big you are) CSRF tokens.
Overall though....Writing Go has been pure joy for me. These are super knitpicky things to complain about.
To also be fair, web apps are nodes bread and butter, not so much so for Golang (apart from maybe api's - which tend to have pretty straight forward auth mechanisms and dont require csrf, xss or templating solutions, traditionally anyway). With that in mind I wouldn't be surprised if go's devs continue to leave web solutions up to the community. I expect to see a lot of frameworks come along similar to pythons django, rubys rails, and phps laravel.
Disclaimer: non elitist node dev, closely watching go
It will get better but for now I think writing a full web-app in Go, (presentation etc) is pretty annoying.
Its just too strong. The development loop is great when using a build chain like gulp, deployment is relatively easy, scaling up and out is easy (by nature of it being a static webapp), single toolchain, single language (well at its core anyway) etc etc.
Writing API's, specifically restful ones, can be done, and for small stuff its quite nice, but as soon as you start adding processes, services and anything more complex than crud functionality it falls over development wise.
Edit: mea culpa for my attempt at tongue-in-cheek humor, "I think that's called Rust - http://www.rust-lang.org/"
You may find this interesting, someone implemented a parsec-like library in Go [1]. I haven't wrapped my head around it completely, but it looks like it's all dynamic [2].
[1] https://godoc.org/github.com/prataprc/goparsec [2] https://github.com/prataprc/goparsec/blob/master/json/json.g...
OCaml tooling has also gotten a lot better over the past few years, mainly because of OPAM. The library count has exploded, and the language still gets regular point-releases with improvements designed to aid tooling, such as extension points.
(My favorite example is when in #ocaml I asked what testing tools people used; the most positive answer was along the lines of "there's OUnit, but I don't know anything about it".)
There seems to be three awkwardly coexisting OCaml communities: the old academic crowd, the Jane Street people, and a crowd of clueless newbies like myself. It's a really great language, but the ecosystem is going through some growing pains right now.
I love the philosophy behind Go and enjoy coding in the language, and the tooling is a major part what makes development in Go such a breeze. Go seems to be consistently praised for its tooling and I suspect the developers of other languages are paying attention.
Having said that, I do wish Go 1.4 retained the Vim plugin that was bundled with the earlier distributions. I've had nothing but trouble setting up vim-go and its myriad of dependencies on Windows. The process was so easy before.
I find Node downright amazing for web development. npm has everything you could ask for. And the whole community takes the unix philosophy and runs with it. Also love that there's no single best way to create something, you as the architect, gets to decide.
And io.js/ecma6 makes node even more appealing.
But honestly I think that's just par for the course for any substantially popular language. I don't think Go (or any other language) is inherently immune to this.
Since Node.js is JavaScript, you can't possibly argue that Go code is more 'portable' than Node.js. For one, JavaScript can run on more machines than any other language.
Go will not run in the browser because most browser vendors will not let that happen. On the other hand, JavaScript is already universally accepted by everyone and it's everywhere - You can run JS in the browser, natively on mobile devices, on the server, on set-top-boxes, on robots/IoT devices and just about everywhere you can imagine. Anybody can implement and modify their own JavaScript engine to suit their specific needs.
No need to worry about protocols - Since JSON is a subset of JavaScript, you can seamlessly pass objects between the client and the server and no need to context switch between programming styles when going between client and server.
People who don't like JavaScript mostly feel that way because they don't understand it well enough (it's a lot more expressive and powerful than people imagine). I have programmed in many different languages - C/C++, C#, Java, ActionScript 3, Python, AVR Assembly (ATMEL ATMEGA8-16PU microcontrollers and family) and a few others but I feel that no other language has the expressiveness and elegance of JS.
Before I got into Node.js, I considered myself 'language agnostic' because I often switched between languages because no one language could do everything I needed. I no longer consider myself an agnostic - In fact, I feel quite comfortable saying that C/C++ and JavaScript are the only two languages worth knowing.
In reality, you can't be 'fluent' in that many languages because fluency requires constant practice - It makes sense to settle on fewer languages - Mastering a language/tool allows you to focus on what's really important - Logic and structure.
Would you mind if I ask what did you find lacking in Go's json package when compared to Gson?
[1] http://golang.org/pkg/encoding/json/ [2] http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/
In my opinion, a programming language is good if it enables the programmer to move from a concept to correct and maintainable implementation with minimal friction. I don't expect a programming language to entertain me.
The burden is then on me to find projects that I believe in and will enjoy implementing. This is, of course, easier said then done.
I read up and played with Rust earlier this week. It's also excellent, and while it's too young and has been too volatile for libraries to solidify, that will change in the next few months. The tooling (as far as Emacs modes and the dependency/build system, Cargo, are concerned) looks solid. Performance is already decent, and has the potential to eventually match C. To be honest, Rust feels like what Go would have been had its authors understood Lisp and Haskell.
This set me up for a negative article about Go, but, like other Go-related materials, it makes me want to use it. I should use it.
Why should you use it? What problems does it solve for you?
Theres a lot of good stuff, created by good people, in those languages and while the solutions are great, the fact that they are in those languages, make them unfit for a lot of cases.
ok, More actually. Some APIs return ok instead of err.
Speed is not the only concern, or even the biggest concern, for most web apps, the constraints nowadays are typically in something like this order:
- Memory - CPU - Bandwidth - Database - Render speed
Clearly that doesn't hold true for all sites, but for most the order is something like that because with caching you can obviate any render speed concerns very easily. On memory and CPU usage, golang completely trounces a solution like Rails (I say this having built similar sites in both) - it's better by a factor of 10, which means you can run a pretty big site with very spartan resources.
The largest obstacles to go replacing languages like ruby as a tool for web apps is more that the libraries at present are not available for everything you might want to do (user auth, sophisticated templating, csrf, fragment caching, form helpers, orms and query builders etc), but that situation is steadily improving, and the standard library is pretty excellent as far as it goes.