131–140 of 173 posts
Earlier quoted context omitted.
is anyone actually using Deno in production for larger projects?
does anyone run production code with 'go run'?
if I refactor some too complicated bash script into a script.go file and then execute it against production DBs/APIs with a `go run`.
$ 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 m…
npm install nanoid Nano ID 5 works only with ESM projects, in tests or Node.js scripts. For CommonJS you need Nano ID 3.x (we still support it):
This whole module bit in node has been a total disaster. Incredibly frustrating
Earlier quoted context omitted.
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()"?
There’s tools for parallel execution in Javascript like Worker or node:worker_threads but they have two big drawbacks that make them somewhere between annoying and useless: 1. No shared objects between threads. You can share non-resizable contiguous byte arrays (SharedArrayBuffer) but 98% of existing code makes normal objects and arrays, and if you want to send those to another thread, you pay a serialization memcopy…
2. You can do this w/o restarting worker each time, which helps. Just keep it alive and submit work to it.
and then coordinate state in parent worker.
> Yeah, and then what happens if you want to use modern syntax like esmodule, or maybe you want to use types with typescript? You are going to have to use npm. I don't understand what the problem is here? Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. > Fun fact: One of the understated features go run is that it will automatically download any dependencies the…
> I don't understand what the problem is here. Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. Node and npm are two commands, and when you go to find packages, you will see people telling you to use pnpm, yarn, or npm. I would expect one tool to do this for me, especially for the most popular language in the world. > This feels like a massive antipattern. Why i…
Does your hammer has built-in car or drone to bring nails from store? No. that's why some people think that it's reasonable to split programs that have different modes if operations.
Your choice, but note that it's not universally accepted true or demand.
Earlier quoted context omitted.
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()"?
No more needs to be said after that.
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 not sure there really is a good technical reason they exist. It's cultural. It basically goes like this: - the inventor of new language 'coolang' has a way that they make their project - it's kinda messy, so they clean it up into a tidy script with a few clear and straightforward commands and/or flags, and give you "cool build," "cool install" for making sure all the necessary dependencies are present, etc - a co…
If coolang decided to try to add coolang support to Bazel instead, they would probably have to learn Java[1]. Current maintainers or contributors to Bazel don't know coolang, and they don't care about it much, especially in the early stage. And maybe coolang developers don't know Java, or even actively hate it with a passion (that's why they were on the market for a new language). And even if some coolang developer decided to contribute to Bazel, the barrier would be much higher: being a mature build system with so many features and different needs, surely working in it is going to be complex; there will be many different concepts, and layers, and compromises, and APIs to work with. So for them it just makes more sense to use coolang so that all coolang developers can contribute to it having a real need for the cool tool to improve.
[1] I know nothing of Bazel. So just bare with the example even if it's technically not correct.
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?
> 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. Grante…
I work mainly with node/ts and totally agree, maybe just add that by tooling it is whole ecosystem as well. This problem is not visible if you work either with relatively small code base or new code base. But as soon as you have something old and big you'll see where the pain comes from.
> Yeah, and then what happens if you want to use modern syntax like esmodule, or maybe you want to use types with typescript? You are going to have to use npm. I don't understand what the problem is here? Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. > Fun fact: One of the understated features go run is that it will automatically download any dependencies the…
> This feels like a massive antipattern. Why is this lauded as a "feature"? Why do I want my build system to automatically reach out to the Internet and download random code, without an explicit request to do so like "npm install"? It's not random code, it's code you've expressly used.