Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go run

breadchris.com

Post reply on HN
Print view View original

91–100 of 173 posts

Re: Go run

#91

Post by BillyTheKing »

bottlepalm wrote: post #67
999900000999 wrote: post #66

Golang is such a elegant language. But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope. The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.

Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?

onboarding 10 Typescript Backend developers is like onboarding 10 developers from entirely different languages. Some are _heavily_ OOP driven, and turn literally everything into a class. Some are heavy on functional programming and start using curried functions everywhere. Others are used to classic express servers, while another group has only ever worked with graphql/prisma, or has only deployed on lambda functions and hasn't really seen express-based routing.

Literally everyone comes with their own project setting, they all have to get used to that specific folder structure, or those eslint/prettier settings. And on top of error-handling in JS/TS is miles behind Go's (and that's despite Go's error handling also being clunky and not as elegant as Rust's or ocaml's, but still much much better than JS's). It is _extremely_ easy to mess up a typescript project, it's significantly harder to mess up a go project (although obviously still easily possible :)

Btw. I also don't hate typescript/JS, I think it's a great language that allows for a big variety of expressiveness in entirely different programming domains, I personally use it all the time and enjoy it. I just don't think it's a particularly great language to scale a team with.

Re: Go run

#92

Post by randomdata »

bottlepalm wrote: post #67
999900000999 wrote: post #66

Golang is such a elegant language. But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope. The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.

Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?

> Where does Go fit in here?

Where you move past academic language discussion and start using the tooling. Typescript is a pretty nice language but the tooling around it is practically unusable. It's laughable how bad it is. Outside of browser work, you're going to pick Go – and still would even if they made the language 10x more flawed – over Typescript every time just to not have to deal with that ecosystem.

Granted, people are trying to make it better. Dahl going on his Go kick and wanting to copy its lessons in the Typescript world via Deno has lit a fire, but there is still a lot of work to do.

Re: Go run

#93

Post by BillyTheKing »

pkilgore wrote: post #69

$ cat helper.mjs export const sleep = (dur) => new Promise(resolve => setTimeout(resolve, dur)) $ cat main.mjs import { sleep } from './helper.mjs' await sleep(1000) console.log("Go is great; but weird throwing node under a bus here?") $ node main.mjs Go is great; but weird throwing node under a bus here?

$ cat helper.mjs export const sleep = (dur) => new Promise(resolve => setTimeout(resolve, dur))

  $ cat main.mjs
  import { sleep } from './helper.js'
  await sleep(1000)
  console.log("Go is great; but weird throwing node under a bus here?")

  $ node main.mjs
file://main.mjs:1 import { sleep } from './helper.js' ^^^^^ SyntaxError: Named export 'sleep' not found. The requested module './helper.js' is a CommonJS module, which may not support all module.exports as named exports. CommonJS modules can always be imported via the default export, for example using:

import pkg from './helper.js'; const { sleep } = pkg;

'What is CommonJS?'

Re: Go run

#94

Post by BillyTheKing »

brlewis wrote: post #90

This article would have worked a lot better without the second paragraph. The writer's simple pleasure of typing "go run ..." should not be predicated on believing that deno doesn't exist.

is anyone actually using Deno in production for larger projects?

Re: Go run

#95

Post by jitl »

bottlepalm wrote: post #67
999900000999 wrote: post #66

Golang is such a elegant language. But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope. The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.

Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?

If Node/Typescript isn't performant enough, you need to move a lot of bytes around, but training a developer team on Rust seems like a massive organizational expenditure.

Go is probably the most efficient language for 0 -> Production. The standard library has everything you need to build a production backend service. There's zero build system shenanigans. Anyone who's seen a C-like language can start writing mediocre code today, and be pretty well off in 2 weeks.

So far at Notion we're solving all our problems with Typescript/NodeJS, but I'm currently working on a distributed system with Consul that needs to move a lot of bytes in and out of files in somewhat complicated ways, and boy howdy am I feeling the painful performance ceiling of single-core NodeJS, and I'm sure if I sat down to rewrite the performance sensitive part in Go, I'd be done in a few days and it'll do 10x the throughput of the NodeJS service with the same resources.

Re: Go run

#96

Post by jitl »

ivanjermakov wrote: post #82
shpx wrote: post #65

Clicking is my favorite part of JavaScript. I just move my mouse onto some blue text and click and the software that I want to use is installed/updated and runs, usually in under a second. In the 50+ year history of software development I haven't heard of any other software stack has been able to realize this is important. go run is close but it's still 10 times slower, maybe even 100 times slower, depending on if yo…

What blue text has to do with JavaScript? You can create such straughtforward tool for any language, and it's running shell commands under the hood in all cases.

here's a gray text that will install and run a javascript app when you click it, in fractions of a second: https://natto.dev/

Re: Go run

#97

Post by scubbo »

Sxubas wrote: post #73
bottlepalm wrote: post #67

Earlier quoted context omitted.

Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?

Go makes error handling explcit, which is a very important part of development. Not only this makes you more conscious on thinking what you need to do when something goes wrong, but also makes codes more maintainable in my opinion. I strongly prefer go error handling compared to a throws-type-error-handling language. Also, with this comment I hope to get some pushback: I haven't kept up with the latest typescript, py…

> Also, with this comment I hope to get some pushback: I haven't kept up with the latest typescript, python or any other language features. I'm talking from almost a purely ignorant perspective so I hope to learn a bit more on how developing with other languages feels like.

Can't push back there - every other language I'm aware of uses at least one (and often both) of "throwing exceptions" or "returning Result types which either contain your actual data, or an Error", both of which let you just write your logic and wrap it in a single handler rather than repeating `if err != null return _, err` everywhere (or if you _want_ to handle each error individually, you can!)

I've gradually reached the conclusion that Gopher's really just do prefer GoLang's verbose repetitive approach. And, y'know what - good luck to y'all. It's not for me, but I'm trying to get better at just letting people enjoy things :)

Re: Go run

#98

Post by winrid »

jitl wrote: post #95
bottlepalm wrote: post #67

Earlier quoted context omitted.

Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?

If Node/Typescript isn't performant enough, you need to move a lot of bytes around, but training a developer team on Rust seems like a massive organizational expenditure. Go is probably the most efficient language for 0 -> Production. The standard library has everything you need to build a production backend service. There's zero build system shenanigans. Anyone who's seen a C-like language can start writing mediocre…

I mostly agree but... you can't use worker threads or something with Node to distribute the work? It's only like one line to submit a job to a worker thread, how is that much more than "go thing()"?

Re: Go run

#99

Post by scubbo »

> bun run :) bun hing.ts same with python but not compiled you need to install python that’s the beauty of go for me even rust you need a cargo file

...are they claiming that you can run Go without installing Go?

Re: Go run

#100

Post by randomdata »

bjackman wrote: post #14

It's not really a Go thing but a build system thing. It's useful to have your build system know what is an "executable target" and how to run it. Bazel does this for _all_ languages. I'm sure most other modern generic build systems do too. AFAIK "go run" is trivial and for single-file scripts it's fine. But for more complex cases (like the NPM equivalent thing) I actually think it's a bit of a shame that it's even ne…

> I'm sure there are some good reasons why they exist under the hood.

User expectation's, mainly. In fact, Google didn't even use the go tool internally, which I expect hasn't changed, using Google's build system à la Bazel instead. It was created only for the wider audience.

Post reply on HN