6 ms·

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package m

by iends 11y ago

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClojure? Too obscure.

ssmoot 11y ago
Please keep in mind I may have completely misinterpreted your comment. > Java? Lots of JEE/App server issues to consider Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)? It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per deployment, no unnecessary proxies or additional services to watch/manage. Sure you can go crazy. Or maybe even need to for some use case, but even in that scenario you can bet your business on the fact that it'll still be a far simpler solution than the comparable dynamic stack. Not that I'm advocating Java exactly. I just feel like if deployment/server-issues are an issue, compared to a dynamic stack with similar throughput, then you've done something horribly horribly nightmarishly wrong. ;-)
- iends 11y ago
  Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering. Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc. But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).
  - mschulze 11y ago
    With Spring Boot (not saying Spring is one of the "uncomplex" parts of the Java ecosystem) build and deployment goes like this: `gradle build`, `scp` the jar file to a server and then you can symlink it to `/etc/init.d/` and just use it as a service.
  - ssmoot 11y ago
    I can totally understand that. Feels a bit unfair to paint an entire platform with the same brush if you haven't tried the more modern alternatives though. This is a full HelloWorld web-server in Spray: http://scastie.org/14680 http://scastie.org/14680 Play can get you to Hello World even easier: $ brew install typesafe-activator $ activator new my-first-app play-scala $ activator run That's going from an off-the-shelf Mac with only homebrew installed to running your first Play app. To deploy it just run the `dist` task instead, and copy the generated .zip file to a server. Unzip it and run `./bin/my-first-app`. The only dependency you have on that system is Java. Stick a load-balancer in front and you're good to go. It's light-years beyond anything I've ever experienced on any other platform on the *nix side of things. Especially since it's also so much faster than any other platform I've worked with (decade old c# doesn't count).
krisdol 11y ago
>If you want a reasonably fast statically compiled language, what would you use? I'd go for rust.
- iends 11y ago
  Rust seems like a nice systems language, but is it really best suited for non-system programming? I may be too risk adverse, but it seems too early to make that bet at this point.
  - EugeneOZ 11y ago
    Works fine for the web needs.
  - gnuvince 11y ago
    I'm learning Rust by writing a toy compiler, definitely a high-level task, and I'm finding that Rust is pretty good for that. Some highlights: - Algebraic datatypes and pattern matching: extremely nice for compiler work where you need to manipulate symbol data. - Result + try! macro: a bit more verbose than a language that can let an exception bubble up, but definitely nicer than the boiler-plate that people in Go must use. - Module system: easy to expose only what you want. - Cargo: one of the best, maybe the best, language package manager that I've used. Super easy to add dependencies to your project. I will say this however: I'm moving more slowly than I would in a language like OCaml. I still haven't assimilated all of the borrow checker rules in my programming sub-conciousness, so I still make errors and it can take a little while to figure out what's happening and how best to address the problem.
notacoward 11y ago
> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent quality.
- iends 11y ago
  There is very little chance I could sell a CEO on using Nim. The fact of the matter is that the community and ecosystem are parts of the entire platform and the platform matters a huge deal when you're betting your business on it. Accident or not.
  - notacoward 11y ago
    Not disagreeing with you, but that only matters if you need to sell a CEO on your choice of language. Many of us don't, and every language had to cross that chasm somehow. Once upon a time, there were plenty of CEOs who didn't believe you should use Java for anything that mattered. Ditto for Javascript. Most relevantly, ditto for Go. If size of the existing community and ecosystem were the main criterion for choosing a language, Go would still be in the same bucket as Nim. Somebody has to use a language because of its own inherent strength before the CEOs can be convinced.
- jibalt 11y ago
  Nim is fun but it's not even at version 1 and has a very small developer and user base. "The only thing in Go's favor ..." The selectivity of a true ideologue.
  - notacoward 11y ago
    It's the Go fanatics who are the ideologues here. Anything Go has is important, anything it doesn't have is trivial. What a horrible attitude to bring into any kind of technical discussion. I've defended Go against detractors who say it's worthless because it has mandatory GC or doesn't have generics (which I do consider a weakness but not a fatal one). There's nothing particularly wrong with Go, but there's not all that much special about it either and it does have flaws. Can you name some other feature that (a) distinguishes Go from Every Other Language and (b) matters? Something that might sway a CEO, as we were discussing? "Goroutines" perhaps? Riiight. That CEO will be really impressed. Don't project your bias onto others.
