4 ms·

Introduce a memory safe compilation mode inspired by Fil-C

84 points by mpweiher 3mo ago

kennykartman 3mo ago
Zig main dev proposes to introduce a Fil-C like compilation mode to make zig safe: it's only natural to mention how that's different from Rust, right? What about all the other languages, Andrew? I'm tired to see zig head people trying to diss Rust whenever they can. It's annoying for people that enjoy both languages and it's really a hint of how toxic the zig community is.
- alexrp 3mo ago
  This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does. I can't speak for Andrew, but I didn't read this as a "diss" at all.
  - kennykartman 3mo ago
    Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled. So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
    - isaacvando 3mo ago
      > So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative. Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee. Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.
      - kennykartman 3mo ago
        IIUC Fil-C does not allow to freely write safe assembly language as well, right? From the inlineasm page, they say > Parsing and analyzing the assembly. If it contains memory accesses, control flow, or anything we don't recognize, we reject it. ...But I'm no fil-c user nor expert so correct me if I'm wrong!
    - andrewflnr 3mo ago
      It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.
  - kennykartman 3mo ago
    By the way > Zig will become one of the only toolchains capable of producing actually memory safe executables there's a whole class of GC languages that can do that
    - audunw 3mo ago
      I think the point here is to include C library dependencies. Which GC languages in general consider outside the scope of its memory safety.
- audunw 3mo ago
  I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much. I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity? “I'm tired to see zig head people trying to diss Rust whenever they can.” I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software
  - kennykartman 3mo ago
    > I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity? You are right: I generalized way too much in my comment. I do not mean that all Zig communities are toxic, but at least the ones I read/participate into.
  - jamincan 3mo ago
    I'm pretty sure he posts about D on every language-related post; it's not just zig.
- andrewflnr 3mo ago
  They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.
  - binary132 3mo ago
    I think it has a lot more to do with the Bun situation.
  - pjmlp 3mo ago
    Not when one isn't against the use of managed languages in systems programming, like Swift, D, C# (AOT), Nim, OCaml or oldies that lost the language wars from the 90's, like Modula-3, Oberon, Component Pascal,...
    - andrewflnr 3mo ago
      Lots of people are against that, though. Clearly. I agree that it's silly sometimes (I dearly wish OCaml or something like it was mainstream), but the implicit definition of the category that rust, zig, etc are competing in is non-managed languages. The only point is that it's not weird for Zig to compare itself to Rust.
      - pjmlp 3mo ago
        Right, however Zig is late to the party, its approach to safety is like using Modula-2 or Object Pascal. Also, not only it is hard to see which big corp would make using Zig unavoidable, AI driven programming makes most languages irrelevant, it is a matter to ask what flavour should be output be. Which is like, why are we even arguing for manual memory management, when is the LLM doing the work.
- pjmlp 3mo ago
  I keep repeating the Modula-2/Object Pascal with curly brackets example. Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing. Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site, > Cyclone thus tries to fill an empty niche: the safe language with C’s level of control and efficiency. https://cyclone.thelanguage.org/wiki/Why%20Cyclone/ https://cyclone.thelanguage.org/wiki/Why%20Cyclone/ The UNIX and C creators, after C got standardised, kept experimenting with Alef, Limbo and finally ended up with Go. Alef failed because according to Rob Pike, "Problem: with C's memory model in a concurrent world, hard to know when to free items. All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming." http://go-lang.cat-v.org/talks/slides/emerging-languages-camp-2010.pdf http://go-lang.cat-v.org/talks/slides/emerging-languages-cam... Then we have Zig advocating for use-after-free solutions, that for all practical purposes have existed for decades, we already had Insure++, PurifyPlus, BoundsChecker in the 1990's. And now we get Fil-C, which in case they haven't been paying attention, uses a GC, go figure!
