> even rust you need a cargo file
And a look at Github shows me Go has a go.mod file. I don't see the point the author wants to make, neither of them affect the build/run command.
Go run
121–130 of 173 posts
Re: Go run
#122> But I can run node main.js? 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
No, you do not. You can just use .mjs extensions for esm. You can also run typescript to transpile your code and then run it with node. You can even use loaders, etc.
Saying you are going to have to use the included package manager in node is probably the weakest argument for using go over node.
Can you run some language superset over go magically without some transpilation? No, you cannot.
You cannot build a argument comparing js to ts vs go, it doesn't follow.
Re: Go run
#123Earlier quoted context omitted.
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…
how does that work with try/catch? try/catch is significantly more verbose than just if err != nil // do something imo, and also much more brittle.
Agree re: Results type in Rust and Ocaml, etc. Those are better in my view too. And yes, you can define a Result return type in Typescript as well (and in fact that's what I mostly when I write typescript and works ok) but unlike Rust this is definitely not 'idiomatic typescript/js' and other developers who might not be familiar with Result types will probably initially dislike and then probably dismiss it.
Re: Go run
#124This 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?
does anyone run production code with 'go run'?
Re: Go run
#125Earlier quoted context omitted.
Make and CMake are not examples of what I was talking about! In Bazel (and, I assume, other similar systems), you can just "bazel run target" and it always works. Doesn't matter what languages the thing is written in. Make and CMake are certainly not like what. (Yes, you can have a "run" target, but that's not the same thing). So my minor gripe is that 'runtime run source' does not need to be a per-runtime thing.
I use Bazel's friend at work but can't imagine using it without also having build_cleaner. Is there an equivalent in the wild?
I am not sure actually, there is this but it doesn't seem to support C++ or Python in the way build_cleaner does, which sounds like it would indeed be kinda annoying: https://github.com/bazelbuild/bazel-gazelle
Re: Go run
#126Earlier quoted context omitted.
The build system should come with it. Even if it requires me to follow conventions, it’s magnitudes better than rolling my own. I can add to it if I need to. The worst offenders are C and C++ projects. Make? CMake? You’re on your own. During development, it’s so good to be able to just runtime run source like in go and bun.
As an embedded developer I shudder to think of all of the work that would go into /runtime run source/ to have it build objects, link them into some kind of format, convert the format to a series of flash addresses and data, connect to my JTAG over a network, halt execution, erase the flash, load the executable file into flash, verify the load, and try to signal a PMIC or other chip to reset the device to start it ba…
You have to do that work anyway... Why not encode it in your build system?
(Admittedly I have never tried this with a modern build system. My real world approach for that would be a janky phony rule in a Makefile, with a bunch of MAKE_VARS the user has to set on the cmdline/in the environment to set up the toolchain/serial port etc. But in principle I have always believed it should be possible to make this process as easy as compilation)
Re: Go run
#127Helpful makefile directive...
run_%:
cd ./cmd/$* && \
go run .Re: Go run
#128go build is great too! I recently was dealing with some docker containers that we needed to abuse. The app within the containers was not returning helpful errors. One quick script and a go build later I had a portable binary that could return a responsible error message.
I often feel like Docker shouldn't even be needed for Go apps. It's just so easy to have your dependencies in order if everything is statically linked.
Re: Go run
#129Personally I've always found it easier to do:
$ go install ./...
$ Re: Go run
#130> But I can run node main.js? 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 No, you do not. You can just use .mjs extensions for esm. You can also run typescript to transpile your code and then run it with node. You can even use loaders, etc. Saying you are going to have to use the included package manager i…
yeah i was going to say its unfair from the start... node is anyway a runtime for a language... go is a language in itself, and also happens to compile to something much more flexibly runnable...