Seems pretty complicated compared to Rust's `include_bytes!("path/to/file")`. Sounds like it might have a compile time advantage though, seeing as it produces a seperate package.
I know it's been mentioned before, but I really feel there is a need to codify an 'internet lore law' about how many comments can appear on a Go themed HN post before someone brings up how superior Rust is
Something like:
Pikes law of unfavourable comparison
OR
HN Golang oxidation rate
I suspect that, programming in Rust is so onerous, that Rust programmers must take lots of breaks and troll Go threads so they feel less bad about themselves.
Or maybe they're just waiting for something to compile?
To be fair, I remember thinking the same thing when Go was new. HN was pretty dominated by everyone apparently switching to Go (if you were to believe the general attitude anyway) and how Go was the clear path in the future
Not that it is or isn’t and clearly Go does things really well in some problem spaces but yeah, this seems to be a common theme for all young languages
I do think some members of the Rust community Take it waaay too personally, which I never saw in general when Go was the hip thing. That I agree can be very obnoxious
Well it's pretty relevant when considering a new feature for a language to consider prior art is similar languages (the key similarity in this case being the compilation model), no?
Your comment itself should be codified. Maybe it’s just another growing language with a large community that itself is dedicated to improving the language. Rust is newish, and changing rapidly so it’s a good candidate for comparisons between modern languages. It helps that it’s designed completely in the open so the sauce can be seen.
Not to pick on you or even the other child comments but the amount of people that complain about a language being compared to a modern equivalent is funny. What about every other thread on HN where the same thing happens? It’s alll turtles just enjoy the discussion
Nah, there's something unique about Rust zealots in this respect.
nicoburns comment is completely off topic, and it's extremely obnoxious to see this kind of thing over and over again from the Rust community. And I even like the language!
The Rust promotion has unfortunately changed lately. I've noticed too that they not only tell everyone how great Rust is (which is fine) but started bashing other languages (which is sad and not doing any good for the public image of Rust).
Rust is from enthusiasts for enthusiasts. If the Rust community wants it to become more real / main stream, they need to look at how the Go team focuses on supporting devs for getting things done correctly with long term stability.
If you prefer I can provide examples on how Windows, macOS/iOS, Android resources work for their native language SDKs, or how Java and .NET embedded resources work.
The Rust community does have an uptight attitude, as if Rust's success or lack thereof is a matter of life and death. This can be seen in general with languages which haven't achieved wide-spread success yet.
Forward slashes work on Windows systems for most [1] paths. You can write `include_bytes!("foo/bar.txt")` in Rust and be very confident it'll compile correctly for most of your users.
[1]: "Most" because they don't work for namespaced paths, by design. But note that the number of times you'll encounter those is limited, the Rust standard library doesn't handle them correctly in general, and a lot of other non-Rust software breaks when given them.
Windows path handling is a horrid mess. It basically takes your input and tries to turn it into a valid NT file path, that also includes handling special device names like COM1. At some point this was limited to 256 chars, so you had to input a valid NT path yourself if you wanted it longer, however I think Microsoft removed that limit a few years ago.
This proposal is more powerful than that one rust macro, but rust's abilities around embedding files are much more powerful than go's approach.
This proposal allows "go build" to embed things in a very specific way, but it's not meant to be extensible.
Rust's 'include_bytes!' macro on the other hand is a macro in the stdlib that can be emulated in an external library. I'm fairly sure every feature of go's embed proposal could be implemented via a rust macro outside the stdlib.
For a specific example, I had a project where I wanted to serve the project's source code as a tarball (to comply with the AGPL license of the project). I was able to write a rust macro that made this as easy as effectively "SOURCE_TARBALL = include_repo!()" [0] to embed the output of 'git archive' in my binary.
Of course, there's a very conscious tradeoff being made here. In rust, "cargo build" allows arbitrary execution of code for any dependency (trivially via build.rs), while in go, "go build" is meant to be a safe operation with minimal extensibility, side effects, or slowdowns.
There is a problem with Rust's "anything goes" approach though - it makes it really difficult to know the inputs to compilation. That makes build systems, IDEs, sccache etc. way less robust.
- go tooling (ides, etc) have to be taught about the _specific_ embedding in the same way one could teach rust tooling about specifically `include_bytes()` (or any other specific macro in the same way one teaches go tooling to handle specific pragmas)
In the world of rust build scripts, there is tooling that exposes information about which files are used if dependency info is all that is required (I don't know to what extent imperative macros are able to expose similar info).
The core of how I see the comparison here: if we restrict ourselves to the capabilities of go pragmas in rust, the same level of support is possible, but even without that restriction there are ways to obtain (though with more work) the same info.
> Of course, there's a very conscious tradeoff being made here. In rust, "cargo build" allows arbitrary execution of code for any dependency (trivially via build.rs), while in go, "go build" is meant to be a safe operation with minimal extensibility, side effects, or slowdowns.
I've been working off and on on a language that tries to get the best of both worlds to some extent. The whole language is built around making sandboxing code natural and composable. Like Rust, it has a macro system, so lots of compile time logic is possible without adding complexity to the build system, but macros don't have access to anything but the AST you give them, so they are safe to execute. There's a built in embed keyword that works like Rust's include_bytes, which runs before macro expansion, which you can use to feed the contents external files to macros for processing. At some point I'll probably add a variant that lets you pass whole directory trees.
Accessing nil pointers is well thought out. Not enforcing error checking is well thought out. Reflection and code generators instead of generics and traits is well thought out. Lack of conditional compilation is well thought out. No compilation with unused variables instead of warnings is well thought out. Doing your own sort, map, all essential array operations from scratch everytime is well thought out. Spamming err != nil instead of some operator like `?` is well thought out. iota instead of type-safe Enums is well thought out. No file-scope variables is well thought out. go mod is well thought out compared to npm and cargo.
Go doesn’t have to be bad for all those things you like in Scala/Rust/etc to be true.
It’s a simple language with simple, explicit, verbose, tedious, pedantic patterns. The communication resulting from those patterns is where the value lies for a lot of developers and teams.
Before using it I thought the if err != Nil would be annoying, but it actually isn't. I think a sum type would be better, but the pattern is common and honestly not very different from a match on a sum type.
In general I agree that it does lead to code that's more familiar even if it was written by someone else. Having only used it a few months now, I can definitely see where the value in go lies.
disagreeing is a pretty strong word. Nobody can disagree these days. I was flagged and labeled as a troll within a couple of minutes once I criticized a programming language. 30 years from now, people will remember this pathetic mob tyranny era when one couldn't even offend a programming language feelings!
