> they have countless times said they aren't associated with that project
Right, but they are visibly are. Russ Vought (project 2025) is the Office of Management and Budget director. He drafted the executive orders months ago that would lead to exactly this. Part of Project 2025
Other members in Trumps cabinet from Project 2025:
- Tom Homan (Border Czar)
- Brendan Carr (FCC)
- John Ratcliffe (CIA Director)
> The rest of your post is just hysteria so I won't comment on that.
Maybe don't accuse others of hysteria while you spout that Democrats are the ones coordinating every independent attorney and judge to come after Trump.
> In every instance, he has said he is not affiliated with it and doesn't support it
You sound like you were born yesterday. If you can't imagine why a politician would say one thing and do the other, I really can't help you. You're maliciously ignorant.
> real people don't talk about their stalkers so much. When I was stalked and harassed I kept the details light and didn't provide much in the way of actual community details because I went to the FBI and local police to deal with it
You actually provided more details here than he did, so I guess that's not true.
>> Suffice it to say, I ended up traveling for most of the year, all the while having to handle various abusers and stalkers who harassed and attacked me and my family (and continue to do so).
If anything, I am more doubtful you had stalkers since you are also in this thread saying this[1]. What an unsympathetic reply. You certainly don't come off like you're aware of the stress and fear that can bring if your answer to other people being stalked is "rethink your life choices."
> Sounds to me like you just need to take a break from the internet friend. If you're that high profile that you're getting hit over and over, maybe you need to rethink your life choices. If it bothers you that much especially.
> "the downright biblical flood of COVID misinformation that emanated from the right" is not a fact - it's an emotional plea
The term "flamebait" is also an emotional plea, but we trust adults to use their brain and decide how to report that in good faith.
"Biblical Flood" is a euphemism indicating "a lot of" misinformation (which is a fact [1]) and anyone not being willfully obtuse could interpret what the commenter meant. but I suppose it's easier to immediately dismiss that very true statement than engage with it.
Incorrect. Emotional pleading is a logical fallacy wherein one manipulates the emotions of the listener in an attempt to convince them of an argument without actually supporting it. Labeling something "flamebait" is a characterization of the tone of an argument, and whether it appears to be designed to incite low-quality discussion/flaminess, which is orthogonal to the argument itself. An argument can be flamebait without containing emotional pleading, and vice versa. The two are unrelated, and the fact that you so confidently state that they are indicates that you don't actually know what either of them are.
> "Biblical Flood" is a euphemism indicating "a lot of"
Yes, I know that - and that's completely irrelevant as to its factual nature. It's still an euphemism designed to manipulate the listener, and is something that is impossible to prove factually. There is no objective test for whether something is a "Biblical flood" (and you can't even get different people to agree on what meets the threshold for it) - you thinking that it can assessed as true indicates that you don't have a good handle on what it means for something to be "factual".
> which is a fact [1]
Copy-pasting journal article links is not an argument, and that article in particular doesn't support the point that you think you're making.
> Labeling something "flamebait" is a characterization of the tone of an argument, and whether it appears to be designed to incite low-quality discussion/flaminess
Which is also not measurable and manipulates the reader. I don't see the readers comment as flamebait. Just because misinformation comes from right-wing media and people have eyes to see that and call it out doesn't make it flamebait. What should we call it? An unknown amount of totally apolitical misinformation from [insert party here]?
> It's still an euphemism designed to manipulate the listener, and is something that is impossible to prove factually
As are most arguments when we use phrases like "a lot", "similar to", etc. If you dismiss things based on such broad criteria, I am puzzled by your comment history. You have told users they are bad and support Tyranny[1], said it's malicious to support infrastructure spending[2], and called Snowden a narcissist (which proves he had no altruistic motives?)[3].
These are not emotional statements supported by an argument, these are arguments supported by emotional pleas.
And a simple cmd+f shows "Emotional plea" is a phrase you do not use sparingly either. You are using this word very broadly. If you cannot hold yourself to the same standards you hold other users, you aren't debating in good faith.
You have obviously constructed a belief system that makes it impossible to engage with things you disagree with while allowing yourself to lash out at users however you see fit and bring up whatever politics suits you.
> Copy-pasting journal article links is not an argument
An argument is not a theoretical bottle exercise for one to wordsmith their way towards not engaging with the facts. In the real world, we have eyes.
Yet most people can still recognize it when they see it, it's relatively easy to provide good heuristics ("is it unnecessarily politically partisan? does it bring up irrelevant examples?"), and is against the guidelines.
> and manipulates the reader
I already pointed out that the characterization of "flamebait" is not an emotional plea, as you incorrectly called it, and you didn't respond to that characterization at all and merely ignored it, so I can only conclude that you're inventing some other definition to fit the word.
Regardless, it's also against the HN guidelines, so we can safely put aside the problem of whether or not it's appropriate to point out, because it is.
> I don't see the readers comment as flamebait. Just because misinformation comes from right-wing media
...and that's why you don't see it - because you're pushing the same political agenda that they are.
This is also deceptive goalpost-moving - the poster didn't just say that "misinformation comes from right-wing media", but that it was a "Biblical flood" from "the right", which means an objectively large quantity, which neither you nor they have provided any evidence for.
It's pretty clear that that comment is flamebait. It made a politically-charged claim meant to attack a particular political group that had zero evidence for it, which you have also provided zero evidence for. Most of that user's other comments have been flagged and the account was eventually banned, which pretty clearly shows that they were engaging in flamebait.
> people have eyes to see that and call it out
Yet more emotionally-manipulative rhetoric. You still haven't provided evidence for these claims, either (although even if you had, it wouldn't excuse this).
> I am puzzled by your comment history.
Yet more emotionally-manipulative rhetoric (you are clearly not puzzled - you're personally attacking me), coupled with profiling, which is an ad-hominem that is extremely inappropriate (for HN, and for anywhere) and bad-faith.
> said it's malicious to support infrastructure spending[2]
This is a straight-up lie. I said "Proposing that we should continue to throw more money at infrastructure, before diagnosing and fixing the problems that are causing that inefficiency [...], is straight-up malicious." This is very different than what you claimed I said. You read my comment, and lied about what I said.
> and called Snowden a narcissist
Which is an irrelevant, intentionally misleading and out-of-context fragment of what I said - which was saying that he had narcissistic tendencies as an explanation for his actions, not as a means of trying to distract from an argument that he made.
> And a simple cmd+f shows "Emotional plea" is a phrase you do not use sparingly either. You are using this word very broadly. If you cannot hold yourself to the same standards you hold other users, you aren't debating in good faith.
More profiling. This is not appropriate for HN. Please do not do it.
> You have obviously constructed a belief system that makes it impossible to engage with things you disagree with while allowing yourself to lash out at users however you see fit and bring up whatever politics suits you.
This is yet another character attack - again, inappropriate for HN. As we've seen, you're also willing to lie about my words, so this assessment isn't based on fact anyway.
> An argument is not a theoretical bottle exercise for one to wordsmith their way towards not engaging with the facts. In the real world, we have eyes.
More emotionally-manipulative and deceitful rhetoric. Also, it's worth noting that you ignoring my point and instead proceeded to link-drop like it proved your point.
This is completely irrelevant to claims that there's been a "downright biblical flood of COVID misinformation that emanated from the right".
I don't need to read the others - if you have a claim that you want to make, you can source the claim from the paper, because given that you lied about what I said, the burden is on you to prove that your claims are based in reality. Posting a link is not proof behind a claim.
If you can't argue in good faith without profiling other users, making personal attacks, making partisan political comments, justifying guideline-breaking behavior because you agree with the opinions made, claiming that your opinions are "facts" without providing evidence, sneering at people who don't agree with said opinions, and actively lying about other people's words and claims, then you shouldn't comment on HN.
Please do not respond if you can't avoid doing the above - especially if you can't avoid lying about my own words back to me.
I'm not sure how someone could see Kotlin as more expressive than Python, unless I am misinterpreting what expressive means. Python has a good language features and helpful abstractions like list comprehensions.
What makes Kotlin more expressive? I understand it has some functional features but I've never seen anything dramatically flexible.
Kotlin's standard library has ruined me for other languages, especially its collections library. The consistency and comprehensiveness of its approach to collections is unmatched in any language I've tried, including all the big name functional languages. It's hard to get across what's so great about the library in writing because it's not just one standard library function, it's how they all interact with each other and how they interact with the language design—you really just have to try it to understand. The net result is that transforming data from one shape to another flows effortlessly, with the dot operator seamlessly connecting a stream of transformations. The fact that it's the dot operator also means that you get really great autocomplete to help you on your way.
Python, meanwhile, has always felt pretty awkward to me when it comes to data transformations. Comprehensions are okay, but they feel like they are special casing what should be a bunch of standardized helper functions operating on lambdas, as a sort of ugly workaround to the fact that Python refuses to implement proper lambdas. And when you can't use a comprehension, you're stuck with a pretty awkward collection of helper methods that are hard to find and use correctly and which are severely handicapped in expressivity by the lack of a proper lambda.
That's interesting. I've heard complaints about Kotlins standard library in comments like this[1]. I understand they may be nitpicks but they seem annoying in practice.
That's on a thread that specifically solicited complaints though.
These are all reasonable but some are just lack of familiarity with the JDK standard library, or the reasons why things have to work that way to begin with.
For example, ArrayList not being immutable/thread safe. Although there are collections libraries that give you snapshot based collections, like this one:
... I've never seen anyone use them because this is almost always the wrong design. Atomicity is usually needed at a coarser grain than a single collection, at which point you're needing to think about locking or transactions anyway, and if it isn't then the JDK standard library already offers concurrent lock-free lists or Collections.synchronizedList() which will give you the same effect. Having an object be mutated out from underneath you by a separate thread is a possibility of basically every language with shared memory. Only Rust tries to solve race conditions in the type system and its solution introduces many other problems.
He also complains that integer width/signedness casts only offer help from both the type system and the runtime! That's pretty good compared to other languages. Then he complains unsigned types are about the underlying bits not the semantic meaning of the number - well, yes, this is unintuitive but exactly the same as every other language because of the weirdness that inherently emerges when mixing signed with unsigned types. Java refuses to add unsigned numbers at all and they have their reasons for that! Unsigned numbers are really only meant for working with binary data formats, not encoding that something can't be negative. Use a jakarta.validation with a framework like Micronaut or Hibernate Validator if you want that.
Likewise for date and times sucking. If you use the long since deprecated classes designed in 1995 then maybe those suck by modern standards, although they're great for beginners. So don't use them: java.time is a modern package that treats timezones rigorously, at the cost of being a bit harder to understand.
Hmm, coroutines are definitely a bit of a mess, but in ways that aren't super relevant when you just want to use them and not implement a framework on top of them. They definitely sacrificed implementation simplicity in favor of interface simplicity.
> don't even try to tell me that anyone uses sealed classes in practice
I use sealed classes for errors all the time.
> Nothing is concurrency safe.
Yes, but I know of no stdlib of a serious alternative that is, so I don't think that's a major concern. Don't use concurrency and you're no worse off than Python (the alternative here), and if your point of comparison is Java or similar then it's the same story there.
> All of the numbers suck. The fact that I can just call Long.toInt().toUByte() and lose a bunch of information and/or wrap a negative value into a positive value, etc, without any kind of help from the type system (maybe returning nullables) or the runtime (throwing exceptions for truncation) is gross.
Similar to the above: yes, it could be better, but it doesn't bring Kotlin's stdlib below any other major language I'm familiar with. Heck, even Rust lets you do those downcasts without a word [0], you're just supposed to know that downcasts can lose information. Lints can help you here if you care, but I don't think a language gets points docked for not having them by default—there's a balance to be struck between too few and too many explicitly-typed failure cases.
> The Map API sucks. Map::getOrElse is literally implemented incorrectly-it will call the "or else" function if the value is present in the map but is null.
That... is fair. I've never actually noticed it before, but it's wrong. The rest of the Map API has always been good for me, though.
> Dates and times suck.
In every language ever.
> I don't like how the default for the collection combinators is to be eager.
They acknowledge that they have no answer here, and neither do I. There's no pattern for Kotlin to follow because only Haskell does lazy-by-default, and Haskell isn't a model most people would want Kotlin to follow.
All in all, I read a comment like this as someone reaching for the things that irk them in a language that they actually really like—which means the items that irk them are either extremely small or actually just broken in all major programming languages.
Yes, but I took their use of "default" to mean that there's slightly more friction to a sequence. It does seem a bit petty given how little friction there is, though.
And the syntactic sugar where `foo({ a -> a })` and `foo { a -> b }` are the same makes code so much more readable.
I've done Python for a project at a previous job for a few months and it made me realize just how awful Python is, especially because you can't chain functions on collections as easily as you can in Kotlin. I also made me realize that I don't like dynamically typed languages.
Lambdas in Python are intentionally second class citizens in that they cannot be full blocks, only a single expression. Technically there's a workaround in that you can define a named function and then refer to it later, but that's enough of a hassle that using lambdas in method calls is much less common in Python than it is in Kotlin.
In Kotlin, much of what would normally be special syntax structures are just function calls that get passed a lambda. That's not possible with Python's single-expression lambda functions, so you get special syntax instead for things like comprehensions.
As someone who uses Kotlin for work and Python for side projects (and loved Python years ago in college), Python's list comprehension feature is one of the things I hate the most about the language now.
As a simple example using only two collection functions I find it much easier to read
val hundredOrLessEvenSeconds = (1..1000)
.toList()
.filter { it <= 100 }
.filter { it % 2 == 0 }
.map { it.seconds }
than
hundred_or_less_even_seconds = [timedelta(seconds=it) for it in range(1, 1001) if it <= 100 and it % 2 == 0]
But there are tons of helper functions in the collections library to express that in a variety of different ways. But not in a gross code golf way, with clearly named functions
Not that I especially want to defend Python, but can you elaborate a bit on why you find that chain easier to read? The Python version is straightforward enough - if it's just the absence of newlines you can write
hundred_or_less_even_seconds = [
timedelta(seconds=it)
for it in range(1, 1001)
if it <= 100 and it % 2 == 0
]
Also, I don't know Kotlin well enough, but is what you wrote going to be efficient? The Python version iterates once and creates one list (and you can actually turn it into a generator and make zero lists just by swapping the square brackets for parens); to my untrained eye, it looks like the Kotlin version is going to do more iteration and make four separate lists, three of which are just garbage to be thrown away immediately. Here that probably doesn't matter, but in other cases it might be a big problem; is there an easy/idiomatic way to avoid that?
Also the map function lets you perform any operations in it. It was a simple example but you could need to perform something slightly more complex than using another standard library function.
> it looks like the Kotlin version is going to do more iteration and make four separate lists.
Someone with kotlin experience could comment too, But I don't think it creates four separate lists. The last map function iterates and asks for element from previous function which asks for element from its parent function. So there is only one list.
What if you want to filter on the mapped value in python? Or group by something and work further on the groups? It's almost unreadable after a few operations.
In that case I think the "Pythonic" thing to do would be to have some named intermediate steps:
foos = (make_foo(bar) for bar in bars)
acceptable_foos = (foo for foo in foos if acceptable(foo))
...
Depending on your circumstances, this may or may not be awkward (coming up with temporary names can be hard), or may or may not be a good idea anyway (naming things can help make the code more self-documenting). I can't reckon how it could become unreadable, per se - what do you mean by that?
That's kinda my point, though. It becomes either awkward or unreadable. You chose awkward in your solution. But simple things as mapping, sorting, filtering quickly becomes unwieldy. Either you have to make it lots of unnecessary steps, potentially also lots of function definitions because of the lack of proper lambdas, or you end up with filter(groupby(map(filter(...)))) trying to figure out what is going on.
What you’re doing, what you’re doing it, and any conditionals are all out of order. If you to translate the Python semantics into say, Rust syntax, you would have something akin to
.map(blah(x,y), |z|, if let (x,y) == conditional(z))
Gotta be real, I don't see any difference in readability (assuming it was formatted the same way, and honestly I'd prefer a different variable name than 'it' in both cases but I get that would require more boiler plate in kotlin and 'it' is a common invention).
The main difference imo is that kotlin uses more "syntax" while python uses more "English" to express the same thing. Also the half-open interval for range but that's an arbitrary decision that benefits some cases more than others (although my preference is the closed interval)
Pythons list comprehensions are sort of fun, but occupy that space because the language designers throttled the alternatives pretty hard.
I used to write a lot of Python, I now write a lot of Rust, and the Rust iterator chains feel inordinately more powerful, and list comprehensions feel semantically backwards to me now: what you’re doing, what you’re doing it to, and whether to do it conditionally are all out of order.
To me, Python feels “expressive” because you can “do stuff to make it work” not because of any inherent design that lets you properly express what you’re trying to do.
The biggest thing that wouldn't be available in Python would be the DSLs. Often they are not my favorite and overused, but they can be very expressive for things like their charting example https://kotlinlang.org/docs/data-analysis-overview.html#kand...
As somebody who uses and likes both Kotlin and Python (and quite a few other languages), I'd be cautious with using a subjective term such as "more expressive", too, but I can possibly shed some light on where such feelings come from.
Personally, I see Kotlin as the closest thing to a statically typed Smalltalk that we have among major languages, and that's a major draw.
A key part here is that Kotlin closures are fully-featured equivalents of Smalltalk blocks (up to and including even non-local returns [1]), whereas in many other languages that falls short. Java does not allow mutation of local variables and Python restricts lambdas to normal expressions.
I find code whose behavior can be parameterized by code to be an essential feature of modern-day programming and this should be as frictionless as possible.
This is also a situation where syntax matters, and while it isn't quite as nice as Smalltalk, Kotlin's syntax (esp. with trailing closures) make such code as readable as possible in a brace-style language with minimal additional syntactic noise.
In a similar vein, the functionality of Smalltalk's cascades is offered through scope functions [2], especially `.run {}`.
But ultimately, fully-featured closures (and the fact that they are widely used in the standard library) power a lot of the things that people seem to like about Kotlin.
That does not mean that there aren't downsides. The limitations of running on the JVM are one (e.g. while Kotlin has workarounds for the JVM's type erasure, they're still workarounds), and then Gradle is arguably Kotlin's weakest point (which apparently even JetBrains are seeing, given their investment in Amper).
That said, personally I'd say Kotlin's static typing and performance would be the primary reasons for me to reach for Kotlin over Python, not necessarily expressiveness. Type annotations in Python + mypy etc. just aren't the same experience, and writing performance-sensitive code in Python can be very tricky/hacky when you can't delegate the hot paths to numpy or other existing C/C++/Rust libraries.
Conversely, Python often has a leg up when it comes to fast prototyping and scripting, even with Kotlin Worksheets in IntelliJ IDEA and with kscript.
[1] Which, to be clear, are a nice-to-have thing, not essential, but still impressive that even that was covered, when previously Ruby was the only major language I know of that did it.
> But there was a lot of misinformation that the studies themselves were fake
That was not misinformation. The idea that Ivermectin was helpful in dealing with CoVID was determined from a meta analysis that included a fake study that nobody can confirm happened and even used dead people. It was pushed by grifting doctors who sell Ivermectin.
Yes, if you have parasites and take an anti-parasite drug you're gonna feel better, whether you have CoVID or not.
> the tide of misinformation saying that the vaccine would halt COVID
It halted it as much as it could considering 30% of people didn't complete vaccination. I finished and have had every booster and never got CoVID despite all of my family members getting it (who refused to get vaccinated).
Any support for open source or cross-platform stuff was a bulwark against claims of monopoly abuse, but none of it worked well enough to be a true replacement. Mono worked for some purposes, but it was far from the first party support cross-platform .NET gets today. Nowadays it sounds like .NET Core + third-party GUI libraries is the way to go.
> Nowadays it sounds like .NET Core + third-party GUI libraries is the way to go.
For reference for those unfamiliar with the terms:
.NET Core was the name given to the cross-platform fork of the .NET runtime.
It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.
It ran on various distributions of Linux and MacOS.
At the same time there were forks of other libraries/frameworks in the .NET ecosystem to have 'Core' variants. Often these were dropping support for legacy parts of their code so that they could run on Core.
Later versions of .NET Core brought over support for a many of the things that had been dropped.
.NET Core and .NET had stand-alone versions until .NET Core was renamed to . NET and became .NET 5.
So, if you want to do the most modern cross-platform C# you would use .NET 9.
More or less. any version of .NET >= 5 is cross-platform and is a direct descendant of the "Core" side of the fork, and so has no "full framework, windows only" variant.
It is "Core" in a lineage sense, but there's no need to make that distinction any more. The term "Core" is out of date, because the experimental "Core" fork succeeded, and became the mainstream.
I've been a long way from Windows development for a while, so missed that shift. I knew it was coming since moving functionality to the open source thing seemed to be Microsoft's target (with some skeptics doubting it, understandably). I didn't know it already happened.
The shift is slow, but it has been ongoing for years, and is pretty much wrapping up now. .NET 5 was released in November, 2020 and that was the "beginning of the end" of the shift over.
For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not that the host OS is something that we have to think about often.
For this, .NET 3.x "the full framework windows only version" services are regarded as very much legacy, and I wouldn't go near one without a plan to migrate to a modern .NET version.
However, YMMV and people are also making windows desktop apps and everything else.
Quantity of languages might be less important than: how many needs are served by those languages, whether the ecosystem is dynamic enough to keep expanding served niches, and whether the culture and community is likely to produce language support for a niche that matters to you ever or on a realistic timeline. The JVM does appear to have a lot more niches covered, but you can still do all the things those languages do in what's available for the CLI.
I don't know much about the current state of CLI and .NET beyond what I've read here, but it sounds like it's dynamic enough to keep expanding. I also don't know enough about the long tail of niche languages supported by each to know which direction they're headed.
That's the situation with the tools used for music production. In theory, any DAW (Digital Audio Workstation) can make any kind of music. In practice, they all move toward different kinds of music, and you'll run into increasing friction as you do weirder or more complex stuff if you pick the wrong DAW. Cubase can do electronic music, but you're better off with FL Studio or Live. Live and FL Studio can do orchestral, but you're better off with Cubase.
And I'd guess there's a similar dynamic with CLI and JVM and the languages that target them.
It's a fork with a lot of modifications (mostly removing deprecated stuff and making it cross-platform). You can still see a lot of ancient stuff in the sources such as referring to the base Object class as "COM+ object" (.NET was originally envisioned as a successor to COM).
>An early name for the .NET platform, back when it was envisioned as a successor to the COM platform (hence, "COM+"). Used in various places in the CLR infrastructure, most prominently as a common prefix for the names of internal configuration settings. Note that this is different from the product that eventually ended up being named COM+.
Correct, the bytecode wasn't even 1:1 compatible. They then brought over missing pieces, and consolidated .NET Framework features into .NET Core, thus becoming just .NET to end the dumb naming war, since everyone calls it .NET anyway...
Good write up that wonderfully encapsulates how stupid Microsoft’s naming is - you didn’t even mention .NET standard.
I love .NET. It’s a great stack, especially for backend web apps. Blazor is a great SPA framework too. But I loathe how Microsoft continue to handle just about everything that isn’t the framework and C# / F#. It’s laughable.
Oh don’t get me wrong - I wasn’t criticising your write up. It was concise and still relevant.
It’s just funny for newcomers to peel back the onion more. Writing a source generator? Target .NET standard 2.0 (not even 2.1) for a whole host of reasons.
The ".NET" label was applied to a bunch of things at Microsoft.
It was also an early name given to their social networking / IM things.
But for the last 20-ish years it's really only been applied to things related to the .NET Framework.
So, yes - Visual Basic.NET is a language - it's the language that replaced Visual Basic 6. It compiles to the Intermediate Language (IL) that the Common Language Runtime (CLR) executes. There are other languages that compile to IL, too like C#, F#.
The .NET Framework is really a bunch of libraries and tools that are packaged together.
The .NET Standard is a standard that allows you to build a library to a known set of supported libraries and IL / CLR features.
So, yes, depending on which specific part you're referring to - it's all of those.
The "Xbox Series X" is such a nonsensical name that only a marketing department could come with it. And this entire line of names exists solely because someone thought that nobody would buy a "Xbox 2" instead of a "PlayStation 3".
Because X's mean moar marketing power... Like the Extreme X870E X motherboard... There's multiple X's and Extremes and the X's mean extreme... so it's moar extreme!!!
Among the other small nits in your otherwise concise post... the windows only versions of .NET (1-4) were known as .NET Framework. So, Framework is the only windows only version, followed by Core being a limited feature set but cross platform and then .NET 5 (no suffix) being a full featured version that is cross platform.
I'd argue that the dominance of Linux on cloud and Azure growing business is what's causing Microsoft to have an ongoing interest in linux support.
A factoid that's shared sometimes (no idea if true) is that Microsoft now employs more Linux kernel engineers than Windows kernel engineers due to Azure.
That came after. Linux wasn't even on 2.6 with its famous stability yet when this kicked off. What you see now is a result. They softened on open source as they realized it actually has some benefits for a company like Microsoft.
The Microsoft of the Halloween Documents[0] is a different Microsoft from the one we see today that understands open source as something good rather than as a threat, and it started with Microsoft being forced to play nice.
After having gouged Red Hat and Suse for years with their bogus Linux patent racket and bankrolling the infamous SCO Unix lawsuit. Make no mistake M$ coming over all We Love Linux was like Donald Trump turning up at the DNC.
I do remain skeptical that the node on the Microsoft org chart that usually strangles anything good the companies does is waiting to strike. It used to be Windows node, but now it seems like the ad node comes in for the kill most of the time. The company is slowly morphing into Google as Google morphs into Amazon, while Amazon is morphing into UPS.
Off-topic but to join in the general good vibes this announcement emanates: i have to say that my experience using Azure cloud has been stellar. Their co-pilot integration works well, IME. Azure shell is simple and good. Dashboard UI is always good.
Bona fides: I have used GCP for 3 years, AWS for 3 years, and Azure for ~ 1 year. As well as the more "bare-metal" types of cloud providers like Linode/Akamai, and Vultr -- all the latter of which are great for self managing your infra.
I also really find the ability to spin up Windows Server and Windows 10/11 etc super useful for builds, testing, Hyper-V.
I really like Azure for huge projects with many moving parts.
More like it was shoring up for developers who use and/or target mac and linux. Many devs are using macs and targetting linux for deployments. MS wants Azure to be a first class option for developers and is the focus for making money going forward. It makes sense for their developer tools to offer that.
Azure didn't exist. OS X had just come out and almost no one took Macs seriously as a development target yet. Windows was the only user-facing thing anyone developed for aside from little Java games on flip phones. The Web 2.0 takeover was still years off and Internet Explorer ran the show.
Is "historical context" not as clear as I thought? You're the second person to challenge this by pointing out the current situation when I'm talking about how we got here.
Then you're not talking about what I was talking about in the post you replied to with a framing that suggested you were disagreeing. Did you click the wrong reply link?
Mono implemented the GUI stuff like Windows Forms, do the latest windows cross platform stuff support that? Can you run .Net GUI windows program on linux without Mono but using the latest .Net thing ? I know it was not possible in the past.
The whole point of .NET-Core was to remove all the (largely desktop-oriented) platform-specific dependencies that tied it to Windows, so you could run server-oriented .net programs on Linux. So no, afaik you can't simply run GUI apps built with .Net on Linux desktops - that's the reason Mono wasn't simply killed, because it covers that niche (which wouldn't even exist, were it not for Mono/Xamarin's efforts back then. But I digress...). Nowadays there are a few other attempts at providing that UI layer.
.net Core still has Windows Forms thoguh? At least I (for kicks) migrated one of my old .net 4.something projects to .net core and it still works and shows the classic Windows Forms GUI.
.Net Core on Windows has support for loading assemblies that reference COM interfaces and the win32 API, along with other things that aren’t supported elsewhere like C++/CLI.
That’s why loading System.Windows.Forms still works, it’s not part of .Net 5+, but it can still load the assemblies on Windows (they still use GDI, etc under the hood).
Sure, nobody wants to write Winforms new applications today
My point is about running existing applications on Linux,
there are still issues with running .Net GUI stuff under wine and Mono was not a perfect implementation.
I read in other comments that the newer .Net cross platform stuff is not a replacement for Mono for running this old applications. (nobody will rewrite them to use the current GUI stuff from MS since are old apps)
No, Microsoft's .NET only supports WinForms on Windows. They do have an official cross platform GUI toolkit in MAUI, but it strangely does not support Linux.
Last I knew it is also considered pretty lackluster. Every time I read up on it it feels like, even beyond the lack of Linux support people just don't care for it.
If I was building a cross platform native app with .NET I'd probably use Avalonia right now.
Yeah, the took an age delivering it, then it came out and most of the early reports were “It’s still not ready.” and then I think Microsoft just gave up.
I think not supporting Linux was a tactical error, though. Some people will put up with a lot for Linux GUI support, and some of those people are the types who can resolve problems with your half-baked GUzi framework.
Does it really need help? I struggle to imagine a scenario where one would consider MAUI not supporting Linux to be an issue (if we discard superficial bad faith concern) when Avalonia, Uno or, if you care about Linux as the main target, Gir.Core exist.
And, at the end of the day, you have a tool with an extremely rich FFI capability so whatever is available from C you can use as well.
Sorry I clearly was not clear enough. I mean specifically an issue with MAUI itself. I agree dotnet/c# have some solid UI options cross platform at this point. MAUI however seems to be at best a mess and at worst dead in the water.
> "The future is already here – it's just not evenly distributed."
Were I live and work (IT and consulting in central south-east Norway) it has been the year of the Linux Desktop on and off since 2009.
That was the first time I worked full time at a place that deployed Linux for everyone and everything that didn't have a verified reason for needing Windows.
I think we had one 3rd party trading software running on a Windows machine and maybe the CEO and someone in accounting got Windows.
Everyone else was upgraded to Linux and it worked beatifully. It was my job to support the sales department with desktop related issues and it was absolutely no problem to do it while also being a productive developer.
Since then I have not worked on a place that required Linux, but I think most of the places I have worked on since has had Linux as an option as long as you supported it yourself, and some places also have been very active writing how-tos and working with me to troubleshoot issues that were related to Linux, since many of them were also Linux users.
At the moment I use Mac, but at my current job I'm also allowed to use Linux.
Open Source Support reasons. If Linux developers want better MAUI support there is a "Community Repo" to contribute to and help move things further along. The impression is that if things were further along it might get formally "adopted" (by the Dotnet Foundation) for "official" out-of-the-box "support", but it isn't far enough along and doesn't seem to have enough contributors with enough momentum. It currently seems that the Venn Diagram of "Developers that say they want MAUI support for Linux" and "Developers that would contribute to Linux support for MAUI" has too small of an intersection.
Sure, Microsoft could pay more employees to work on it faster, but Linux loves and prefers open source from Linux devs "untainted by Microsoft", right?
Contribute to the Maui backend for GTK and/or Qt, nothing is stopping you
Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno
It is not perfect, there are issue depending if you need 32 or64 bits or if you need .net4 or greater. Games work but I have issues running tools like mod managers, game save cleners that are made with .net . In my case Sims3 works fine but not the Sims3 Launcher(this tools has more features then just launching the game like importing custom content/mods )
Sadly some Java tools stopped working if you run latest Java runtime because for some reason some crap was removed from Java and nobody made some easy way to add them back with soem package install.
With commercial applications that want to just take their existing code and have it run on Linux with only a couple lines changed, Avalonia XPF will do that
You are expected to use Avalonia or Uno for multi-platform targeting or Gir.Core (GTK4) or one of the many other binding libraries for Linux-specific GUI.
Also very easy to throw something together on top of SDL2 with Silk.NET.
Practically speaking it is in a much better place than many languages considered by parts of Linux community to be more """linux-oriented""".
My personal use case is running old GUI apps, I am not planning on writing GUI apps with .Net , MS had the opportunity to open source .Net/Silverlight and make money from tools but they bet on Windows and today most apps are node and javascript, a much inferior platform but MS open things up too late.
No, they pretty much gave up on winforms when .net core morphed into "the" .net that is cross platform. There are some nice crossplatform gui libs now though.
If true this would be huge. I got burned on the whole silverlight, Universal Windows Platform, WPF etc. All these new and improved solutions had all sorts of issues, no designer, no or weaker accessibility stories, bloated, slow etc etc.
C# + Winforms would be appealing. Some of the performance with larger datasets in the new solutions (tables etc) was just surprising. I really feel like Microsoft got so distracted chasing phones, tables, touch etc they forget just basic line of business application development which they could and should have owned.
.net Core doesn't supply WinForms, but WPF is the far more common paradigm for Windows apps now. WPF is supported by projects like Avalonia on Linux. There are also a few other major alternative UI toolkits, more commonly used by cross-platform (vs Windows-exclusive) developers.
This is the "virtual monorepo", if you want to clone one repo and build the entire SDK product then this is the correct thing to checkout - but development work right now still happens in the separate project repos, of which there are ~20
No it's way better than Flutter. Avalonia really works on desktop.. :). Also the model is WPF so whoever know a little bit of legacy .NET framework will be able to write Avalonia apps in no-time
I don't know any .net, and have never heard of this until now. Only stories with comments on HN are from eight years ago. Although I liked the screenshots on the linked site, it doesn't seem to have much buzz around it.
And unfortunately, the only stench I can't stand more than Google's is Microsoft's.
I do not follow buzz. I am an engineer by education and attitude and always try to investigate my options based on my needs and requirements. I use buzz only to drive me trough my investigations. In my case I had a desktop application that had to run on Windows and MacOs and needed support for Rich text format and rendering of custom graphs.
Following buzz I started to do a prototype with Flutter and stopped after a few days as I found out that most of the open source controls I was using had bugs on Windows Desktop. Then I moved to MAUI and discovered that in order to have some decent Rich Text support my only option was Blazor Hybdrid. Nedless to say I found bugs that prevented my prototype to work correctly. Then I moved to UNO and found that it doesn't have full Rich text format support. I was able to find some .NET open source libraries for doing text layout on Skia and with that I was able to find a partial solution that was however pretty complicated. Out of curiosity I investigated Avalonia and found that everything that I needed had full support. Being fluent in WFP I built the prototype in 3 days and I never looked back.
Your experience might vary depending on your fluency of WFP but I found that, considering Windows Desktop as a target platform, Flutter and MAUI are absolutely the worst options.
In my opinion Uno is better than Avalonia when considering web application support but Avalonia has more coverage of the WPF api with respect to what Uno does for WinUi. And for sure marketing is the worst part of Avalonia while it is the BEST for MAUI and Flutter.
BUT
That's now officially unsupported as all of Xamarin Forms is no longer supported and the MAUI replacement doesn't cover Linux nor does that look likely (MAUI is mired deep in problems due over-ambition, failure to resource and it seems a significant push in MS to use MAUI Hybrid aka web UIs within native apps).
Yes. There are multiple UI projects that build on the WinUI 3 components in the Win App SDK.
There's the first party MAUI which is an updated version of Xamarin Forms. The two best-known third-party implementations are AvaloniaUI and Uno. I prefer Uno, it has more cross-platform targets.
Which lets you run Blazor (web framework) like a desktop UI across all major desktop platforms. Microsoft has MAUI/Blazor as a thing, but only targets Mac and Windows ATM, so Photino bridges the gap for Linux.
Photino lets you use anything other than just .NET but has pretty decent .NET support.
(i hardly know what i'm talking about so somebody else may have a better idea, but i'm here now so)
mingw is a GNU's header/library environment (tools too maybe?) to create windows compatible applications. So I'd look into searching mingw .net and/or mingw mono.
also, ask your favorite AI, they're good at this type of question so long as it's not up to the minute news
I go in more detail in my other comment but I would imagine this is a definition most people can't get behind.
> intelligence can be reasonably defined as "knowledge and skills to be successful in life, i.e. have higher-than-average income"
I think it just crumbles under light scrutiny. People have higher income for all kinds of observable reasons that don't have to do with intelligence. I have higher income than other employees at the same level just based on where I live.
Intelligence is something that is defined by academics. Surprise surprise that it it measures how people perform in a narrow set of academic skills.
Right, but they are visibly are. Russ Vought (project 2025) is the Office of Management and Budget director. He drafted the executive orders months ago that would lead to exactly this. Part of Project 2025
Other members in Trumps cabinet from Project 2025:
- Tom Homan (Border Czar)
- Brendan Carr (FCC)
- John Ratcliffe (CIA Director)
> The rest of your post is just hysteria so I won't comment on that.
Maybe don't accuse others of hysteria while you spout that Democrats are the ones coordinating every independent attorney and judge to come after Trump.
> In every instance, he has said he is not affiliated with it and doesn't support it
You sound like you were born yesterday. If you can't imagine why a politician would say one thing and do the other, I really can't help you. You're maliciously ignorant.