What kind of question is this? He is working on a JavaScript/TypeScript runtime not building a communication product. Why would you run to him to solve your pet grievance with Discord?
I imagine the complaint is around Bun's use of Discord as community coordination tooling -- linked in the site's header. The post isn't implying Bun should be involved in the creation of an alternative.
(I'm not here to throw shade at using Discord for OSS "communities" - I do as well - And am concerned about the path forward. Just want to clarify the question's intent.)
If open source, free software is a good enough ethos for your code base, it should be good enough for your community communications. Supporting only a proprietary locks out a swath of users & Discord in particular is an information blackhole—and now with ads!
Users that need special clients (accessibility, hardware, etc.). Users blocked by US sanctions. Users that have been moderated off the platform for something not in your community (account bans even happen accidentally). Users with privacy/anonymity concerns about the data collection (& now ads)—especially the chat rooms that require a SIM card. Users that take their FOSS or otherwise ethical software views or anti-corporate views to heart & want something built on those principle—from wanting to use free software to make free software, to wanting to outright avoid what some now call enshitification where a free (gratis) account clashes with the idea of freedoms, etc.
I think they used the word "support" to mean "use", rather than "build". That is - they weren't asking Bun developers to _build_ an alternative to Discord, but rather to stop _using_ Discord.
My comment is about the conditions that made TFA possible.
The business model explained in the article (do compute-intensive stuff and give it away for free) largely worked for Google, Facebook, and the big platform companies. Stability tried to do the same thing - building amazing tech as a loss leader - without a moat that gets people paying.
Combine that with a supplier that has huge market power (Nvidia) and you have a recipe for an entirely predictable bankruptcy.
It's an interesting question to ask what Midjourney and OpenAI/Anthropic have that Stability and Google doesn't have. The best answer I can give is "good taste" - specifically the ability to take relatively standard model components/architectures and tune the hell out of them so that a lot of people will enjoy using the end product.
Having good taste is a hell of a moat, which is how fashion designers build multi-billion-dollar brands (I am not talking about the old "houses" - those are about the logo, but new brands are different), as well as chefs and visual artists. It's just a very different kind of moat than the one we expect as engineers.
Midjourney's initial success was a combination of elusive marketing and a unique style. They focused on building a large community and took advantage of constant feedback.
> (I am not talking about the old "houses" - those are about the logo, but new brands are different)
Have you looked at Hermès' business model? It has never been about their logo. They'll often hide it from their product.
I agree with you about Hermes and actually the majority of the lines by most of the houses (not the cheap lines), but when you talk about fashion here, a lot of people think about the branding-focused groups like Gucci, Tiffany, or Louis Vuitton.
> a commercially developed language in that its developers are clearly incentivized to add more features.
Do you have any evidence this is true? Most programming languages are developed either by a company (C#, Java, Swift, Go) or heavily influenced by many companies (Python, JavaScript, C++). Java had been criticized forever (until very recently) for it's slow pace of development and it was 100% controlled by either Sun or Oracle.
Comments like these show just how little developers investigate the reasons why features they personally dislike were introduced to a language.
As a professional Java developer its new feature pace is still slow. It’s a little better but it hasn’t been fast in a VERY long time.
But that’s OK. They do an amazing job of maintaining backwards compatibility and making things fit in the language well as well as trying to get it right the first time.
Some languages are more willing to remove things that don’t work. Others are willing to have multiple different attempts that all work completely differently every few years.
In many ways that’s just not Java’s style. And that’s OK.
F# is not mainstream lang - it’s more like Clojure for .NET. My point was - you don’t have that variety in .NET as in JVM (Scala, Kotlin, Groovy are all relatively mainstream)
Kotlin is only mainstream on Android because Google says so, Groovy is barely kept alive thanks Gradle, and if it wasn't for Kafka and Spark, Scala would have been long gone.
Don’t get me wrong F# seems like a nice lang but definitely not mainstream (non geeks don’t use purely functional langs).
You can’t deny Kotlin is bigger lang than F# by any ranking from those popular (Tiobe) to unknown ones and is build on top of much bigger ecosystem (JVM) - that’s IMHO much more important factor for anyone doing commercial projects.
Additionally there is a big incentive to use it over Java (if you are stuck with older JDK) contrary to using F# over C#
Kotlin as a lang is better than C# (which is normal - it’s newer) and has better default IDE (IntelliJ) than anything on the market.
Well a bit exaggerated. Seen two Fortune 500 companies moving all never stuff to Kotlin on backend on my own eyes (for the reason I mentioned above) in some branches.
nobody is kneecapping anyone. The ask is to change CUDA into a standard for which nvidia is one implementation.
instead, what you have today is this:
> You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to target a non-NVIDIA platform.
The motivation seems to be "many people have transpilers configured wrong" and this seems an extreme solution to fixing people's transpiler configurations. Especially because it will still fail for modules using top-level await (anywhere in their dependency graph), so it is at best a band-aid. Beyond that it does seem to be missing real motivating use cases. What real reason in 2024 is there to use CommonJS at the top level in NPM? How hard is it to rewrite `require()` statements to `await import()` ones, especially when the fix is a transpiler configuration change away?
I don't know how much experience you have, but in the JS world there are band-aids everywhere. They "fix" a lot of real-world problems, help push things to production, and are more important than you think.
1. I don't agree this is useless. You may very likely never need to use it, but not for others.
2. Until every single JavaScript file in the world is in the ESM format, anything that happens before that will be a band aid of some sort.
> but in the JS world there are band-aids everywhere
I apologize, "band-aid" was the wrong word to use for this specific case, because that unintentionally disparages "band-aids". You are right there are "band-aids" that fix real-world problems, and help heal accidental wounds. This experiment does neither and seems to me worse than a "band-aid". It's a fragile broken and fake bridge that looks like it can get you to your destination but will collapse right under you if you try to use it (rather than switching to what already works today).
Sorry to disappoint you, half of the things in the JS world are half baked, broken, and are fake bridges. That's why I need to mention experience -- it is hard to explain all of this within a few sentences if you don't already have the context of what I am trying to say.
It's so that CommonJS modules can use ESM modules.
---
Like suppose examplelib uses otherlib, both in CommonJS.
The examplelib wants to upgrade otherlib, but the new version uses ESM. Now, examplelib is stuck either on the old version, or has to undertake a rewrite (and propagate this situation downstream). Or adopt a transpiler and force downstream users to do the same.
Some would say "just rewrite in ESM" and that is a nice idea, but there are lots of tools with caveats, TypeScript, Jest, anything that depends on require-in-the-middle, etc.
It's hard to boil the ocean. (Just look at Python 3.)
CommonJS modules (and anybody else that prefers or needs "require-in-the-middle") can already import ESM. They need to use `await import()` or `import().then()` if they prefer callback waterfalls to async/await syntax. That works everywhere in Node today. Sure, it's a pain when upstream switches to ESM that you have to use more Promises, but that the price you pay and it is certainly a lot less work than a full rewrite even for the most brownfield CommonJS library. You don't have to rewrite everything to ESM all at once. (You should want to, but don't have to.)
If your upstream has switched to ESM and expects to do async things, then yes, everywhere you depend on that upstream you need to consider those imports async. Yes, it's contagious, but your upstream already caught that contagion. Trying to keep smashing it into a synchronous box seems like a recipe for unexpected bugs. Especially in the case of this experiment where the difference between "works" and "gives the same error it already gives today" is a one keyword change anywhere in the upstream file. That sounds brittle to me and less useful than "everything needs to become async".
What does the market cap of the company or the founders net worth have anything to do with the unit economics of operating a streaming business? Netflix, Hulu and others are all exploring charging more or introducing ads. Does that not factor into your analysis at all??
If the company is already huge and makes a tonne of profit, there's little/no need to double-dip on an accessory service that already makes a good case for pushing people into their main service (i.e prime video is free if you use amazon prime -> using amazon's main website/service).
It's not about the market cap specifically, it's stating that prime video doesn't need to operate at a profit in order to benefit amazon's core business.
> What does the market cap of the company or the founders net worth have anything to do with the unit economics of operating a streaming business?
For being a sub-product when compared to other streaming platforms, I, the naive me, would expect that Prime wouldn’t be in such a rush to milk money from users and instead they would focus on making the best product they can given that their mother company is wealthy as fuck.
Not that I even agree, but I guess the point is that someone so highly paid should be able to find solutions that don't at least feel unfair. I mean most people pay for cable and there's not even a way to not have ads and they increase prices regularly - then again most people do hate the cable companies.
"You'd think we had enough of those already, but no.". The market determines when "we have had enough" not some arbitrary limit imposed by a current resident.
It's hardly a free market - it would certainly be more profitable to build a midrise with 20+ less expensive units rather than one expensive unit on a given lot - but zoning restrictions mean it can't happen.
Generally any neighborhood meeting will also have people providing input that more units will cause more traffic so could the developer please create fewer, more expensive units?
What market? Developers are tripping over themselves to build housing in Cambridge/Somerville.
But zoning gets in the way all the time. For example, Somerville was going to get a new development in Davis Square. And the developer jumped through all the hoops. The city literally changed the zoning map so that they could only build labs and no housing.
Then there is no shortage of the housing. Local people are satisfied with zoning and current state. Prices are going up, everyone who has some ownership have profit.
New people, who wants to move to the city - they are screwed.
So to be fair in some areas, the majority of voters are renters. BUT most of these don't vote (they do whine). The rest vote. Of those who vote, plenty are NIMBY - they have theirs and they don't want any change to their neighborhood. So that yeah, we are screwed (except that the voters actually ARE getting what they want. Just that what they want is messed up.)
A lot of people I know can't afford a data plan for their phones, so when RCS becomes enabled it just bounces all their incoming/outgoing messages and it is sometimes days or weeks before they realize.
And even for those who can afford a data plan for their phones, they might have gone over their data allowance for the current month, so the data won't work until it refreshes at the start of the next monthly cycle. And obviously, having one more thing using data makes it even easier to go over the limit.
For me, SMS is solely for receiving 2FA codes and sending message to my provider to check how much data allowance I have left for the month. I use Whatsapp for messages to people.
Companies have already begun using RCS as an opportunity to flood my phone with ads that take up way too much space in the notification shade. Also not from the US, so I can just use a 3rd party app
I agree. GitHub is the biggest player, but it's a pretty layer on top of an inherently distributed system. If I get tired of Microsoft's shenanigans, I can pack up move to a competitor with only the normal amount of friction (like moving bug reports over, etc.). I use Gitea for my personal projects and it handles 95% of the code-hosting bits just as well.
I'm not so relaxed about how easy it will be to move to a new issue tracker.
When you're moving from a self-hosted system to a proprietary system, you can do the work yourself to make sure there are redirects from the old URLs to the new ones.
That option isn't likely to be available when you're moving the other way.
I observe that github is happy for you to "bring your own domain" for github pages, but AIUI issue and PR URLs are always under github.com .
Maintaining links is going to be a pain in the neck, sure. I don't mean to make light of it. However, that's kind of inherent with going from one service to another, and not something GitHub's doing to make it artificially harder.
