Live data from Hacker News

From Node.js to Go

bowery.io

131–140 of 192 posts

Re: From Node.js to Go

#131
post #120

Earlier quoted context omitted.

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

I've never used a typed language at all (only PHP, JS, Python etc). Why is it a big deal? I read the Wikipedia article but didn't understand why.

Guarantees at compile time:

Array means the only element you will encounter is a double.

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

Re: From Node.js to Go

#132
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…

> With Go, you never, ever have to write any OS-specific code

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)

Re: From Node.js to Go

#133
post #120

Earlier quoted context omitted.

I've never used a typed language at all (only PHP, JS, Python etc). Why is it a big deal? I read the Wikipedia article but didn't understand why.

Say you have a function that can operate on various types, for example you'd have a function in JS like: function addKey(input, key, value) { input[key] = value; return input; } this will work on either Objects or on an Array. But if you have static typing and no generics to make it work you have to either: - create two versions of the same function, one for Objects, 2nd for Arrays - use any as a type of input - this…

Thanks a lot. That was a really good explanation which instantly made me understand generics. In fact, I think this is an awesome way to learn new languages and concepts. You start with an example in a language you know and reason about the functionality from that.

Re: From Node.js to Go

#134
post #131
post #120

Earlier quoted context omitted.

I've never used a typed language at all (only PHP, JS, Python etc). Why is it a big deal? I read the Wikipedia article but didn't understand why.

Guarantees at compile time: Array means the only element you will encounter is a double. Array 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.

I'm sorry, I meant why generics are a big deal. Thanks though!

Re: From Node.js to Go

#135

Earlier quoted context omitted.

Again. Third party tools will have exactly the same benefits. People have been using standard code formatters in Eclipse/IntellIj for what decades now ?

> a single standard format

indeed. Pretty sure there's some cognitive load involved for developers who come onto a team who uses a style that's different to what that developer is used to. Languages with strict style standards remove this problem.

Re: From Node.js to Go

#136
post #69

Earlier quoted context omitted.

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.

Technically a coin should be enough to put a screw in place. winks depending on the size of the screw of course. :-)

Don't worry! All the screws have the same size and your coin is compatible. (Go's builtin data types which have generics)

You want to use different screws? You're on your own.

Re: From Node.js to Go

#137
post #115

For testing frameworks, standard library tasks, workflow: he author prefers less choice and more standardisation, hence Go > Node.js. 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…

I think there's a difference between standards at the language level and standards in library code.

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.

Re: From Node.js to Go

#138
post #73

Earlier quoted context omitted.

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

>With Go, you never, ever have to write any OS-specific code. 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…

You don't need to include the binaries, once you can run "npm rebuild" in the installation process.

Re: From Node.js to Go

#139

Earlier quoted context omitted.

Again. Third party tools will have exactly the same benefits. People have been using standard code formatters in Eclipse/IntellIj for what decades now ?

> a single standard format

Unless you change the settings it'll default to the Java Conventions.

Re: From Node.js to Go

#140
post #86

Earlier quoted context omitted.

Most languages have an equivalent of go fmt. 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 used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks. I'm now inclined to believe that a basically free way to avo…

Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err := foo(); if err { ... } that I get lost trying to figure what the happy path behavior is.
Post reply on HN