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.
Something like: Pikes law of unfavourable comparison OR HN Golang oxidation rate
Go has a pretty high oxidation factor.
Or maybe they're just waiting for something to compile?
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
Java Resources - https://docs.oracle.com/javase/8/docs/technotes/guides/lang/...
Android Resources - https://developer.android.com/guide/topics/resources/providi...
.NET Resources - https://docs.microsoft.com/en-us/dotnet/framework/resources/
Win16 and Win32 resources - https://docs.microsoft.com/en-us/windows/win32/menurc/about-...
UWP resources - https://docs.microsoft.com/en-us/windows/uwp/app-resources/
C++ helpers for Win32 resources - https://docs.microsoft.com/en-us/cpp/windows/resource-files-...
Given that you mention bundles, Java's resource management shows the influence of Objective-C in Java's design.
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.
Generic compile time evaluation is an interesting feature, better than magic comments in my list. Though in this case it is compiler built-in [1].
[1] https://doc.rust-lang.org/src/core/macros/mod.rs.html#1122-1...
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
> The path separator is a forward slash, even on Windows systems.
Which is much more ergonomic for developers than rusts treatment of os specific paths.
[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.
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.
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.
- 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.
So what you're saying is simplicity is only a virtue if it supports the thing you already liked?