blakeyrat 11y ago
Great tooling? Does Go have any quality IDEs with integrated debuggers yet? I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)
- geodel 11y ago
  Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.
  - jmgao 11y ago
    Does go even have any good command-line debuggers? All of the things I've seen either involve insanity like preprocessing your source to inject hooks in between each line of code, or don't actually work.
    - pjspycha 11y ago
      Delve is an open source debugger for go. And many editors can work with delve such as Visual Studio Code. There is an animated gif of the debugger on the vscode-go page. https://github.com/derekparker/delve https://github.com/derekparker/delve https://github.com/Microsoft/vscode-go https://github.com/Microsoft/vscode-go
      - pjmlp 11y ago
        Due the way Delve rewrites Go source code and relies on having it available, I wouldn't call it a debugger.
  - pjmlp 11y ago
    > Infact this is why Go will remain unviable option to .net developers. Why should we even bother with Go, if we have C#, F#, JIT, AOT compilation to dynamic binaries (NGEN), AOT compilation to static binaries (.NET Native), NuGET already available? And yes, I do know Go and even tried some early contributions before the 1.0 release. For me it is only a step forward for C developers. Still a very important one, as we need more widespread use of safer compiled languages.
FraaJad 11y ago
D. * C/C++ like familiar syntax. * as fast as C++ (faster in some, slower in others) * type inference (auto keyword) * Garbage collected language by default. * Multiple compiler implementation (DMD, GDC, LDC) * Debugging symbol support * Package management with versioning and pkg repo * IDE/Editor support - Visual studio/xamarin/emacs * Very easy C FFI * compile type function evaluation * meta programming * The concurrency story is more "mainstream" than Go's (no "goroutine" and other fancy stuff). * Multiple new books on the topic D has a lot going for it, except for breathless fans :) (not knocking breathless fans here. D can use some)
BuckRogers 11y ago
> If you want a reasonably fast statically compiled language, what would you use? Anything that is C ABI compatible. I'm sympathetic to Go's philosphy, but Go is not that. In general, I'd be on the lookout for Swift on the server in the next few years. It has the backing of Apple, is compiled, and the possibility of removing yet-another-language from your stack. Since many shops want or need an iOS frontend, running Swift on the server makes sense.

by iends 11y ago

ssmoot 11y ago

Please keep in mind I may have completely misinterpreted your comment. > Java? Lots of JEE/App server issues to consider Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)? It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per deployment, no unnecessary proxies or additional services to watch/manage. Sure you can go crazy. Or maybe even need to for some use case, but even in that scenario you can bet your business on the fact that it'll still be a far simpler solution than the comparable dynamic stack. Not that I'm advocating Java exactly. I just feel like if deployment/server-issues are an issue, compared to a dynamic stack with similar throughput, then you've done something horribly horribly nightmarishly wrong. ;-)

iends 11y ago
Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering. Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc. But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).
- mschulze 11y ago
  With Spring Boot (not saying Spring is one of the "uncomplex" parts of the Java ecosystem) build and deployment goes like this: `gradle build`, `scp` the jar file to a server and then you can symlink it to `/etc/init.d/` and just use it as a service.
- ssmoot 11y ago
  I can totally understand that. Feels a bit unfair to paint an entire platform with the same brush if you haven't tried the more modern alternatives though. This is a full HelloWorld web-server in Spray: http://scastie.org/14680 http://scastie.org/14680 Play can get you to Hello World even easier: $ brew install typesafe-activator $ activator new my-first-app play-scala $ activator run That's going from an off-the-shelf Mac with only homebrew installed to running your first Play app. To deploy it just run the `dist` task instead, and copy the generated .zip file to a server. Unzip it and run `./bin/my-first-app`. The only dependency you have on that system is Java. Stick a load-balancer in front and you're good to go. It's light-years beyond anything I've ever experienced on any other platform on the *nix side of things. Especially since it's also so much faster than any other platform I've worked with (decade old c# doesn't count).

krisdol 11y ago

>If you want a reasonably fast statically compiled language, what would you use? I'd go for rust.

iends 11y ago
Rust seems like a nice systems language, but is it really best suited for non-system programming? I may be too risk adverse, but it seems too early to make that bet at this point.
- EugeneOZ 11y ago
  Works fine for the web needs.
