Hacker News Reader

Comment by cornholio | Hacker News Reader

Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something like Rust which forces you to constantly reevaluate your design before you even press the compile button, is ideal.

What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc. A language with the learning curve of Python, near C performance and strong safety guarantees of Rust. There is nothing that suggests to me such a language would not be possible. Swift and C# come closest but they are warped by their respective corporate overlords.

View on HN

> What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc.

The funny thing is that MACLISP could do this back in the early 70s. While Lisp is a dynamically typed, GCed language, MACLISP let you annotate variables to promise that they would only be called on certain primitive types, thus supporting compile-time optimizations for numeric code and not necessarily allocate memory, follow a pointer, unbox data etc. This was critical to make packages like MACSYMA run on machines with performance in the KIPS range.

Although languages like Python support similar declarations or annotations, they aren't used in the same way -- if you want performance you write the module in C++ and give it a python interface.

Somehow it is kind of tragedy of this industry, the amount of zig-zag it does between ideas and technologies, until mainstream finally adopts concepts that were already available during its genesis to a iluminated few.

> While Lisp is a dynamically typed, GCed language, MACLISP let you annotate variables to promise that they would only be called on certain primitive types, thus supporting compile-time optimizations for numeric code and not necessarily allocate memory, follow a pointer, unbox data etc.

And woe betide you if you happened to violate the preconditions of one of those annotations. That kind of programming is no better than C with "Segmentation fault. Core dumped."

The problem is that "system programming" or "embedded programming" isn't one thing.

There are people who want to throw around a zillion polygons at 144FPS. There are people who want max performance on x86-64 shoveling around millions of network connections. There are people who need guaranteed real time response or someone dies. There are people who need to stay asleep all the time to conserve battery and only wake up once every 5 minutes to chirp some RF.

These people do not have the same needs in a language yet they almost all wind up shoveled into C.

> These people do not have the same needs in a language yet they almost all wind up shoveled into C.

Why is that tho? There are better languages for each of those applications. What do you think, is it business requirements? Hardware? Regulation? Legacy code?

Are there better languages? What does it even mean to be better?

C is a great choice because I can hire people who know C and get good results. A domain specific language will not be much better than C for any of the above. It turns out that all the hard problems listed above are similar enough that someone good in one will be good in them all and so I can hire C experts from any field and get going fast without having to teach them my domain specific language that isn't really much better.

So does that mean you feel programming language design peaked in 1972?

No. However I think most "modern" languages make a big mistake because they don't address interoperability. Rust is great if you only write in rust, but if you have millions of lines of C++ it is really hard to fix a simple one line of code bug in rust. Rust cannot talk C++ - it can at least talk C but you lose the advantages of rust. Now imagine you have C++, rust, go, and ada teams fighting about which is best - they have to drop down to 1972 C to work with each other. (note that I carefully excluded D since D does have some C++ interoperability)

I do not know the best way for any modern language to take to any other modern language - but 1972 C is a big negative to them all.

Only on Linux and regular UNIX systems.

On other systems we have XPC, COM, AIDL, TIMI, MSIL.

Trade offs - I'm not familiar with all of those, but the ones I do know of are trading something for that flexibility - generally performance and power consumption - two things that we should not be willing to trade off. You can get similar things from UNIX as well, though it isn't the default and so you need extra effort to use them.

