Why on earth would a line editor need platform specific code? Sounds like a case of that's-a-cool-feature-let's-use-it!!!
From Node.js to Go
111–120 of 192 posts
Re: From Node.js to Go
#112I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - 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…
> 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.
Having written in both Go and Rust, I can see the arguments. Go has a relatively simple, easy to use type system. The problem is that whenever you need to do anything generic, you have to use Go's "any" type, "interface{}", and the reflection system. This results in doing stuff over and over at run time that could have been done once, preferably at compile time. For much web back-end stuff, though, you don't need a really fancy type system with generics. Mostly you're pushing strings around, which Go does quite well.
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.
Re: From Node.js to Go
#113Earlier quoted context omitted.
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. 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…
> 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) 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.
had to be hundreds of thousands because you didn't come out of the gates with a decent design and you had to wing it for the last 6 years
;)
Re: From Node.js to Go
#114Earlier 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…
> So while you can't get a single binary with an interpreted language (you need the shared runtime)
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.
Re: From Node.js to Go
#115For 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 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.
Re: From Node.js to Go
#116Earlier quoted context omitted.
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.
Technically a coin should be enough to put a screw in place. winks depending on the size of the screw of course. :-)
Re: From Node.js to Go
#117Earlier quoted context omitted.
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)
Java's a bit of a special/odd case, since it's AOT-compiled into a bytecode that is then JIT-compiled into native instructions.
Excelcior JET, Atego, JamaicaVM, RoboVM, ART, CodenameOne, SubstrateVM are just a few of the available native compilers for Java.
Re: From Node.js to Go
#118Go does lack quite a bit of the web pizzazz you'd find in rails, but I learned a lot more by writing web things in go than I did in rails because so much less of the magic is hidden away from you.
I'd consider that a feature of Go. At least that this is not your only way. What you want is maybe something like Beego. http://beego.me/
I ve given beego a go and although it is closer to a full stack solution to write in golang, I find it lacking still, and I am still looking for someone to share their experience by example moving from NodeJs.
Re: From Node.js to Go
#119This is just another generic Go vs Node post. Do we really need another post telling us about Go's concurrency/built-in features/compile benefits. 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 h…
Actually, I would like to see a case by case comparison why / how go's concurrency primitives are nicer/better than something equivalent in node.js/javascript.
Re: From Node.js to Go
#120I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - 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…
> 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.