[HN Gopher] Bflat: C# as you know it but with Go-like tooling
___________________________________________________________________
Bflat: C# as you know it but with Go-like tooling
Author : tate
Score : 210 points
Date : 2021-06-25 18:18 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| arthurcolle wrote:
| Can you do .NET development on a Mac these days? I vaguely
| remember a thing called Mono that was in vogue for a while before
| .NET Core became open source. Anyone have time to do a quick
| recap of capabilities on non Windows or Windows Server systems?
| elisaado wrote:
| Yes! The thing you're looking for is .NET Core.
| manigandham wrote:
| The latest release is just called .NET 5
|
| .NET Core was the name for the cross-platform version, but
| that's the default now and will be the future. No need to
| differentiate from the older Full Framework anymore.
| pjc50 wrote:
| Microsoft naming strikes again. I suspect they're only
| dropping the "core" now because they can - below 4 there's
| a need to disambiguate versus .net Framework versions.
| mattmanser wrote:
| And the road between .net core 1 > .net core 2 > .net
| core 3 was extremely bumpy.
| Smaug123 wrote:
| Yes, it all Just Works (TM). Rider with net5 is as seamless for
| me on a Mac as it is on Windows.
| popotamonga wrote:
| My whole company is c# and every single person has a company
| issued Mac, 0 issues.
| moron4hire wrote:
| Basically, the only major systems it not on are the BSDs, as
| the work is still in progress.
| josteink wrote:
| As one of the original contributors trying to land BSD-
| support back in the 1.0 days (2015!!! before life got in the
| way), that's been the story for waaay to long now.
|
| I really hope some day we finally land it. Even as a full
| time Linux-user these days, BSD still has a special place in
| my heart.
| turtlebits wrote:
| You can, but not all the languages receive the same level of
| support. I really tried (twice) to use F# on Mac recently and
| gave up because the tooling/docs didn't work.
| ducaale wrote:
| This is nice, I have two questions if you don't mind:
|
| - Can bflat be used to compile F# code?
|
| - How do you build multiple files?
| loic-sharma wrote:
| Not the author, but I would assume bflat cannot compile F# as
| this project uses the Roslyn compiler, which supports C# but
| not F#.
| MStrehovsky wrote:
| Pass the multiple files to `bflat build`. Or if you run `bflat
| build` without arguments, it will compile all *.cs files in the
| current directory. Not great, but works for now.
| bobowzki wrote:
| I feel Dflat would have been a better name.
| tester756 wrote:
| >The source code is in the respective Roslyn/NativeAOT
| repositories. I'm not ready for people to see (or to accept pull
| requests) things that are specific to bflat.
|
| hmm?
|
| edit: nvm, it seems he's MS employee, so it's I guess it's legit.
| canadianfella wrote:
| Legit isn't the right word.
| snarfy wrote:
| No source code.
|
| > I'm not ready for people to see (or to accept pull requests)
| things that are specific to bflat. If you think bflat is useful,
| you can leave me a tip in my tip jar and include your GitHub user
| name in a note so that I can give you access to a private repo
| when I'm ready.
|
| It's not hard to use CoreRT directly. [1]
|
| [1] -
| https://github.com/dotnet/corert/tree/master/samples/HelloWo...
| alpb wrote:
| There's zero chance anyone will seriously consider using this
| without the source code being available. :) So I am not too
| worried. The author would be ending up shooting themselves in
| the foot if they keep it that way for long.
| MarkSweep wrote:
| The author's ZeroSharp project is also interesting. It shows how
| you can compile C# without any runtime. No garbage collection, no
| exceptions. You can perform stunts like make a 5KB Hello World or
| a EFI application that runs with no operating system:
|
| https://github.com/MichalStrehovsky/zerosharp
|
| I did a survey recently of binary sizes for .NET apps and
| comparisons to other languages. Things like NativeAOT (on which
| Bflat is built) and Graal Native Image let these languages get
| down to a binary size , startup speed, and deployment model
| similar that enjoyed by Go and Rust developers.
|
| https://github.com/AustinWise/SmallestDotnetHelloWorlds
| throwaway894345 wrote:
| > You can perform stunts like make a 5KB Hello World
|
| Which, according to HN/proggit, is the only valid measure of a
| programming language. :)
| Gibbon1 wrote:
| If one could cross compile to something like an ARM-Cortex,
| 5k hello world with no GC would be very interesting.
| hughrr wrote:
| I'm not sure it would because a C one is measured in bytes
| and does the same thing.
| MarkSweep wrote:
| I assume you mean an ARM microcontroller? I think it may be
| possible. .NET has a code generator for ARM32, which I
| think generates Thumb-2 instructions.
|
| The trouble I had last time I tried (.NET Core 3.1 I think)
| is you needed a cross compiling versio of RyuJIT that has
| the same bitness of your target. That is , you needed one
| that ran on linux x86 targeting linux arm32. And that was
| not easy to find. Maybe if I try compiling from a Arm32
| host it will be easier.
| jozen wrote:
| B flat as a replacement to C# huh? That name is a bit too clever.
| irikeyu wrote:
| So is this a step down from c#?
| tk75x wrote:
| A step and a half actually
| nhoughto wrote:
| Cool, so like Graal for Java. 2-3mb min file size is quite a bit
| smaller than the smallest Graal native images tho, I wonder what
| the difference is.
| tmccrary55 wrote:
| It's like Go but old!
| LandR wrote:
| To me, Go feels like the antiquated language.
| haolez wrote:
| A little off topic, but what's so good about C# nowadays? All
| developers that touch it start preaching it around as the best
| programming environment that they've ever used, but I haven't
| seen that many projects written in C# that really impress me
| (like Java or Go excel at). Also, and maybe this is unfair, but
| Microsoft's software is known for being buggier than one would
| expect and I imagine that C# is used a lot there.
|
| Please, help me correct my prejudices :)
| zx14 wrote:
| What I love about C#:
|
| - very active language development, modern functional features
| - very strong standard library. I used to take this for
| granted, but over the years I realised many other languages and
| are nowhere near where .NET is - exceptional IDE. VS has no
| competition
| jokab wrote:
| > VS has no competition
|
| True. Rider comes close, but it's no VS
| mdasen wrote:
| > what's so good about C# nowadays?
|
| For me, it basically has all the advantages of Kotlin over
| Java. ASP.NET is also a lot better than any Java web framework
| I've tried. It doesn't really have new concepts, but everything
| works together without spending time glueing things together.
| Things just build and run with minimal hassle. Rider and Visual
| Studio offer excellent tooling that doesn't stop at odd
| boundaries (think about how most template engines have poor IDE
| support in the Java world).
|
| With Java, how do you create a data class? Are you making Java
| Beans (and hoping no one ever makes a mistake)? Are you using a
| library like Immutables to generate code at compile time? Are
| you using Kotlin for that and compiling two languages? Are you
| using the records feature which just landed (out of preview)
| three months ago and doesn't work the way Java Beans work? Are
| you using Lombok and installing IDE plugins and doing fun
| runtime crazy?
|
| C# isn't perfect, but it has a lot of the modern things that a
| lot of people want that are available in languages like Kotlin.
| The tooling is first-class and the libraries from Microsoft
| work well.
|
| .NET offers AOT-compilation that doesn't involve a lot of
| trade-offs (mostly just binary size which isn't that important
| to most people). GraalVM is really cool, but also changes the
| performance characteristics of a lot of Java code and requires
| the community to think about re-orienting how they write Java
| programs.
|
| Go is a great language, but many people want more features than
| the language offers and that isn't likely to change.
|
| > I haven't seen that many projects written in C# that really
| impress me (like Java or Go excel at)
|
| If you're talking about libraries, it's likely that because
| you're not a C# dev you aren't looking at C# libraries. If
| you're saying, "well, I see Kubernetes in Go and Kafka in
| Scala/JVM, but I don't see any equivalent in C#/.NET," then
| yes: there are fewer large open source projects in C#/.NET. If
| I were writing your comment, I would have said, "I see fewer
| influential open source projects" rather than "projects that
| really impress me". You're probably not impressed by Kubernetes
| so much as you note that it is large and influential.
|
| I think C#'s lack of representation here comes down to timing.
| .NET Core (the first cross-platform .NET) is only 5 years old.
| At the time, we didn't know whether Microsoft was really
| committed to .NET Core or if it was just an experiment. By
| contrast, Kafka is 10 years old and Kubernetes is 7 years old.
| Both of those influential projects literally couldn't have gone
| with C# and .NET because they started well before cross-
| platform .NET really existed (beyond the unofficial Mono effort
| which didn't offer the same performance or sanction from
| Microsoft).
|
| If you're coming from the open-source, Linux-deploying side of
| the world, C# hasn't been an option very long. I would say that
| it started becoming clear 3 years ago that .NET Core was truly
| going to be the future for Microsoft.
|
| How many influential open-source projects do you know of that
| started in the past 3 years? Probably very few.
|
| Realistically, it will take a while for a lot of people coming
| from the Linux-deploying world to see C#/.NET as a viable
| ecosystem. It will continue to be viewed suspiciously by some
| people for a while. If you're looking for influential projects,
| they don't come along frequently. Hadoop, Spark, Kubernetes,
| Kafka, etc. are the kinds of things that you don't see every
| year.
|
| I don't think it's a reflection on the language so much as a
| reflection on timing and culture. I think C# is still thought
| of as the Microsoft-only, Windows-centric ecosystem that it
| used to be. I think people looking to create an influential
| project know that the broader community will accept projects
| written in Go, but it's unclear whether the broader community
| will accept projects written in C# - many people might just be
| turned off due to their preconceptions. So when you start the
| next Hadoop, Spark, Kubernetes, or Kafka, do you choose C# and
| potentially alienate part of the community who write off your
| project due to preconceptions about the language?
|
| Plus, there's a certain amount of inertia around some areas.
| Data science and ML are still heavily Python-based. It's not
| that Python is the best language for those things, but the
| community is familiar with it and so if you're creating a tool
| for that community you're going to make it in Python. If you
| make it in Go or Java, it will just languish without usage and
| without people improving it. Is that because Python is a better
| language for impressive data science and ML projects than Go or
| Java? I think it's more around community knowledge and
| perception (and the already built tools they might be familiar
| with and also want to use).
|
| > Also, and maybe this is unfair, but Microsoft's software is
| known for being buggier than one would expect and I imagine
| that C# is used a lot there
|
| Yea, that is just unfair. I've found C# to be so easy and
| seamless. No more headaches around builds, no more headaches
| about how to glue together Maven generating X while Hibernate
| expects Y while something else expects Z. I think part of it is
| that because C# was a Microsoft project for so long, the
| ecosystem didn't end up with as many camps in it. With Java
| there was Sun, IBM, and RedHat all kinda pushing similar yet
| slightly-distinct stuff. I think Java also fell into a problem
| where so many people tried to solve the "I just need a data
| class" problem that now we have a bunch of solutions that all
| act slightly differently and can lead to headaches.
|
| Realistically, this assertion isn't disprovable. "Microsoft
| software is known for being buggier": is it? As someone who
| truly hated Windows for a long time, I would definitely have
| been on that train a while ago. Is their software today of
| worse quality? Realistically, I don't use Microsoft software
| much and never really have. I don't really think it's worth
| addressing this more than I already have since it wasn't really
| a fair criticism to begin with based on a potentially spurious
| premise.
| smackeyacky wrote:
| Great comment. The only things I would add:
|
| 1. The seamless integration to things like containers
| (working with Docker Desktop is fantastic - and you can debug
| your code inside the container).
|
| 2. Razor pages. I gave up on hideously complicated SPA and
| use Razor now. The user experience is similar but it's a lot
| more secure generating everything on the server.
|
| 3. Deploy to AWS ECS or AWS Lambda with a few clicks. You
| need the AWS tools installed in Visual Studio but as a one
| man shop this is insanely productive.
|
| 4. Write it on Windows, deploy it on anything. The two use
| cases I use the most are things like Linux based containers
| but also ancient Windows servers in client environments where
| the infrastructure guys don't want to install new libraries.
| I wrote a small web slurping utility that had to be deployed
| on an old Windows Server 2012 machine and the self contained
| executable _just worked_ without having to install anything
| else.
|
| .NET Core has been fantastic for me.
| tester756 wrote:
| Handy and expressive language, power-full ecosystem (libs,
| community, tooling)
|
| Especially tooling, people might like it or not, but I think MS
| has really strong people working on languages and combining
| compilers and tools, so you have things like editing code while
| debugging it (at fly), evaluating expressions at fly, IDEs that
| makes you use refactor often and make your life waay easier and
| those are only things that I notice the most
|
| https://www.youtube.com/watch?v=bEfBfBQq7EE
| GiorgioG wrote:
| The reason you don't see many projects written in C# is that
| there are far fewer open source C# projects than Java/Go/etc.
| Most C# is written in-house (enterprises, some startups
| (admittedly relatively few.))
|
| I've been a .NET Dev for 20 years. C# keeps trucking along
| adding features at neck-breaking pace. That can be good and
| bad. Personally I wish F# had more resources assigned to it at
| MS. Having said that C# seems to be getting more and more F#
| features as time goes on.
|
| I did a small amount of Java in my career, and learned golang
| on my own time. Neither clicked with me or swayed me to
| consider a move to full-time employment using those langs. I've
| been learning Rust most recently and I'm considering looking
| for a job doing Rust.
| ska wrote:
| > Personally I wish F# had more resources assigned to it at
| MS.
|
| This absolutely. Or that they had avoided the usual NIH MS is
| prone to, and just supported another ML variant (thus
| reducing the load to match the resourcing).
| jpeter wrote:
| Bitwarden is written in C#
| (https://github.com/bitwarden/server). If you want a project
| that impresses you, look at Ryujinx
| (https://github.com/Ryujinx/Ryujinx)
| 369548684892826 wrote:
| Also jellyfin, and I guess Emby which it was forked from
|
| https://github.com/jellyfin/jellyfin
| [deleted]
| vorpalhex wrote:
| C# is a general language, not strictly tied to Microsoft (only
| dotnet was, but dotnet core fixed that generally).
|
| C# is a heavily OO language with powerful semantics. If you
| like Java but hate the JVM, C# is your friend. C# has
| traditionally had much better developer aesthetics than Java
| but that gap has closed some.
|
| Also worth noting the Java licensing has gone batshit insane in
| the last version or two.
| vips7L wrote:
| OpenJdk Is GPLv2 with class path exception. I don't know how
| that is batshit insane.
| kaba0 wrote:
| It was literally open-sourced completely to the last bits
| even - that was the update grandparent likely references.
| But it is without doubt a positive update, so there must be
| some misunderstanding.
| hawk_ wrote:
| i think there's more people in the hate java, love the JVM
| camp.
| StreamBright wrote:
| > but what's so good about C# nowadays?
|
| F# :)
|
| Seriously though, I think regardless which flavor you use .NET
| Core is pretty good. You can work on whatever platform you like
| and deploy to any platform you like. There is usually at least
| one good library for the most common tasks (http, database
| access, cloud, big data) you might encounter while working as a
| software engineer.
|
| > but Microsoft's software is known for being buggier than one
| would expect
|
| I am not sure about this. Microsoft's software is used a lot
| more than anything else. They invested in software quality and
| FOSS a lot since the Ballmer era. I am generally pretty happy
| with the quality of MS software I use (.NET Core, VS Code, F#).
| zwieback wrote:
| I think if you're not a Windows-centric developer it's a bit of
| a hard sell.
|
| Having grown up with C, then C++ I find C# as the best
| compromise: expressive language, garbage collection, good
| performance, non-fussy syntax. When C# first showed up it was
| painful because for every other thing you had to call out to
| native Win32 libraries but nowadays I almost never find myself
| doing that.
|
| Over the years the team added new language/runtime features at
| just about the right time: tasks, async, dynamic, reasonably
| tasteful collections.
|
| For me Visual Studio Enterprise is a big part of it as well. I
| like plenty of open-source alternatives but honestly VS is
| where it's at.
| haolez wrote:
| Yeah, I've heard that Visual Studio's debugger is awesome and
| has no competitors.
| tester756 wrote:
| VS' debugger allows you to manipulate code while debugging
| it, with some limitations e.g when you're writing COM code,
| but generally the craziest thing I did was putting
| breakpoint after SQL bad call, editing SQL string, at
| function exit adding call to itself with passing the same
| args, going into the same function and catching the same
| breakpoint while executing new SQL and then removing that
| function call and letting program continue.
|
| it allows you to evaluate expressions at fly
|
| it allows you to back in time (move e.g 2 LoC above)
|
| it allows you to use the Immediate window to debug and
| evaluate expressions, execute statements, and print
| variable values. The Immediate window evaluates expressions
| by building and using the currently selected project.
| msk-lywenn wrote:
| I still haven't tried it, but apparently rider is even
| better than VS. Especially for unity developers as it gives
| informations from the code as well as the Game asset files.
| ska wrote:
| > Please, help me correct my prejudices :)
|
| We could start with the one that MS code is notably buggy :)
|
| As far as I know most of the bread-and-butter consumer visible
| stuff is still mostly c++ (e.g. office suite, windows, etc.). I
| imagine there is a bunch of C# in Azure etc.
|
| I could easily be wrong, been a while since I've spent much
| time with anyone working there. But these things have momentum
| and clean rewrites usually fail.
| haolez wrote:
| I've had bad experiences and reliability issues with some of
| their software. For example: OneDrive for Windows, Teams,
| Azure AD, Windows Bluetooth Stack, Azure Functions, Azure SQL
| Database.
|
| All of those are mostly ok, but we encounter reliability
| issues on a more frequent basis than software from other
| vendors, like Amazon and Google.
| ska wrote:
| FWIW I wouldn't hold them up as a beacon of good practices
| either, but I've found them about average for issues,
| perhaps a bit better than average for response & docs.
| gavinray wrote:
| Background: I touched C# a little over 5 years ago writing
| ASP.NET MVC + jQuery apps and decided I hated it then.
|
| About 6 months ago I had a side project where I took a C++
| library and decided I'd try to translate it into every language
| that supports C/C++ Interop, to have a canonical "C Interop
| reference + comparison" repo for anyone interested
|
| I found out that C# could do this, and started looking into
| how.
|
| Long story short, it's now possible to use C# and .NET to
| directly interop with C/C++. Function Pointers, structs and
| all. You can publish a binary or static/dynamic library for any
| platform that's natively compiled -- zero dependencies.
|
| It allows you to manually allocate memory and provide
| allocation strategies. Shit, you can even turn the GC off
| entirely (at this point the language is very barebones).
|
| See ZeroSharp by same author:
|
| https://github.com/MichalStrehovsky/zerosharp
|
| So on top of this surprising viability for fairly low-level or
| native programming, it's also:
|
| - Just generally good at everything/bad at nothing
|
| - Blazingly performant, and getting faster consistently. Both
| at a language/computation level, and for things like web
| servers. ASP .NET Core Kestrel webserver has throughput only
| topped by a handful of Rust/C++ libs, and most recent preview
| included a new functional router API that increased throughout
| by +100,000rps.
|
| - C# as a language is evolving rapidly and has already become a
| solid multi paradigm lang. Adopting FP functional features like
| pattern matching and lambdas. It has LINQ. It's actually
| pleasant to write now and doesn't always feel like verbose
| enterprise garbage. (I prefer modeling entities as
| classes/structs + using pure functions for working with them)
|
| - The tooling and ecosystem of C# and .NET are rivaled only by
| the JVM. The developer experience and quality/depth of
| libraries available are fantastic.
|
| There's more but that's off the top of my head.
|
| Needless to say the last few months visiting C# and .NET land
| have changed my former opinion.
| quaffapint wrote:
| I was hoping to see in the readme how this is different than what
| they offer in core today? You can build self-contained exes (and
| they're getting better with each release). Is this the same only
| different or an improvement on that?
| np_tedious wrote:
| It's been a few years, but I worked on a dotnet core C# project
| once. Prod was Linux and dev usually OSX. I remember running a
| dotnet build to generate some kind of artifact (dll maybe) that
| still needed the SDK to run. Is there some other way to do it
| that made a self contained executable?
| atraac wrote:
| Yes, since I believe 2.1 you can make a self contained
| executable with sdk included using dotnet publish. You can
| read more about it here: https://docs.microsoft.com/en-
| us/dotnet/core/deploying/#publ...
| quaffapint wrote:
| The nice thing they also added was the ability to trim the
| self-contained app, so it doesn't include a lot of
| unnecessary assemblies.
|
| https://docs.microsoft.com/en-
| us/dotnet/core/deploying/trim-...
| gregmac wrote:
| Yep. One of the things I've been doing lately with some
| internal utility apps is building a small Windows exe (for
| Workstations where almost always the dotnet runtime is
| already installed), and a larger but self-contained binary
| for linux. dotnet publish -r win-x64
| -p:PublishSingleFile=true ---self-contained=false
| dotnet publish -r linux-x64 -p:PublishSingleFile=true
| -p:PublishTrimmed=true --self-contained=true
|
| To give an example of this for a reasonably complex test tool
| I have on .NET core 3.1, the Windows exe is 3.7MB and the
| linux binary is 38MB. I'm guessing there's some room for
| optimization in the process though, as the linux binary is
| compressed (tgz) to 13.37MB.
| mdasen wrote:
| Yes, .NET Core can now create self-contained executables.
| Microsoft and others have been enhancing this since it was
| introduced in .NET Core 2.1.
|
| I've been enjoying the way that .NET has been evolving in
| pragmatic ways. The initial implementation basically created
| a self-extracting zip that would include the runtime. That
| had its drawbacks, but it was a way for them to get self-
| contained deployable out the door with minimal hassle. Sure,
| it meant taking up a bit more space, but it worked and solved
| what most people cared about: having a single file that they
| could run without needing to install things in the OS.
|
| Likewise, they came up with ReadyToRun. Basically, they'd
| AOT-compile stuff for fast startup times, but include the
| byte code so that things could be JIT-compiled during
| runtime. This meant that the AOT-compiler didn't need to be
| perfect and that they didn't need to worry too much about
| things like the performance of reflection code. That code
| would end up JIT-compiled in long-running programs. Again, a
| pragmatic approach that does have some drawbacks (like large
| deployable artifacts), but they got it out the door and have
| been improving it as time goes forward.
|
| A more pure approach might be to wait until one can produce a
| really top-notch AOT compiler, wait until one can replace
| certain reflection-heavy code, wait until one can optimize
| libraries, wait until one can do lots of testing to make sure
| you don't have regressions, etc. But that requires a lot of
| time while what a lot of people might want isn't a pure
| solution, but just something that allows them to speed up
| start times.
|
| Likewise, zipping up the runtime with your code into a self-
| extracting and self-running file isn't the most pure
| approach, but it meant that you could get a single file to
| scp and just do `./myprogram` on.
| MarkSweep wrote:
| The self extracting is gone for Linux in .NET 5 and gone
| for Windows in the upcoming .NET 6. If any copying still
| happens, it just within the memory space of the process.
|
| If you include extra DLL or .so files, those still have to
| be extracted so that the operating system dynamic linker
| can load them.
| mdasen wrote:
| Yep! It's one of the things that's nice about the .NET
| ecosystem. We didn't have to wait for self-contained
| executables and got them back in 2018 (even if it wasn't
| perfect, it worked well enough) and they refined it as
| time went along in a way that didn't require me to do
| things.
|
| Microsoft could have waited until .NET 5/6 to offer self-
| contained executables "the right way", but they were able
| to create something that offered 90% of people what they
| wanted a few years earlier.
| cheschire wrote:
| self contained executables simply bundles the libraries, but
| still requires a JIT compilation to execute.
|
| The description of bflat is what you are looking for, and it's
| the second section of the readme.
|
| bflat implements a form of ahead-of-time compilation.
|
| This is closer to .net native conceptually, but that was only a
| UWP abomination.
|
| edit: replies have pointed out this is actually closer to
| ReadyToRun, a neat feature I was not aware of.
| trynumber9 wrote:
| What about with ReadyToRun and single file?
| vexna wrote:
| replied with this on another post, but you can add
| `-p:PublishReadyToRun=true` to your `dotnet publish` command
| to do AOT. it blows up your binary in size, but pretty much
| gives your warmed up code from the start.
| Shadonototro wrote:
| it doesn't fully AOT your app and worse it doesn't produce
| a native static executable
|
| it runs few tier for JIT, it still ship with IL and the JIT
|
| don't advertise ReadyToRun as "hey we got AOT at home, says
| Microsoft salesman"
|
| because all it does is makes me want to use Go instead, it
| feels and sounds bloaty
| loic-sharma wrote:
| Those self-contained exes need a .NET runtime to be just-in-
| time (JIT) compiled to code your CPU can actually run. This JIT
| compilation happens as your app runs, so your startup
| performance suffers as a result. On the other hand, bflat
| compiles your project ahead of time into native code your CPU
| understands.
|
| Also, to build that exe you have to use the .NET SDK which
| pulls in lots of tooling: MSBuild, NuGet, etc... It looks like
| bflat ditches all of that.
| vexna wrote:
| You can actually add `-p:PublishReadyToRun=true` to your
| `dotnet publish` command and it will do AOT compilation for
| you. It blows up your executable a bit, but it does pretty
| much give you warmed up code at the get go.
| mdasen wrote:
| It is different.
|
| .NET Core will create a self-contained executable which can
| have AOT compilation (or not), but which will include the byte
| code so that it can be JIT-optimized at runtime.
|
| This is about creating a binary that is small and uses some of
| the upcoming experimental stuff like Crossgen 2 and NativeAOT.
| Some of the Crossgen 2 stuff will land with .NET 6 this fall.
|
| As the project says, it's about bringing together two
| components that are being actively worked on in the .NET
| ecosystem to create a compiler and runtime for small binaries.
|
| For most people, you'll want the normal .NET self-contained
| Ready2Run binaries. They're compatible with everything and
| rock-solid. But sometimes you want to play around with
| something - like creating C# programs that are going to be
| tiny.
|
| Microsoft and others in the .NET ecosystem are improving
| C#/.NET at a rapid pace and it's great. bflat is, as it notes,
| using what is being created in that ecosystem. I mean, bflat
| literally labels itself "Initial proof-of-concept release" at
| this point. The guy writing it is on the .NET Runtime team at
| Microsoft and is really interested in these types of things. I
| think we can all imagine ourselves creating a project that does
| things a bit differently to figure out what is possible, figure
| out possible future directions we could take our work, etc.
|
| So, it is different from what is available in .NET today. It's
| written by one of the people on the .NET Runtime team who is
| interested in this stuff. Some of the concepts might show up in
| .NET 7/8/9. Heck, Crossgen 2 should be showing up in .NET 6.
|
| It's a cool proof of concept of slimming down C# binaries and
| even the readme shows how things like stack trace information
| takes up space.
| andrewzah wrote:
| Why would I use tooling that isn't open source?
| mdasen wrote:
| I think if the author of it were here, he'd say that this is a
| proof-of-concept that he was working on to play around with
| NativeAOT and Crossgen 2 so that he could see what could be
| achieved with them.
|
| Sometimes things get posted to HN as if they were "you should
| use this because it's the future" rather than "this is a cool
| thing I made to show what could be possible".
|
| In the author's own words:
|
| "I'm Michal, I live in Slovakia, and I work remotely at the
| .NET Runtime team at Microsoft.
|
| In my spare time I work on C#-related side projects that I find
| fun but don't particularly overlap with my day job. You might
| know me from my greatest hits such as "Let's make C# run on
| Windows 3.11!", "How about a snake game in C# running on DOS?".
| I also write articles such as the one on how I built a fully
| self-contained game in C# in 8 kilobytes."
| MStrehovsky wrote:
| (Author here, I hang out on HN.)
|
| Yup. There's really not much extra code in bflat compared to
| what's in the dotnet/runtimelab repo (in the NativeAOT
| branch). This just packages things differently so that one
| doesn't need the .NET SDK (plus Windows SDK if targeting
| Windows). The 100 MB bflat ZIP is all that's needed to target
| Windows or Linux.
| Arnavion wrote:
| I think if a compiler gets posted to HN as if it's being
| provided for general use, asking for its source code is
| reasonable.
|
| The author is perfectly within their rights to keep it
| private, and we are perfectly within ours to call it out.
| jonnycomputer wrote:
| Clever name.
| xaduha wrote:
| Brilliant name.
| lelanthran wrote:
| > Brilliant name.
|
| The name is a bit of a blunder:
|
| 1. Because of the placement of the in Flat, that's actually
| read as "FlatFlat".
|
| 2. The note D is the same as the note C#.
| dkdbejwi383 wrote:
| It would be better as Bx (B double-sharp), which is
| enharmonic with C#
| mrits wrote:
| I haven't played guitar in 20 years but I think D flat would
| have been a much better name
| titzer wrote:
| B flat (or A sharp) is the relative minor of C# major, so I
| think that is what they were going for.
| Zababa wrote:
| D is a programming language that's currently used, B is not.
| xaduha wrote:
| There are products where B stands for 'be' in combination
| with 'gone'. So in a way it says "be flat" as a program
| invocation, it's not just about notes if you ask me.
| kefka42 wrote:
| This is how I interpreted it. "Be flat", as in, be as small
| as possible.
| Shadonototro wrote:
| This kind of project is what could make me use C# instead of Go
| for my server needs
|
| Microsoft is sitting on a gold mine and they don't know it!! yet!
| bob1029 wrote:
| I have a feeling that Microsoft is abundantly aware of the
| value proposition of the new .NET ecosystem.
|
| C# has always been a good systems programming language. NET
| Core/5/6+ have just taken that to a new dimension with
| x-platform and better tooling.
|
| The best thing about the MS stack is that it is built for the
| 8000lb gorilla projects (I.e. their own internal stuff). If you
| have a unicorn solution that has 2000 projects and requires 36
| hours to build, visual studio, msbuild (dotnet build) are the
| things you want to be relying on to get you through the day.
| gavinray wrote:
| I've been using C# with recent features like Function Pointers,
| [UnmanagedCallersOnly], Dotnet Native Exports, etc
|
| Have been writing C# to interact with C/C++ and publishing C ABIs
| as static/shared libs that are natively compiled
|
| My mind has been absolutely blown with what modern .NET and C#
| are capable of doing in terms of low level/systems program and
| interop with C/C++/Rust etc.
|
| The performance and object sizes are killer too.
|
| I think most people don't know or think C#/.NET are capable of
| this
|
| Can envision a not so distant future where C# is a common choice
| for places when you'd typically reach for C++
|
| Also, the folks on the .NET Interop team are all super friendly
| and willing to have a conversation with you or answer questions.
| My experiences with the whole .NET organization at MS as a random
| person has been nothing short of shockingly pleasant.
| attractivechaos wrote:
| I really like C# as a language, but as a Linux programmer, I
| found it difficult to install the dotnet sdk without the root
| permission. With that barrier, I can't recommend C# over Java,
| D or Go which are much easier to install.
| cebert wrote:
| You don't need to install the SDK to run a dotnet core app.
| They can ship what's required to run and there's even single
| executable options now as well.
| josteink wrote:
| > but as a Linux programmer, I found it difficult to install
| the dotnet sdk without the root permission
|
| It's a tarball. Unpack it wherever you like.
|
| What exact problems did you have?
|
| Edit: I've even "installed" the .NET SDK on ARM/Aarch64
| devices this way. Zero issues.
| attractivechaos wrote:
| The lack of the ICU library. As you mention it, I searched
| around and found setting "export
| DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true" could solve the
| problem. I stand corrected. Nonetheless, adding an env
| variable is still an extra step especially when the dotnet
| cli doesn't tell you what to do. An enduser has to google
| around to find the answer.
| BuckRogers wrote:
| >An enduser has to google around to find the answer.
|
| Welcome to Linux?? Not to be sarcastic but if you want
| your hand held install Windows for your .Net development.
| It's pretty nice over there.
| pjc50 wrote:
| C# native interop is very, very nice.
|
| However, the build/package system for this is still a complete
| mess if you want to target more than one architecture; I've
| spent much of the week looking at the question of how to make
| cross-platform assembly A depend on platform-specific assembly
| B, where B is one of B-win or B-mac, and it seems to require
| carefully hand building B into a nuget package.
|
| I'm coming to appreciate msbuild, though. Or maybe that's
| Stockholm syndrome.
| guhidalg wrote:
| I second MSBuild as one of the best build systems I've had to
| work with. It absolutely has a learning curve but once you
| "get" how projects are evaluated and executed then you can
| start writing your own targets to do whatever you want.
| pjmlp wrote:
| Actually several of those features exist since version 1.0,
| because the CLR was designed to support languages like C++ as
| well, so there was always a way to access them even those that
| are only exposed after 7, but yeah bad M$.
| bob1029 wrote:
| > The performance and object sizes are killer too.
|
| > I think most people don't know or think C#/.NET are capable
| of this
|
| Take all of this amazing stuff and it also works on
| embedded/raspi4... I have been playing around with using C#8 to
| directly drive & sample GPIO. Who needs timer ICs when you have
| a busywait while loop checking the high res timer...
|
| Also, don't forget that you can go open an issue or submit a PR
| to any of the major .NET repositories right now, and expect to
| have your work (assuming accepted) incorporated into an
| official .NET release within a year or so.
|
| And tooling, etc. Check out visual studio 2022. Its available
| in preview now.
| dasb wrote:
| Shouldn't it be D flat instead?
| xaduha wrote:
| No, because then "be flat" part would be lost.
| ska wrote:
| Probably not? I think they are intentionally calling it the
| relative minor, not same note, which makes a kind of sense in
| the usual way punny names do (i.e. a bit of a stretch, but not
| ridiculous).
| Jap2-0 wrote:
| B isn't the relative minor of C#? I think that'd be A# minor.
|
| Edit: Actually B minor is the enharmonic equivalent of A#
| minor. IE another case of things in music that are the same
| but aren't.
| ska wrote:
| I thought of adding the comment about enharmonics but it
| decided it would muddy the water further and edited it out.
| Should have left it in.
| OscarCunningham wrote:
| > We need a name that's witty at first but seems less funny
| each time you hear it.
___________________________________________________________________
(page generated 2021-06-25 23:00 UTC)