Live data from Hacker News

From Node.js to Go

bowery.io

61–70 of 192 posts

Re: From Node.js to Go

#61
post #51

>In Go, you can define different files for different operating systems that implement functionality depending on the operating system. 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…

That's a very naive argument. There are so many other variables in choosing a cross platform language which you've overlooked:

]] 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.

Re: From Node.js to Go

#62
post #40

I'm having a hard time enjoying Go. It just reminds me a little too much of Java, and I programmed in that language for way too long. After I finished my test program, I uninstalled the toolkit from my system. Right now, I feel that there's no perfect language for me. I do love JavaScript, but there are some things I wish they'd fix. And it takes browser makers way too long to support the latest features. Been messin…

Maybe you don't like programming? Or you did once, but you've grown bored with it now that it's not as challenging? 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 implementi…

No, I actually do like programming. And I agree with you that there's more to choosing a language than having fun with it. I've had to make that decision for 2 decades. :) But my idea of fun is when I find a language that does a lot with less code, easy to apply patterns, doesn't have a lot of boilerplate, doesn't take a lot of tooling, simple, sleek, and allows any style of programming (e.g. oop, functional, procedural). Like I said, I've tried Go and it just didn't feel like that. It felt like, well, Java. The language I used to build apps in the 90s.

Re: From Node.js to Go

#63
post #61
post #51

>In Go, you can define different files for different operating systems that implement functionality depending on the operating system. 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…

That's a very naive argument. There are so many other variables in choosing a cross platform language which you've overlooked: ]] 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…

>Performance

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.

Re: From Node.js to Go

#64
post #51

>In Go, you can define different files for different operating systems that implement functionality depending on the operating system. 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…

> 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.

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.

Re: From Node.js to Go

#65
post #28

Earlier quoted context omitted.

Sure it's a true statement. Even if you have to compile to different targets (and you do), that's much simpler than implementing shared dependencies on those different targets. When you deploy a binary with no external dependencies, you can (generally) set it and forget it. 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, it's not a function of compiled vs interpreted. It's about a single binary vs shared resources. 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 76…

Minor nit pick, but theses days "interpreted" languages are also compiled. What we are really taking about is AOT vs JIT (though even here, there are AOT compiled languages that still require a supporting run time environment installed, such as Java)

Re: From Node.js to Go

#66
post #51

>In Go, you can define different files for different operating systems that implement functionality depending on the operating system. 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…

> I never, ever want to write any OS-specific code

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.

Re: From Node.js to Go

#67
post #62

Earlier quoted context omitted.

Maybe you don't like programming? Or you did once, but you've grown bored with it now that it's not as challenging? 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 implementi…

No, I actually do like programming. And I agree with you that there's more to choosing a language than having fun with it. I've had to make that decision for 2 decades. :) But my idea of fun is when I find a language that does a lot with less code, easy to apply patterns, doesn't have a lot of boilerplate, doesn't take a lot of tooling, simple, sleek, and allows any style of programming (e.g. oop, functional, procedu…

That does sound fun. Let me know if you find it.

Re: From Node.js to Go

#68
post #63
post #61

Earlier quoted context omitted.

That's a very naive argument. There are so many other variables in choosing a cross platform language which you've overlooked: ]] 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…

>Performance 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 m…

javascript requires you install Node on your target platform alongside your Javascript program, where as Go doesn't. So the extra step you described gets equalled out.

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.

Re: From Node.js to Go

#69
post #49

Earlier quoted context omitted.

> saying that your type system doesn't have generics is like saying your car doesn't have wheels. 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 G…

This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.

I always saw it as the classical: why do you want a screwdriver to put the screw in place? The hammer should be good enough!

Well, sure, I guess you can pound a screw into things with a hammer but you're missing the point.

Re: From Node.js to Go

#70
post #49

Earlier quoted context omitted.

> saying that your type system doesn't have generics is like saying your car doesn't have wheels. 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 G…

This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.

[deleted]
Post reply on HN