akagusu 3mo ago
This will be huge if accomplished.
chlorion 3mo ago
Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.
- audunw 3mo ago
  I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig) And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted. Serious comments seem to be kept, even when they’re sceptical.
- andrewflnr 3mo ago
  If you see a substantive comment you think might be deleted, screenshot it. But I do see debate in there.
  - chlorion 3mo ago
    directly from the thread: If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say Sadly I didn't get a chance to screenshot anything, but he's definitely not just deleting the toxic comments.
- audunw 3mo ago
  For posterity here are some comments I’m curious if will be deleted 1. > Id like a clarification on how this is safer than Rust? (Seems reasonable enough) 2. meme image with the words “bait” and “retarded” - should be deleted 3. > Funny how memory safety suddenly became a priority right after Bun moved to Rust. That feels like a pretty big departure from Zig's original philosophy. > Someone's still pretty butthurt about Jared and the Bun team. Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT
- 3mo ago
espetro 3mo ago
As a developer without deep know-how in low-level memory mgmt., what are the most promising (or actually working) approaches to safer memory mgmt. other than Rust's borrow checker? Is Rust's credited safe approach mainly due to the borrow checker approach or rather a mix with other language features?
afdbcreid 3mo ago
Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.
- iacuobos 3mo ago
  The idea of this is that you can import libraries from C/C++ and wrap them on the filC compilation mode, I could see some fuzzing usage on this too but I do agree it's not quite where I would like to see project effort going.
davemp 3mo ago
Without explicitly entering the language holy wars. I think there’s an interesting trade-off here. Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead. Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from bounds checking. Maybe zig could find a way to elide enough of the capability overhead that careful programming could get a <2x penalty vs C. Maybe explicit opt-in built in types or something. This would essentially be the reverse of unsafe blocks, but then there’s no escape hatch. Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. This would be great for compile times and places where open source is not tenable. Regardless, I’m very happy to see another independent school of thought approach memory safety. I’ll forgive Mr. Kelly any gruffness, these topics can be quite annoying to discuss in public.
- tstack 3mo ago
  You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug. > Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.
  - davemp 3mo ago
    Looks like Mr. Kelly agrees with you. From the zen of zig: - Runtime crashes are better than bugs. - Compile errors are better than runtime crashes. - Incremental improvements. - Avoid local maximums. Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here. Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.
slopinthebag 3mo ago
It’s kinda funny how butthurt they are about Rust, especially considering that most Rust users probably don’t think about Zig at all. I’m not sure what they gain by being so antagonistic about it…
deleted 3mo ago
[deleted]
deleted 3mo ago
[deleted]
musicale 3mo ago
How about something like clang's -fbounds-safety?
- aapoalas 3mo ago
  I believe Zig will always do bounds checks, except maybe in ReleaseFast mode?
dminik 3mo ago
I'm having a hard time squaring together two of the claims Andrew makes here: - No source changes - https://codeberg.org/ziglang/zig/issues/36237#issuecomment-19729631 https://codeberg.org/ziglang/zig/issues/36237#issuecomment-1... - No escape hatches - main post Surely there are already projects out there that rely on behaviours prohibited by Fil-C. One example that immediately comes to mind is reliance on external/C libraries. Overall, I think adding it as a build target/ABI to the main compiler is pretty neat, but I do agree that it seems quite against the spirit of Zig (no hidden allocations, no hidden control flow). Combined with the combative title, I wonder how much of this is just "if I give them this, they will shut up about Rust."
- pjmlp 3mo ago
  More like, we might shut up about use after free not being better than what C and C++ tooling has already provided for the last 30 years. Also, Fil-C also makes use of GC technology, which is kind of ironic.
casey2 3mo ago
Funny I was just having a conversation about this last week... with gemini. The obvious idea being that this places zig as the main build toolchain for most software on the planet.
z0ltan 3mo ago
[dead]
RustSupremacist 3mo ago
One of the banned individuals was indeed not serious: https://xcancel.com/Malix_Labs/status/2079172393105227839 https://xcancel.com/Malix_Labs/status/2079172393105227839 I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.