That said I fully accept your correction. (even though it doesn't apply in my world)

> And woe betide you if you happened to violate the preconditions of one of those annotations.

Umm, this is MACLISP we're talking about -- you know the types at runtime and can pass the unspecialized argument to an ordinary function. A kind of generic function I suppose, though we didn't use that vocabulary back then.

Just because this was 50 years ago doesn't mean that programmers were morons.

The point of annotations is to avoid having to branch on type at runtime.

Consequently, whatever you sent in was assumed to be what the annotation was. There was no "compilation phase" to ensure that the type at the call point actually matched the type in the annotation. If those differed, then your program would just go boom.

Now, it could be that I'm remembering something other than MACLISP. It's been a lot of years.

MACLISP was most definitely a compiled language, it’s just that like modern Lisps you could mix the two (compiled and interpreted code).

I tried to be clear by using the modern terminology “generic function”.

If you compile a function with those annotations you’d end up with two functions: one that could be called if you knew the types at compile time and one that did not.

Apparently I am confusing LISPs. My fault.

> Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something like Rust which forces you to constantly reevaluate your design before you even press the compile button, is ideal.

I was recently musing about this on Mastodon[0], commenting on a tweet that said something to the effect of "C++ isn't complex, it just doesn't lie about the complexity of reality". I think Rust is similar, and really any system language has too be. However, there's a space between lying about reality and fully reflecting reality where useful abstractions, such as Rust's lifetimes live. If you hardline the "lying about reality" framing, any abstractions on top of machine code must be ruled out. So while I see where you are coming from, I think lots of space to improve system programming, as Rust did.

> What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc. A language with the learning curve of Python, near C performance and strong safety guarantees of Rust. There is nothing that suggests to me such a language would not be possible. Swift and C# come closest but they are warped by their respective corporate overlords.

I agree about Swift fitting this mold, it's unfortunate that it has failed to gain traction outside of Apple's ecosystem.

0: https://infosec.exchange/@k0nserv/112399102914339131

.NET of today seems to stand out quite a bit in comparison to many other MSFT-backed projects. Especially if you look not at non-essential and possibly azure-related (a tiny part of ecosystem) tooling but rather at the "core" itself (that is, SDK, runtime and compilers) which is distributed under permissive MIT license which you can just take and do anything with.

To surprise of many outside of .NET community, it has much better performance than Swift[0][1][2] and lets you match performance of C and C++ in areas that matter.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (better performance for short-running benchmarks sensitive to JIT)

[bonus] C# AOT vs Go https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

(no direct comparison but Tl;Dr: ARC and Swift defaulting to virtual dispatch that can't always be elided with WMO results in Swift having much lower (even if more consistent) performance)

With AOT and "[UnmanagedCallersOnly]" you can even emit C# libraries that are callable from true native code using the C FFI.

Yup, you can even statically link them into C/C++/Rust/etc. (or vice versa)!

now direct

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Thanks!

Also wow, I stand corrected, Swift is a much stronger contender in Benchmarks Game scenarios than earlier microbenchmarks and research projects that I've seen would suggest. Particularly when using its own SIMD abstraction, it is likely LLVM makes very competent transformations, possibly merging narrower operations into a wider ones, replacing one set of intrinsics with another, etc.

However, still seems to suffer quite a bit, just like Go, in Binary Trees (it's not like C# does the best there either, the winners use bump allocators, and then there's also a 2.6s magic entry by Java, write barrier elision?).

It doesn't feel to me like much of C++'s complexity is just "the complexity of reality" being faithfully exposed.

I'd wonder whether that's just me being dim, but if so then I think Bjarne Stroustrup and Herb Sutter are dim in the same way. (Stroustrup, quoted approvingly by Sutter: "Inside C++, there is a much smaller and cleaner language struggling to get out." and "Say 10% of the size of C++ in definition and similar in front-end compiler size. ... most of the simplification would come from generalization.") And it doesn't seem likely to me that they are ignorantly overpessimistic about the complexity of C++.

C++ has a bazillion different ways of initializing a value, most of which contain syntactic footguns of some kind that don't do what you probably intended. That's not fundamental complexity of reality, that's messy evolution over decades coupled with the inability to break backwards compatibility.

C++ also does "lie" about reality in a lot of ways, in the sense that the actual compiled program behaves quite a bit differently than a plain reading of the code implies to a nonexpert. The most obvious form of this is the rules for effect ordering. Even the recurring complaints about the compiler doing unexpected things based on the as-if rule and undefined behavior seem to count here.

Actually, it has enough for having a 200+ pages book full of them.

"C++ Initialization Story: A Guide Through All Initialization Options and Related C++ Areas"

https://www.amazon.com/Initialization-Story-Through-Options-...

C++ is the poster child for incidental complexity.

The reality is people have 30 year old code bases, and so a messy evolution without breaking backward compatibility is and important part of reality. C++ could have been a much better language without backwards compatibility - but nobody would used it and so what is the point.

I don't think that C++'s rigorous adherence to backwards compatibility (include binary compatibility) is a bad choice. It has served the language well. It just has consequences.

> it just doesn't lie about the complexity of reality

"Undefined behavior" is not reality; it's a strange shadow world where anything may happen. The compiler reserves the right to reject your reality and substitute its own - which it will not show you within the language, nor let you choose or hint, nor warn you.

People like to use C and C++ as if they were a species of typesafe macro assembler that always produces predictable machine code, and that breaks down often enough that the world is full of systems-level CVEs.

People keep saying this, yet undefined behavior sanitizer proves in the real world it isn't an issue most of the time.

Most real world security issues have nothing to do with code. Social engineering breaks more security than memory issues. We are also skewed by many of the fundamental programs are written in C and so there is a lot of value in finding holes.

The US government official cybersecurity people have a different opinion. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre...

Nothing in that disagreed with my statements.

> "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used.

The question is: is it harder than it needs to be due to accidental complexity[1] in programming language design. TFA argues that there is still some accidental complexity in the design of Rust that leaves room for an "easier" language that still allows the level of control needed for a systems language.

[1] https://medium.com/@sharkaroo/navigating-complexity-in-softw...

There's definitely a bunch of accidental complexity in systems programming. Even in domains with extreme performance constraints, large portion of the code base could be expressed with simpler and safer semantics like MVS.

And Kotlin, and arguably Java and Scala, and possibly Dlang and Nim. There are a lot of strongly-typed general-purpose languages.

Yeah the JVM is quite fast at this point after it starts up.

It can even be helped to be faster with AOT/PGO, or JIT caches.

And while Android ART technically isn't Java (the plaform), its mixed execution mode with hand written Assembly interpreter, JIT, AOT with PGO shared via play store is quite cool.

>A language with the learning curve of Python, near C performance and strong safety guarantees of Rust.

Sounds like Go or Zig, though Go is slightly less safe and slower - in turn being much easier.

Though I'd reach for Go first if I'm working with anything concurrent. Concurrency is hard, and Go really helps with getting it right.

Go is not at all playing in the same league as Zig or Rust. Of course managed languages are more than fine for almost every use case, but I really hate this trends to wash go together with low-level languages for absolutely no good reason.

That's not just a trend. There are many areas of programming where a choice between Rust and Go is perfectly reasonable. Rust is playing on Go's turf, but Go isn't playing on Rust's, if you get my meaning.

F-Secure created USB Armory firmware in Go instead of Rust, exactly because they wanted to make the point of it being a possible scenario for Go, regardless of what the interwebs think about the idea.

USB Armory is still being sold.

Zig doesn't have anything like the safety guarantees of Rust.

Crystal lang also plays a bit into that space. It has a fairly expressive type system, good inference, checked nil type, and very approachable syntax.

C# nails this consistently, it's not worth hand waving it away because it isn't FOSS. Rust drama itself suggests that a FOSS language doesn't shield it from corporate meddling.

The C# compiler has an MIT license and is available on GitHub, which is about as FOSS as it gets.

https://github.com/dotnet/roslyn

The compiler is one thing, the ecosystem is another.

Sure, you can compile and host your .NET Core web app on Linux these days, but desktop applications are a completely different beast. You're often lucky if one exists at all, and if it does there's a decent chance it's not designed for "modern" C#-on-Linux. It really isn't a viable option yet, maybe in a decade or two.

WPF is MIT licensed, available on github. The fact that it's windows only doesn't make it less FOSS. Microsoft doesn't have incentive to port it to other platforms but other people and companies are free to do that.

WPF is not the best example of open source, as some components are still closed source. Though it only runs on Windows, a closed source operating system, so perhaps that is not so important.

https://github.com/dotnet/wpf/issues/2554

That said, there are cross platform, open source .NET UI frameworks out there, including one that is inspired by WPF:

https://avaloniaui.net/

Those are good points, but my problem with c# is that it isn't as performant in Linux. On Linux I'd suggest go as the more performant option. In any case I like both of those so much more than swift. Swift is slower even with bounds checks off. You can't turn them off in go.

> but my problem with c# is that it isn't as performant in Linux

Any evidence for this? From the benchmark game it seems like c# is more performant than go, and measurements are done on Linux.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I think it is because I generally look at a given benchmark there and don't browse below the "optimized" section to look at solutions that use intrinsics directly. Being able to use intrinsics directly is a great feature, but doesn't fit in with the whole "fast but not so fast I need to worry about safety" theme. When you exclude solutions that use intrinsics, go is faster. I use rust as my daily driver at work and home. I don't think I'd select either go or c# for a project. When I just want something that works, and I'm not worried about performance, rust is easy to use. It is only when I'm trying to squeeze out performance it gets hard. It is hard to convince go that it is safe to skip bounds checks, and while writing intrinsics isn't hard, it isn't very portable and you have to write lots of versions unless you metaprogram it, which I find harder than idiomatic code in any of these languages. Squeezing out performance is easy in c++, even in c++17, but it usually entails doing something that will "probably always be ok". Doing stuff like that repeatedly adds up to frequent issues.

> I generally look at a given benchmark there

Which? Just curious.

Some-of the spectral-norm programs seem quite similar:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Hi! Thanks for the update! I usually look at your curated list of "idiomatic/optimized/non-portable and unsafe" but in the list you noted the c# solutions faster than go had intrinsics.

Those benchmarks were debunked, they don't represent anything.

Where were they "debunked" ? Please share.

You just need to look at the c# implementation.

Here's a Go program and a C# program. Please explain your comment —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The issue for me with languages like C# is the lack of expressiveness.

Sometimes classes aren’t the abstraction I want to use.

That’s why I like kotlin over Java or c#. It’s be nice to have a language like that which targets .net

C# offers multiple options for abstracting away functionality. What do you have in mind?

Also, JVM ecosystem does not offer the ability to provide zero-cost abstractions, which C# does with monomorphized generics. This is a hard requirement for productive systems programming if you don't want the C level of verbosity.

> Also, JVM ecosystem does not offer the ability to provide zero-cost abstractions

This is true, wasn’t thinking about that.

C# always requires me to use and organize my code into classes and my data into objects.

For example, If I wanted to use higher order functions, I need to wrap functions in callables (Objects).

If I wanted to throw together a quick script to test, I need to set up a program which uses some magic configurations so that I don’t need that entry point class.

Granted I only worked with C# professionally for a couple of years before getting back to a Go shop, but it always felt like trying to avoid thinking in objects was fighting against the language.

Personally, I like just having first class functions which take simple data structures as arguments. Modeling the world as objects just isn’t as clear to me (the old OOP vs FP discussions)

Languages like C# and Java turn me off for that reason.

Exactly.

I used C# for a long time, and when I started using JS, I marveled at the directness of its expressiveness, its lack of ceremony.

What's actually needed is a language as direct as JS, with the bad parts stripped out, types and a proper standard lib added, and compiled to byte-code for performance.

They can call it a different name if they want.

Yeah that “directness” you’re talking about is what I call “expressiveness”

It’s important for how I like to code.

You might like AssemblyScript (https://www.assemblyscript.org/)

Are you sure you are talking about C# and not some other language? There is no such thing in C# as "callables". It has lambdas, Funcs and delegates.

It has always had a fair share of FP features and only gained more as it kept evolving. It had higher order functions partially in the form of method group to delegates conversions since C# 2.0, released 19 years ago and to a full extent in the form of lambda expressions since C# 3.0, which also included LINQ, released 17 years ago. It is a mixed-paradigm language.

On the off chance that this is trolling, I must point out that Java and C# are sufficiently distinct, with the latter leaning more heavily on offering both lower and higher level features like extensive pattern matching, LINQ, structs and pointers/byrefs.

If you do have C# snippets you are unhappy with - please post them. There is likely a better way.

(I noticed you posted about Callables twice, and had a quick search - it appears to be a Godot-specific abstraction imposed on C# due to inadequacy of GDScript it has to interoperate with, and has nothing to do with C# itself)

Unity and Godot are both a bless and a sin for C#'s adoption.

In one way, they help the adoption in the games industry, in the other hand they introduce so many anti-patterns with their reflection based SDKs, and use of magical methods instead of proper .NET code.

Callable may have been the wrong word. I think I meant delegate. (I do work with Godot, but not in C#. Some wires must’ve gotten crossed)

Regardless of the actual word, there is an extra thing I need to do to pass a function to a higher order function as an argument.

I was using this as an example to demonstrate how C#’s support for the language features I like require some ceremony which reduce expressiveness and require me to think about the language more.

You didn’t. The example does not exist and the terms you used don’t apply to C#.

Post an actual example (code).

Delegate is a C# term and was what I was talking about

https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

I need to create a delegate for any function I want to pass around.

Trolling is bad, consider asking ChatGPT or reading documentation first, thanks.

    var func1 = (int i) => i + i;
    var func2 = () => func1(1) * 2;
    
    Console.WriteLine(func1(4) + func2());

Valhala might help there, but yeah, we are still a couple of years away and currently the best is to manually model memory with the new Panama API, definitly not the same league as C# / .NET today, which I consider the closest modern language to what Modula-3 has promised us.

In what ways is C# the closest to Modula-3's promises?

Now that AOT is part of the standard toolchain, with plenty of Midori, and C++/CLI capabilities also exposed to C# Language level, a memory safe systems language with a modern type system.

I would also place D and Swift into that bucket, only D never managed to really take off when it had the opportunity, and Swift is clearly at home in iDevices.

Thanks.

You should try Java and C# again. They have added lambdas and the support for high order functions is quite good. Sure, there is missing some things like guaranteed tail call optimization.

I have tried C# recently.

They have support for these features, but they require some ceremony to use (like wrapping function arguments in a Callable), which increases friction, signal to noise ratio, and decreases the expressiveness that I want.

I just want to write what I want without having to think too much about how the language wants me to write it. Go is good for that. JS too, but has a lot of historical cruft.

I feel like your "recent" must have still been years ago. Modern C# is as terse as Python/TS/Js for basically any equivalent task, if not more so. Dotnet 8 even make the following possible:

var foo = [1,2,3];

Add on switch expressions, primary ctors, first class functions, no ceremony in Program.cs anymore... it's hard to get more terse and expressive unless you want lots of chained single symbol operators (look at F#).

(slight correction: `var foo = [1, 2, 3];` requires natural types for collection literals (it needs to infer the best type for var), this is coming in C# 13 (.NET 9, this November), but otherwise `int[] numbers = [1, 2, 3];` works)

You're right! I remember some session where they talked about wanting to infer a natural type for stuff like that but its obviously a big question. But as you said declaring the type directly allows it to work. However the other nice part is that you _can_ do this:

void myFunc(List<int>){}

myFunc([1,2,3]);

The expression sytanx can infer the type from the caller syntax so you can just inline the array declaration.

My recent was a month ago, but to be fair, the CTO of that company (who wrote the existing code when I joined) last wrote production code in 2008, so his code may have not been using those newer syntax features.

Yeah it's very easy to write Java style C# that is incredibly verbose and rigid, but once you understand modern c# you can see how it's this really great (imo, awesome) hybrid of functional/typed languages. They've done a ton of syntax work to let types get out of your way when you need them to, with the ability to always fallback to rigidly declaring them when you need better readability.

The downside of all this is that the only people that know how awesome C# is are people who are already doing C#. Growing the pot and trying to convince people to give it a go in its modern (post dotnet 5/"core") iteration is like pulling teeth. Everyone assumes nothing has changed since like C# 2, and given the fact it's a "boring" language that doesn't have Hacker Hype behind it, people just ignore it.

Every week you have people on HN wishing for something that does exactly what C# does but don't want to give it a shot or admit that C# is _actually_ an incredible language and toolset that does exactly what they want (and more).

.NET has explicit tailcalls - they were made for and are heavily used by F#.

https://learn.microsoft.com/en-us/dotnet/api/system.reflecti...

https://github.com/dotnet/runtime/blob/main/docs/design/feat...

Actually they were made for other languages given the original goal of Common Language Runtime, as published on the 2001 release note.

https://news.microsoft.com/2001/10/22/massive-industry-and-d...

Anyone with the pre-release MSDN .NET SDK that was initially made available to MSFT Partners, with alpha documentation written in red, has a folder with tons of functional languages that could take advantage of tail calls.

F# only came later into the picture, even considering its OCaml for .NET origin.

Not the person you replied to but, today I learned!

As an aside, and as someone who's currently going through materials such as Crafting Interpreters (and who knows what else based on suggestions from r/compilers), is there a, I guess, guide for people who want to implement a compiler that targets the CLR/CLI?

I have a copy of CLR via C# 4th edition, but other than that not sure what else I can reference targeting anything newer than .NET Framework 4

I don't have something that could be of Crafting Interpreters level on hand, but the general suggestion given to this question on DotNetEvolution discord by Roslyn team members was to start with the spec itself: https://ecma-international.org/publications-and-standards/st...

This might be a bit of a learning curve if you don't have experience with writing compilers like that though.

There are other materials that might prove useful should you go down this path:

- A series of blog posts of a student who is writing a Rust to .NET compiler which you could follow along: https://fractalfir.github.io/generated_html/home.html The project itself: https://github.com/FractalFir/rustc_codegen_clr

- A video series on writing a compiler for .NET from scratch: https://www.youtube.com/watch?v=wgHIkdUQbp0&list=PLRAdsfhKI4... Notes: https://github.com/terrajobst/minsk/tree/master/docs

As for CLR via C#, while it has certain facts that remained the same, the ecosystem has changed a lot since then, you really want to target the latest LTS to get best experience and performance. If you liked it, then I can strongly suggest https://github.com/dotnet/runtime/tree/main/docs/design/core... which covers .NET runtime internals.

p.s.: if it's any consolation, the promise in CLR via C# of JIT having the advantage of dynamically profiling code execution and compiling to profile-guided version, tuned to the exact hardware and environment is finally fulfilled, many years later :)

I think that's what they are trying to achieve with Mojo.

Agreed, although the language still feels like a tech demo. They don't even have a package manager yet. I'm curious and hopeful to see what it looks like in a year

They don't yet have `class` support.

They have their own version called struct which works in a very similar way. I feel like this should be mentioned when saying that `class` support didn't yet exist

Yes, you're right and struct is _the_ interesting part about mojo and is enough to write interesting things in it.

Floodgates will open though once class is also supported.

Posted this Chris Lattner interview about Mojo to HN yesterday. The video is just 6 days old. It's on the Developer Voices channel.

https://news.ycombinator.com/item?id=40285414

I really must suggest Nim.

The D programming language is mostly this, or could be this, however it has several flaws. It still isn't as polished and doesn't have the ecosystem, and is sort of trying to be Rust, C# and Python at the same time which doesn't always work out that well. But when it does, it is amazing. It also has some crazy and unusually powerful metaprogramming abilities.

Isn't Java better than Swift/C# ? (more open, green threads, better ecosystem).

Someone prefers Java over Swift/C#? Now I've seen everything.

Debateable; I much prefer the dotnet ecosystem, even if it's less open. I suspect green threads vs C# async is another matter of taste as well. Plus Oracle is a much more annoying overlord for Java.

C# has value types, stackalloc, simpler FFI and a rich SIMD API, offering far better control for low-level code than Java. I don't feel green threads is a system level concern, and while Java's ecosystem is huge, it's also very enterprisey. Also, I'd disagree with more open, C# is under a more permissive license and Oracle has actually been litigious over Java.

While I also favour C# over Java, the languages, the runtimes it is a bit different, given the wide spectrum of JVM implementations in the wild.

Lets not forget that C# only exists because Sun won the lawsuit over J++, where several C# features were born (J/Direct => P/Invoke, events, JFC => Windows Forms, COM support), and Ext-VOS (the COM next generation runtime) paper refers to J++, before COOL became C#, and J# was introduced as migration path from J++.

Ironically, after all these years, as means to keep Azure relevant for the Java community, Microsoft has become a OpenJDK contributor by acquiring jClarity, including ARM support on Windows, better escape analysis, and has their own distribution.

And VSCode plugins for Java, developed in collaboration with Red-Hat, are much better than C# Dev Kit, without requiring a Microsoft account.

The only features DevKit offers are Visual Studio style solution and test explorers. You don't need either DevKit or a Microsoft account to use base C# extension.

The description is confusing though. I suppose they did the whole "rebrand" thing because for years everyone thought poorly of experience of writing C# in VSC while it has always been semi-decent (depending on your skills) and got better recently, especially after moving to Roslyn-based LSP from Omnisharp.

How is Java more open than C#?

Its features are driven by a consortium of Java companies, even if Oracle does the majority of the development.

This allows for a spectrum of JVM implementations, where basically any CPU capable of running some form of Java implementation has a JDK available.

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

Likewise, most frameworks are driven by set of companies, based on industry standards, where .NET due to its culture, most Microsoft shops tend to only adopt what comes from Microsoft.

It is a long discussion problem in the .NET community that when many FOSS projects finally manage to get enterprise adoption, Microsoft ends up coming with their own solution, which said enterprises then switch to, thus killing those FOSS efforts.

Listen to big podcasts like .NET Rocks, where this tends to be often discussed with their guests.

I don't see how any of that means that C# is less open. Microsoft drives C# feature evolution from community feedback, so is that less open than a consortium of commercial interests?

Does Microsoft somehow prevent anyone from developing a CLR implementation for CPUs they don't support? The only reason the JVM is everywhere is because they had first-mover advantage.

How does Microsoft developing their own solution to a problem "kill" FOSS efforts, exactly? Microsoft's solutions are almost all also FOSS. Is competition some kind of inherent problem? Or is a large corporation creating and maintaining FOSS a problem? Why aren't you annoyed at those enterprises that started adopting the original FOSS projects, but didn't contribute dev time to maintaining them? Instead you're annoyed at Microsoft for creating its own FOSS and paying to maintain it for the community for free.

I just find most objections to .NET so bizarre, it's almost always knee-jerk Microsoft hate.

It's been 25 years since the release of C# and 30 since the release of Java. The fact C# isn't everywhere Java is has nothing to do with "first-mover advantage" as you call it but is due to the fact that C# is open-source software, which is not the same as Free Software. Java, even Oracle's Java, is controlled by the community; .NET is controlled by Microsoft. That's the difference.

C# and VB compiler suite, MIT license: https://github.com/dotnet/roslyn

.NET virtual machine, MIT license: https://github.com/dotnet/runtime

SDK, MIT license: https://github.com/dotnet/sdk

You were saying?

It's Microsoft-driven, not community-driven. For the past 25 years the Microsoft camp has either never understood, or hasn't cared about, that distinction.

Each of those links shows thousands of contributors not connected to Microsoft, but do go on believing there's no community, or that it's a terrible thing that people rely on Microsoft to produce a free, open source, solid product they can depend on. That's the reason it's Microsoft-driven, because they've mostly been doing just fine as a steward, and it being MIT licensed means MS knows the community can take over if they step too far out of line.

Not the point. Who's leading? That's the point. Not impressed with your example of a corporate behemoth using free labor. That's the wrong kind of Free.

> Not the point. Who's leading? That's the point.

No, the point is, who cares as long as everyone is happy with the direction?

Not quite the same thing though, is it? And if you're not happy with the direction then you're stuck.

I think this may be a better way to explain it. Supposed someone comes up with a C# proposal that defines a way to introduce the Result type enum system that Rust has as a replacement for Exceptions. Supposed this is a pretty solid plan, easy transition, we can make a magic button that all the code bases when upgrading to the next version of C# just has to press the magic button and its done. No more expcetions, you now have Result return types. Lets also supposed this proposal has a large amount of the community on board with it. At the end of the day, that proposal will live or die by someone (or some group) at Microsoft.

Now granted, I don't know if it would be different with Java and Oracle. But that is the point. A significant enough change proposal for C#, supposed like above, a change proposal that goes against where Microsoft thinks the development path of C# should be, that is the important bit. So long as contributions and feature request align with Microsoft's interest, its all good, but if the community has large support for a contribution or change request that doesn't align, then it may be different.

Addition: Although arguably, this is true for most languages. Even FOSS languages have some type of leadership that those big shifting proposals will live and die with. Not intending to cast anyone in a bad light, but just a project leader and a project I am familiar with. If a proposal that was as ground shifting as the proposed above was suggested for Zig, whether or not the project does it, the decision of whether to do it may live or die depending on Andrew Kelly or his close knit team of contributors to Zig. Same could be said about Rust, the project has leadership and they could kill a popular proposal. Even outside of languages. The linux kernel, a feature or restructure may live or die by the hand of Linus Torvalds.

Not exactly related to conversation but given that you mentioned (discriminated) unions, here are notes on recent design work:

https://github.com/dotnet/csharplang/blob/main/meetings/2024...

Would be really nice to have. I hope we can get it with something like optionals you see in Rust or Swift. And really, with optionals, something like Swift's guard let statements.

> So long as contributions and feature request align with Microsoft's interest, its all good, but if the community has large support for a contribution or change request that doesn't align, then it may be different.

Speculation about what Microsoft may do or may not do in response to community pressure is a weird kind of criticism. I can invent all sorts of fictional boogeymen too. What if Linus has a psychotic break and wants to make the Linux syscall interface mimic the Windows NT kernel?

People would do exactly what I'm suggesting here: fork and continue development without him.

As you also say, leadership means leading, and Microsoft takes backwards compatibility very seriously, and that's why people trust them and use their offerings, sometimes instead of open source offerings.

A change like that would invalidate every tutorial and document ever written about C# over 25 years, so is it really C# anymore? I don't think anyone would make that change. It's simple to fork the MIT licensed C# compiler, call it C* and make that transition in a language that is definitely no longer C#. I just don't think this is a good example.

For good examples, see the language evolution that has actually taken place which has been community driven in many cases. Records, tuples, the evolution of type constraints have all been started from community feedback, and are backwards compatible.

As a final note, a comment on "aligning with Microsoft's interests". They are interested in two things for .NET: selling Azure hosting, and incentivizing Windows programming. Making the software development experience pleasant, robust, predictable and backwards compatible are the objectives, so devs are incentivized to pay them to program on their OS, target your program to their OS, or run your software on their cloud infra. I really don't see the problem.

Java still has the Java Community Process. Oracle has a thumb on the scale, but it's still a largely community-driven process. The .NET community has nothing even approaching this level of community and openness. Microsoft is in the driver's seat.

Why would MICROS~1 hate be something bizarre?

I find such hate quite understandable. I might not share it, but I would not put any trust in MICROS~1 either, especially not in a professional setting.

When I develop applications for MICROS~1 platforms, I do it in Java, betting that the Eclipse foundation and a plethora of corporations, including MICROS~1, aren't going to suddenly team up and do something nasty to the language and important libraries. With MICROS~1 as the lone manager of a language and most of its 'ecosystem' this seems like a real risk.

> With MICROS~1 as the lone manager of a language and most of its 'ecosystem' this seems like a real risk.

Why? All of the code is MIT licensed. If MS does anything untoward, forking it is trivial.

Sure. Organising a community to care for the fork is not.

Ximian and Mono were built almost immediately after .NET was released and provided a decent multiplatform community-supported alternative for years, but you somehow think that forking an existing and working codebase would be more difficult than a completely independent reimplementation?

Look, there are obvious differences in how Java and the JVM are maintained and evolved as compared to .NET, but to continue claiming that these differences really matter all that much is just FUD, to put it politely.

I made no such comparison.

No, it's not. Is Mono independent today?

So far I haven't had jdb refuse to open because it wasn't running inside of an Oracle-provided mystery meat build of NetBeans.

Oracle’s lawsuits, esp copyrightable API’s, makes me default on staying away from anything they make. I’d leave any platform they acquire, too. There’s many open platforms whose owners or backers aren’t as aggressive in lawsuits as Oracle is. Many have strong communities of contributors, too.

The only reason I’d use or contribute to Oracle I.P. is if I was paid to do so. The other is porting off Java but that’s legally risky if minima changes. CPAChecker was the one I was thinking of. Past that, I’d try to avoid Java.

I mean, Go and Java have those properties, but achieve them using managed runtimes.

The first thing that crossed my mind reading this comment was Nim. It’s pretty Pythonesque (but that’s kinda what I hate about it.)

I love Go, but it certainly doesn't have the safety guarantees that Rust has. You're not going to have a memory leak or use-after-free, due to the garbage collector, but you have nil pointer dereferences and data races.

I have seen more leaks in the golang project I currently work on than in most C++ codebases I've worked with in my career. It's trivial to leak stuff in golang, and much more difficult to make sure that you don't

Ok? Is it not trivial to leak in unsafe rust? Managed memory is safety. And frankly, OOM termination is not unsafe. If you crash the host because you ate all the system resources, that’s a different thing, and Rust doesn’t fix that either.

And it's trivially easy to ignore an error.

Also channels and WaitGroups are easy to misuse (well, that's why there's also an ErrGroup now).

I'd make Golang my 100% go-to language if it got rid of several footguns.

Though let's be real, that's absolutely certain to never happen, they take their backwards compatibility extremely seriously. So we'll have to keep relying on checkers and linters that alleviate some of the pains somewhat.

I'm not aware of any serious Go project without linting and tests.

In fact, most projects I've worked on won't even merge a PR with ignored errors.

Also, `go test -race` is a Go feature, there's nothing wrong with using it.

go test -race is awesome and everyone should use it.

But it's worth remembering that it's a dynamic analysis that only covers access patterns created by your tests.

Strange, I've worked on complex projects in the distributed space with Go and it's very easy to catch these things with `-race` and linters.

nil dereference isn’t unsafe.

It's undefined behaviour, which is even worse!

Nope. Nil deref in Go is checked, and simply panics, just like array access out of bounds.

Also, data races in Go are trivially addressed using the common pipeline / CSP pattern, since channels are serializing. Of course, it doesn’t eliminate the possibility of doing stupid concurrency things, and you could of course argue that giving users trivially easy concurrency primitives encourages stupid concurrency, but I think it is fair to say that in most cases, Go idioms and primitives make race-free concurrency pretty easy. You have to go out of your way to write racy Go, and there’s nothing really preventing people from going out of their way to write unsafe Rust, either.

Nim?

Checkout Mojo

What's actually needed is to start with JS, and:

- Strip out the bad parts.

- Add types, more functional features, a proper standard lib, and a standardized module system.

- Allow compilation directly to performant machine or byte code.

They can call it a different name if they want.

Why start with JavaScript?

Why not?

Because it seems so very far away from your goal. What is it bringing to the table that makes it the best starting point?

As a front-end interface, JS is pretty good.

- It has simple, straightforward, and pleasant syntax/semantics. Except for a few tweaks here and there, there is no need to re-invent the wheel here.

- It is pretty functional, all that's needed is to add everything-is-an-expression

- It supports multiple paradigms (functional, imperative, OOP)

- Since it has no types currently, a _modern_ type system can be feasibly added, supporting concepts like result/error instead of exceptions, maybe/option, pattern matching, etc.

- It has easy-to-reason about async features

- It has a huge ecosystem; it shouldn't be hard to port many high-quality packages to a similar language

Now, the lower-level features are another matter entirely, but it shouldn't be too difficult to retrofit what we want, like multi-threading (maybe building on top of workers), utf-8 strings, and so on.

If you change the language, you have no ecosystem. You cant say, it has a big ecosystem "if everyone ports their code". By that logic all languages have a big ecosystem. Anyhow. JS has much unexpected strange behaviour, i really would not recommend such a language in 2024.

So let's take out the "unexpected strange behavior", that's what all I'm saying

With so many sweeping changes you could take any currently popular scripting language as a base.

> It has a huge ecosystem; it shouldn't be hard to port many high-quality packages to a similar language

...Spoken like a person who's never coded anything meaningful or serious, if you can't even gauge the complexity and man-hours needed to create (much less port) high-quality packages between programming languages.

No need for that flippant response. You do not know the work I've done, so don't assume I don't know what I'm talking about.

Talking about "man-hours" tells me you think of software engineering like an assembly line, which it is not.

There are whole lot of factors that might influence the time needed for such porting; the keyword in my comment is "similar". If the new language is a superset of the original language, minus a few warts, I'm not sure what should take so much time. For one thing, the architectural design of the packages (which probably took most of the original effort) remains the same.

Reply on news.ycombinator.com