

You know, as a full-time Linux user, I think I rather have game developers continue to create Windows executables.
Unlike most software, games have a tendency to be released, then supported for one or two years, and then abandoned. But meanwhile, operating systems and libraries move on.
If you have a native Linux build of a game from 10 years ago, good luck trying to run it on your modern system. With Windows builds, using Wine or Proton, you actually have better chances running games from 10 or even 20 years ago.
Meanwhile, thanks to Valve’s efforts, Windows builds have incentive to target Vulkan, they’re getting tested on Linux. That’s what we should focus on IMO, because those things make games better supported on Linux. Which platform the binary is compiled for is an implementation detail… and Win32 is actually the more stable target.
tsc
is (very) slow and there are also no convenient ways to interact with it from Rust.
So it saves a lot development and CI time to roll our own. The downside is that our inference still isn’t as good as tsc
of course, but we’re hopeful the community can help us get very close at least.
Biome v2 launched: First type-aware linter that doesn't require tsc
cross-posted from: https://programming.dev/post/32376875
Biome is a formatter and linter for web languages: JavaScript, TypeScript, CSS, HTML, JSON, and GraphQL.
Version 2 adds type-aware lint rules and it is the first TypeScript linter that does not require
tsc
. Other new features include:
- Monorepo support
- GritQL Plugins
- Revamped, configurable import sorting
- Linter domains
- Bulk suppressions
- Analyzer assists
- Many new lint rules
Biome v2 launched: First type-aware linter that doesn't require tsc
cross-posted from: https://programming.dev/post/32376875
Biome is a formatter and linter for web languages: JavaScript, TypeScript, CSS, HTML, JSON, and GraphQL.
Version 2 adds type-aware lint rules and it is the first TypeScript linter that does not require
tsc
. Other new features include:
- Monorepo support
- GritQL Plugins
- Revamped, configurable import sorting
- Linter domains
- Bulk suppressions
- Analyzer assists
- Many new lint rules
Biome v2 launched: First type-aware linter that doesn't require tsc
Biome is a formatter and linter for web languages: JavaScript, TypeScript, CSS, HTML, JSON, and GraphQL.
Version 2 adds type-aware lint rules and it is the first TypeScript linter that does not require tsc
. Other new features include:
I see this argument repeated here every now and then, but it’s not true: https://aoav.org.uk/2020/the-effects-of-strategic-bombing-in-wwii-on-german-morale/
To summarise: Bombing had a profound effect on depressing morale through inducing defeatism, fear and apathy. Bombing did not harden popular resolve against the US. The hate and anger it aroused was directed against the Nazi regime, not the Allies.
Heh, I agree with everything you said, but I’m afraid such a framework is impossible to create, let alone implement. It’s impossible to foresee the infinite possibilities for people to screw themselves through bad decisions, so all you’d create is a lot of bureaucracy to still end up in the same place.
That’s still a very major achievement! Do I understand correctly this means all target architectures supported by GCC are now unlocked for Rust too?
It’s that the compiler doesn’t help you with preventing race conditions. This makes some problems so hard to solve in C that C programmers simply stay away from attempting it, because they fear the complexity involved.
It’s a variation of the same theme: Maybe a C programmer could do it too, given infinite time and skill. But in practice it’s often not feasible.
Which one should I pick then, that is both as fast as the std solutions in the other languages and as reusable for arbitrary use cases?
Because it sounds like your initial pick made you loose the machine efficiency argument and you can’t have it both ways.
I’m not saying you can’t, but it’s a lot more work to use such solutions, to say nothing about their quality compared to std solutions in other languages.
And it’s also just one example. If we bring multi-threading into it, we’re opening another can of worms where C doesn’t particularly shine.
Well, let’s be real: many C programs don’t want to rely on Glib, and licensing (as the other reply mentioned) is only one reason. Glib is not exactly known for high performance, and is significantly slower than the alternatives supported by the other languages I mentioned.
I would argue that because C is so hard to program in, even the claim to machine efficiency is arguable. Yes, if you have infinite time for implementation, then C is among the most efficient, but then the same applies to C++, Rust and Zig too, because with infinite time any artificial hurdle can be cleared by the programmer.
In practice however, programmers have limited time. That means they need to use the tools of the language to save themselves time. Languages with higher levels of abstraction make it easier, not harder, to reach high performance, assuming the abstractions don’t provide too much overhead. C++, Rust and Zig all apply in this domain.
An example is the situation where you need a hash map or B-Tree map to implement efficient lookups. The languages with higher abstraction give you reusable, high performance options. The C programmer will need to either roll his own, which may not be an option if time Is limited, or choose a lower-performance alternative.
Of course, but it needn’t be black and white. You can also diversify, make yourself less reliant on a single platform. And by doing so, enable your audience to follow you elsewhere. Or diversify into different activities altogether. And when it’s no longer half your income on the line, then switch.
But doing nothing and saying, “but half my income!”? That’s not only a choice, but also complacency.
Great points, except:
People can’t leave for anything smaller.
They can and some do. It’s still a choice.
Ah yes, then we are in agreement. I thought we were talking about unintentionally arriving at the same implementation after looking at the original, which is where the discussion started.
Because coming up with the same implementation independently is legal, while copying someone else’s implementation isn’t. Which method you used to arrive at your implementation can be difficult to prove either way, which is why it’s important for implementors to be able to say they never looked at the original. It’s a legal defence, in case you ever need to stand in front of a judge or jury who will question how you arrived at yours.
Maybe not the best example then, but not the only example. If you unintentionally create something that resembles the original too much you may still become liable. It’s hard to draw the line, which is why many in such a position would prefer to be safe rather than sorry.
It’s a gray area, legally. What you say is theoretically correct, but there’s practical issues once you’ve looked at the code that will open you up to legal liability anyway.
For instance, what if you need a utility function during your reimplementation for which there is really only one obvious implementation? You can no longer claim to have come up with it by yourself.
I doubt the FSF would sue over it, but companies are known to avoid the risk.
An in-depth exploration of the architecture powering Biome's type inference.
Biome is an integrated linter/formatter for JavaScript/TypeScript, CSS, HTML and GraphQL.
We are now in the process of implementing TypeScript-like inference (not full type checking!) that allows us to enable type-informed lint rules. This is similar to typescript-eslint
except instead of using tsc
we attempt to implement the inference ourselves.
This post describes our progress thus far, with a detailed overview of our type architecture.
Biome is a formatter and linter for JavaScript, TypeScript and other web languages.
With this partnership, we aim to develop TypeScript-compatible type inference that works out of the box for use in our lint rules.
Haha, sure thing!
So, today, TurboPascal isn’t a very popular programming language anymore. But that’s okay! We have new programming languages nowadays. Some of the popular languages that we use today include JavaScript, TypeScript and CSS. You don’t need to know much about these languages, except that they’re commonly used for creating websites and apps that run on the web.
Now, assume you want to create a website or a webapp, and you were to learn these languages for that purpose. In that case you have quite a learning experience ahead of you, which is great! Learning can be fun! But what’s not so great is that these languages have lots of room to make mistakes. Now, everyone makes mistakes, that’s just a fact of life, but when mistakes can be avoided, that’s generally preferred.
This is where Biome comes in: It is a tool – we call it a linter – that helps you to detect many kinds of common mistakes. It can show you where these mistakes are, and sometimes even fix them for you. It can also show you possible mistakes, things that are not necessarily a mistake, but things that look suspicious.
And on top of that, Biome offers you another tool: It’s called a formatter. When you write your code, it automatically takes care for you that the code looks consistent. So it fixes things like indentation and other use of whitespace for you, as well as where to place your parentheses and stuff like that.
Together, hopefully these two things can make your programming experience a little bit more enjoyable. Cheers!
They’re included in the beta!
Specifically, you can create GritQL plugins for custom linter diagnostics. There’s certainly more we’d like to do on that front, but we’re first going to see how these are being received to decide where to prioritise next.
I don’t have Nix experience myself, but what would it take to be better supported there? I think we’d be open to PRs for that ☺️
We don’t currently publish to Crates.io, but we do have CI integrations that can install without needing NPM.
Biome lead here, so feel free to ask anything!
Biome is an integrated linter and formatter with support for JavaScript, TypeScript, CSS, and more.
Highlights of the release:
noFloatingPromises
: Still a proof-of-concept, but our first type-aware lint rule is making an appearance. // biome-ignore-all
, or suppress a range using // biome-ignore-start
and ` New Monarchy is based on a union of districts, each governed by a monarchy. Monarchies are constrained by a constitution to guarantee citizen rights, including the right to depose unjust or unfit rulers, while districts are sworn to protect each other's constitution.
Recent events in #politics triggered me to write a manifesto on the values of #Democracy and what we can to do preserve them.
New Monarchy is based on a union of districts, each governed by a monarchy. Monarchies are constrained by a constitution to guarantee citizen rights, including the right to depose unjust or unfit rulers, while districts are sworn to protect each other's constitution.
Recent events in #politics triggered me to write a manifesto on the values of #Democracy and what we can to do preserve them.
Biome project lead here, so feel free to ask questions!
If you're developing an application and find yourself running a benchmark whose results are measured in nanoseconds... you should probably stop and get back ...
Various ways of using singletons in JavaScript, with their pros and cons
This is the government's strongest stance yet on software security, which puts manufacturers on notice: fix dangerous coding practices or risk being labeled as negligent.
DirectX Adopting SPIR-V
Today the Direct3D and HLSL teams are excited to share some insight into the next big step for GPU programmability. Once Shader Model 7 is released, DirectX 12 will accept shaders compiled to SPIR-V™. The HLSL team is committed to open development processes and collaborating with The Khronos® Group ...
SPIR-V is the intermediate shader target used by Vulkan as well, so it sounds like this may indirectly make DirectX on Linux smoother.
First anniversary of Biome and release of Biome 1.9 that enables CSS and GraphQL formatting and linting by default, a new search command
Biome v1.9 is out!
Today we celebrate both the first anniversary of Biome 🎊 and the release of Biome v1.9! Read our blog post for a look back at the first year and the new features of Biome v1.9.
In a nutshell:
.editorconfig
support. Opt-in biome search
command to search for patterns in your source code. Async Rust is powerful. And it can be a pain to work with (and learn). Async Rust can be a pleasure to work with, though, if we can do it without `Send + Sync + 'static`.
Practical tips that allow you to build an evolving architecture
With this post I've taken a bit more of a practical turn compared to previous Post-Architecture posts: It's more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
On the implications of defining the architecture after you build the product -- part II
After my previous post introducing Post-Architecture, I received a bunch of positive feedback, as well as enquiries from people wanting to know more. So I figured a follow-up was in order. Feel free to ask questions here as well as on Mastodon!
On the implications of defining the architecture after you build the product
This post highlights my experience working with software architecture in startup environments. I think the approach is different enough from the traditional notion of software architecture that it may warrant its own term: post-architecture.