84 points by mpweiher 3mo ago

Zig main dev proposes to introduce a Fil-C like compilation mode to make zig safe: it's only natural to mention how that's different from Rust, right? What about all the other languages, Andrew? I'm tired to see zig head people trying to diss Rust whenever they can. It's annoying for people that enjoy both languages and it's really a hint of how toxic the zig community is.

alexrp 3mo ago
This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does. I can't speak for Andrew, but I didn't read this as a "diss" at all.
- kennykartman 3mo ago
  Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled. So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
  - isaacvando 3mo ago
    > So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative. Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee. Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.
    - kennykartman 3mo ago
      IIUC Fil-C does not allow to freely write safe assembly language as well, right? From the inlineasm page, they say > Parsing and analyzing the assembly. If it contains memory accesses, control flow, or anything we don't recognize, we reject it. ...But I'm no fil-c user nor expert so correct me if I'm wrong!
  - andrewflnr 3mo ago
    It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.
- kennykartman 3mo ago
  By the way > Zig will become one of the only toolchains capable of producing actually memory safe executables there's a whole class of GC languages that can do that
  - audunw 3mo ago
    I think the point here is to include C library dependencies. Which GC languages in general consider outside the scope of its memory safety.
audunw 3mo ago
I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much. I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity? “I'm tired to see zig head people trying to diss Rust whenever they can.” I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software
- kennykartman 3mo ago
  > I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity? You are right: I generalized way too much in my comment. I do not mean that all Zig communities are toxic, but at least the ones I read/participate into.
- jamincan 3mo ago
  I'm pretty sure he posts about D on every language-related post; it's not just zig.
andrewflnr 3mo ago
They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.
- binary132 3mo ago
  I think it has a lot more to do with the Bun situation.
- pjmlp 3mo ago
  Not when one isn't against the use of managed languages in systems programming, like Swift, D, C# (AOT), Nim, OCaml or oldies that lost the language wars from the 90's, like Modula-3, Oberon, Component Pascal,...
  - andrewflnr 3mo ago
    Lots of people are against that, though. Clearly. I agree that it's silly sometimes (I dearly wish OCaml or something like it was mainstream), but the implicit definition of the category that rust, zig, etc are competing in is non-managed languages. The only point is that it's not weird for Zig to compare itself to Rust.
    - pjmlp 3mo ago
      Right, however Zig is late to the party, its approach to safety is like using Modula-2 or Object Pascal. Also, not only it is hard to see which big corp would make using Zig unavoidable, AI driven programming makes most languages irrelevant, it is a matter to ask what flavour should be output be. Which is like, why are we even arguing for manual memory management, when is the LLM doing the work.
pjmlp 3mo ago
I keep repeating the Modula-2/Object Pascal with curly brackets example. Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing. Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site, > Cyclone thus tries to fill an empty niche: the safe language with C’s level of control and efficiency. https://cyclone.thelanguage.org/wiki/Why%20Cyclone/ https://cyclone.thelanguage.org/wiki/Why%20Cyclone/ The UNIX and C creators, after C got standardised, kept experimenting with Alef, Limbo and finally ended up with Go. Alef failed because according to Rob Pike, "Problem: with C's memory model in a concurrent world, hard to know when to free items. All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming." http://go-lang.cat-v.org/talks/slides/emerging-languages-camp-2010.pdf http://go-lang.cat-v.org/talks/slides/emerging-languages-cam... Then we have Zig advocating for use-after-free solutions, that for all practical purposes have existed for decades, we already had Insure++, PurifyPlus, BoundsChecker in the 1990's. And now we get Fil-C, which in case they haven't been paying attention, uses a GC, go figure!

akagusu 3mo ago

This will be huge if accomplished.

chlorion 3mo ago

Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.

