Hacker News new | ask | show | jobs
by MStrehovsky 1264 days ago
bflat author here - happy to answer questions.

I think at this point https://flattened.net/ is a better introduction to bflat than the repo. The repo also links to it, but wanted to highlight it.

7 comments

Any thoughts on OSX support? I'm naive here, but DotNet 6 seems to work just fine (I haven't tried building bflat yet), and p/invoke seems straightforward enough:

https://learn.microsoft.com/en-us/dotnet/standard/native-int...

I want bflat to be able to crosscompile from anything to anything.

Apple's platforms are difficult to crosscompile for - most instructions I've seen that need to reach dependencies beyond what libc offers require one to copy files from an Xcode installation and pray one didn't break EULAs. I don't even know where to start if I want to build from Linux or Windows to target macOS without a mac.

Then there's a philosophical issue that I have where Apple essentially would like everyone to pay up if they want to distribute software that targets their platforms (required code signing, etc.), and breaking backwards compat all the time (essentially treating developers like a resource to be exploited). This practice needs to go away. I know bflat not being available for macOS won't change that, but we need to start somewhere...

Can you do whatever Go does? IIRC Go can crosscompile without requiring any xcode component.

Or you literally mean that you don't want to do it because of ideological reasons regardless of the aforementioned technical argument?

The crosscompilation on Go to mac is pretty limited. That's why I wrote "need to reach dependencies beyond what libc offers". If you crosscompile Go from Linux to mac, you'll actually get a different binary than if you compile on mac natively (DNS resolution will use Go's home baked version instead of the one provided by the OS). CGo also doesn't work if you crosscompile.

It's a bunch of work to even get a hobbled version of crosscompilation to macOS running.

Yeah the DNS resolution issue without cgo is quite a hassle.

Luckily this should be solved in 1.20

https://go-review.googlesource.com/c/go/+/446178/

I agree with what you're saying, and it's of course entirely your call to make.

However, given that a significant percentage of developers are on Macs, this makes bflat a non-option for a large number of use cases. Even if I'm writing a library (and not an app or a service), I can't pick bflat because sooner or later someone will want to target Macs and iOS.

Also, will .Net V8 NativeAOT being able to target Apple Silicon help with the effort?

Please make it so it can at least compile on a Mac, no need for cross compiling if it's too complicated.
I think that support will come when dotnet 8 adds aot support for osx.
Hi. I think this is an exciting development. It will be much work to replicate all dotnet standard libraries. Is there anything existing that can be ported/reused? For instance the original work on mono? Or is any of microsoft’s work licenced permissible enough to use?
This is using Microsoft's standard libraries and compiler parts. All of .NET is MIT licensed so this kind of remixing is super easy.
Thanks.
Would you be able to provide support for dotnet 8 alpha? Super interested in this, but would need iOS,MacOS and wasm... Seems like cross-compile support for all those targets are already in 8.0.0 alpha?
What's keeping exceptions out of Zero?

Is there a simpler way you could achieve Try/Catch semantics and throw-like flow control, without having to check return values after each function call? eg. Even though VB6 lacks exceptions, I built such a framework for it out of primitives like "On Error Goto" (and helper tooling that would automatically wrap and instrument functions to propogate the Err details). It sounds a bit heavy but was in fact really slick in practice.

TL;DR: It's work.

The way exceptions are done in .NET is by keeping track of extra metadata to be able to unwind methods (remove them from the execution stack) and execute handlers. That way the overhead of exception handling is close to zero if no exception is ever thrown. This requires quite a bit of infrastructure.

Propagating exceptions as error codes would come with execution time costs even if no exception is thrown and would have to be written from scratch (since .NET doesn't do it this way).

Either approach requires more investment than I'd want to put into it right now.

Note that .net supports exception filters (and the stdlib uses them), so replacing exceptions with error codes would observably change behavior in a big way.
Awesome project! C# is my preferred language, but I love the less-heavyweight tooling in other langs, so bflat fits nicely. What inspired you to start this / what was your use case? Where did existing tooling fall short for you? I had a brief look at the repo but didnt see a 'Why' or similar section.
I also like the less heavyweight approach where one can compose tools to do things. The existing .NET tooling is so entwined with MSBuild that one can't even (easily) invoke the C# compiler without an MSBuild project file.

Don't get me wrong, I like MSBuild and even bflat is built with MSBuild (wrote a custom target to invoke bflat from MSBuild), but sometimes I really just want to write a Makefile and be done with it instead of fiddling with MSBuild targets.

bflat integrates nicely with Make or other build systems - pass `-c` to generate object files (link it later with the commands bflat would use - use `-x` to see the commands), or use `bflat build-il` to create .NET assemblies and pass those as a reference (`-r`) to `bflat build` later.

Ah, there's a repo. That's cool: I didn't realise you'd open sourced this.
Awesome work! Any info about UI frameworks that are/might be supported?