61–70 of 107 posts
I love Go but am not a fan of .NET Have to ask what is the point of .NET is it even needed being the navel gazing MS fraternity?
C# is a great programming language. It's cross platform, and I personally find it fun and efficient to use. According to Tiobe index and stack overflow developer survey, it's also a lot more used than Go, so there's that.
My anti MS is a reflex from many years of torment!
Earlier quoted context omitted.
Things like Zig, D, Odin, Rust, etc, are outliers. Most new programming languages are used only by their creators. It's hard for a new language to find its feet, and make a name for itself. Unless its created by a big company with a lot of clout and internal users. (e.g. Rust, Go). People keep creating new languages because it's educational, interesting, and sometimes even fun. Doesn't mean they'll get used, and it d…
There is gleam that is popular, and not backed by a huge company. Then there is also lisette for Go, thats very similar but targets Go instead of the beam. New languages have space, and its just stupid "to stick to the only one i ever tried", then you just end like a PHP dev who just refuses to learn anything other than PHP.
Trying to hire Haskal programmers to keep your product alive will be significantly more effort than finding a C, Go, Java, Rust, or similar programmer instead.
I like languages, I explore lots of them, but at work I stick to "obvious" choices because colleagues use them, know them, and it fits into the shared infrastrcture. It's okay to introduce new things, but it requires buy-in, and persuasion. Not just one dev saying "That new CLI we wanted? I started in Racket/Odin/Wren/Lua/whatever."
Yuck. I like both Go and C# a lot, and use them both professionally. In my experience the strengths of Go are mostly - Deployability via single-file static binaries - Simple syntax that anyone can learn (no exceptions, no classes or inheritance) - Wicked fast compile times And the strengths of C# are - Powerful language with null-safety and lots of syntax sugar - Runtime-level coroutines so you don't need `async/awai…
> @DllImport("libc", EntryPoint: "strlen", CharSet: CharSet.Ansi)
I would argue that they made something I suspect many Go developers will dislike. I know I absolutely hate it. If I wanted to do things like that I might as well use C#. Then again, these days I'm shifting more and more of my development to either Python (which is objectively an awesome language that also sucks) or Rust. While one of my favorite features of any programming language is the Go modules with single folders and upper and lower cases for private/public. I am becoming a fan of how rust does structs with impl methods.
Anyway...
Earlier quoted context omitted.
> AOT is entirely independent of single file binaries. splitting hairs, but its is not independent. AoT is a required pre-requisite for single-binary creation. You can't create single-binaries with JIT. And that is the big hurdle, lot of libraries do not support AoT and that is the blocker to create single-file binary. Once you have the AoT figured out, the single-binary creation is easy.
Yes, you can. I am using that in production right now. An ASP.NET Core application as a self-contained single-file binary, without AOT. .NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already. See the documention here for the PublishSingleFile and SelfContained options: https://learn.microsoft.com/en-us/dotnet/c…
Earlier quoted context omitted.
What's missing in .NET AOT?
That’s a dishonest question, take any code base >10000 slices, it will not work with aot ootb. Read the docs of what’s missing, if you are honestly interested in what’s missing. https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Reflection, is one thing. Of course some runtime stuff are missing, but the problem is that no one is using source generators before trying out aot, so as soon you try aot you ju…
Reflection, is one thing.
Earlier quoted context omitted.
It’s slop
Could you expand on that?
How is this different than C#? What new concepts does this bring that C# doesn't? 20 years ago there was some momentum behind Visual Basic .Net; but the language was so similar to C# that it just wasn't worth using. There was a joke that .Net was a "skinnable language." BTW, there's a whole nitpicky/semantic argument that C# isn't null safe because of the null forgiving operator. That will probably come into play wit…
There was a joke that .Net was a "skinnable language." I remember the MS documentation had sample code in all the variants of .NET languages they created (C#, F#, VB.NET), and of course there were decompilers that let you choose which one to target, with many other translation tools available between them.
Go, C# and .Net? And here I am wishing for typescript-like language for backend systems.
Calling a language with `let` instead of `const` and async/await and iterators and classes "Go" is plain just incorrect. This G# is more similar to TypeScript than Go.
The ONE feature that C# really needs is payload enums with `match` instead of C#'s current pattern matching with `switch` anyways, and Rust is more similar to Go anyways so why not copy from Rust instead? I'm honestly baffled.