audunw 3mo ago
I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig) And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted. Serious comments seem to be kept, even when they’re sceptical.
andrewflnr 3mo ago
If you see a substantive comment you think might be deleted, screenshot it. But I do see debate in there.
- chlorion 3mo ago
  directly from the thread: If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say Sadly I didn't get a chance to screenshot anything, but he's definitely not just deleting the toxic comments.
audunw 3mo ago
For posterity here are some comments I’m curious if will be deleted 1. > Id like a clarification on how this is safer than Rust? (Seems reasonable enough) 2. meme image with the words “bait” and “retarded” - should be deleted 3. > Funny how memory safety suddenly became a priority right after Bun moved to Rust. That feels like a pretty big departure from Zig's original philosophy. > Someone's still pretty butthurt about Jared and the Bun team. Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT
3mo ago

espetro 3mo ago

As a developer without deep know-how in low-level memory mgmt., what are the most promising (or actually working) approaches to safer memory mgmt. other than Rust's borrow checker? Is Rust's credited safe approach mainly due to the borrow checker approach or rather a mix with other language features?

afdbcreid 3mo ago

Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.

iacuobos 3mo ago
The idea of this is that you can import libraries from C/C++ and wrap them on the filC compilation mode, I could see some fuzzing usage on this too but I do agree it's not quite where I would like to see project effort going.

davemp 3mo ago

Without explicitly entering the language holy wars. I think there’s an interesting trade-off here. Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead. Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from bounds checking. Maybe zig could find a way to elide enough of the capability overhead that careful programming could get a <2x penalty vs C. Maybe explicit opt-in built in types or something. This would essentially be the reverse of unsafe blocks, but then there’s no escape hatch. Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. This would be great for compile times and places where open source is not tenable. Regardless, I’m very happy to see another independent school of thought approach memory safety. I’ll forgive Mr. Kelly any gruffness, these topics can be quite annoying to discuss in public.

tstack 3mo ago
You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug. > Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.
- davemp 3mo ago
  Looks like Mr. Kelly agrees with you. From the zen of zig: - Runtime crashes are better than bugs. - Compile errors are better than runtime crashes. - Incremental improvements. - Avoid local maximums. Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here. Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.

slopinthebag 3mo ago

It’s kinda funny how butthurt they are about Rust, especially considering that most Rust users probably don’t think about Zig at all. I’m not sure what they gain by being so antagonistic about it…

deleted 3mo ago

[deleted]

deleted 3mo ago

[deleted]

musicale 3mo ago

How about something like clang's -fbounds-safety?

aapoalas 3mo ago
I believe Zig will always do bounds checks, except maybe in ReleaseFast mode?

dminik 3mo ago

I'm having a hard time squaring together two of the claims Andrew makes here: - No source changes - https://codeberg.org/ziglang/zig/issues/36237#issuecomment-19729631 https://codeberg.org/ziglang/zig/issues/36237#issuecomment-1... - No escape hatches - main post Surely there are already projects out there that rely on behaviours prohibited by Fil-C. One example that immediately comes to mind is reliance on external/C libraries. Overall, I think adding it as a build target/ABI to the main compiler is pretty neat, but I do agree that it seems quite against the spirit of Zig (no hidden allocations, no hidden control flow). Combined with the combative title, I wonder how much of this is just "if I give them this, they will shut up about Rust."

pjmlp 3mo ago
More like, we might shut up about use after free not being better than what C and C++ tooling has already provided for the last 30 years. Also, Fil-C also makes use of GC technology, which is kind of ironic.

casey2 3mo ago

Funny I was just having a conversation about this last week... with gemini. The obvious idea being that this places zig as the main build toolchain for most software on the planet.

z0ltan 3mo ago

[dead]

RustSupremacist 3mo ago

One of the banned individuals was indeed not serious: https://xcancel.com/Malix_Labs/status/2079172393105227839 https://xcancel.com/Malix_Labs/status/2079172393105227839 I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.