- gnuvince 11y ago
  I'm learning Rust by writing a toy compiler, definitely a high-level task, and I'm finding that Rust is pretty good for that. Some highlights: - Algebraic datatypes and pattern matching: extremely nice for compiler work where you need to manipulate symbol data. - Result + try! macro: a bit more verbose than a language that can let an exception bubble up, but definitely nicer than the boiler-plate that people in Go must use. - Module system: easy to expose only what you want. - Cargo: one of the best, maybe the best, language package manager that I've used. Super easy to add dependencies to your project. I will say this however: I'm moving more slowly than I would in a language like OCaml. I still haven't assimilated all of the borrow checker rules in my programming sub-conciousness, so I still make errors and it can take a little while to figure out what's happening and how best to address the problem.

notacoward 11y ago

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent quality.

iends 11y ago
There is very little chance I could sell a CEO on using Nim. The fact of the matter is that the community and ecosystem are parts of the entire platform and the platform matters a huge deal when you're betting your business on it. Accident or not.
- notacoward 11y ago
  Not disagreeing with you, but that only matters if you need to sell a CEO on your choice of language. Many of us don't, and every language had to cross that chasm somehow. Once upon a time, there were plenty of CEOs who didn't believe you should use Java for anything that mattered. Ditto for Javascript. Most relevantly, ditto for Go. If size of the existing community and ecosystem were the main criterion for choosing a language, Go would still be in the same bucket as Nim. Somebody has to use a language because of its own inherent strength before the CEOs can be convinced.
jibalt 11y ago
Nim is fun but it's not even at version 1 and has a very small developer and user base. "The only thing in Go's favor ..." The selectivity of a true ideologue.
- notacoward 11y ago
  It's the Go fanatics who are the ideologues here. Anything Go has is important, anything it doesn't have is trivial. What a horrible attitude to bring into any kind of technical discussion. I've defended Go against detractors who say it's worthless because it has mandatory GC or doesn't have generics (which I do consider a weakness but not a fatal one). There's nothing particularly wrong with Go, but there's not all that much special about it either and it does have flaws. Can you name some other feature that (a) distinguishes Go from Every Other Language and (b) matters? Something that might sway a CEO, as we were discussing? "Goroutines" perhaps? Riiight. That CEO will be really impressed. Don't project your bias onto others.

blakeyrat 11y ago

Great tooling? Does Go have any quality IDEs with integrated debuggers yet? I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)

geodel 11y ago
Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.
- jmgao 11y ago
  Does go even have any good command-line debuggers? All of the things I've seen either involve insanity like preprocessing your source to inject hooks in between each line of code, or don't actually work.
  - pjspycha 11y ago
    Delve is an open source debugger for go. And many editors can work with delve such as Visual Studio Code. There is an animated gif of the debugger on the vscode-go page. https://github.com/derekparker/delve https://github.com/derekparker/delve https://github.com/Microsoft/vscode-go https://github.com/Microsoft/vscode-go
    - pjmlp 11y ago
      Due the way Delve rewrites Go source code and relies on having it available, I wouldn't call it a debugger.
- pjmlp 11y ago
  > Infact this is why Go will remain unviable option to .net developers. Why should we even bother with Go, if we have C#, F#, JIT, AOT compilation to dynamic binaries (NGEN), AOT compilation to static binaries (.NET Native), NuGET already available? And yes, I do know Go and even tried some early contributions before the 1.0 release. For me it is only a step forward for C developers. Still a very important one, as we need more widespread use of safer compiled languages.

FraaJad 11y ago

D. * C/C++ like familiar syntax. * as fast as C++ (faster in some, slower in others) * type inference (auto keyword) * Garbage collected language by default. * Multiple compiler implementation (DMD, GDC, LDC) * Debugging symbol support * Package management with versioning and pkg repo * IDE/Editor support - Visual studio/xamarin/emacs * Very easy C FFI * compile type function evaluation * meta programming * The concurrency story is more "mainstream" than Go's (no "goroutine" and other fancy stuff). * Multiple new books on the topic D has a lot going for it, except for breathless fans :) (not knocking breathless fans here. D can use some)

BuckRogers 11y ago

> If you want a reasonably fast statically compiled language, what would you use? Anything that is C ABI compatible. I'm sympathetic to Go's philosphy, but Go is not that. In general, I'd be on the lookout for Swift on the server in the next few years. It has the backing of Apple, is compiled, and the possibility of removing yet-another-language from your stack. Since many shops want or need an iOS frontend, running Swift on the server makes sense.