Make sure crab, crablang, crusty, crabby, or whatever we decided to call our tools and terminology are licensed as openly as possible. We want to make sure nobody takes them away from us.

Please consider enabling discussions here, for people who do not like Discord for a variety… of reasons

Rename cargo to crusty. Now we have crusty building the crab language. May or may not be inspired by some yellow square with the last name Robert or something 🟨 :)

Update 1

Ok so there are 2 current popular proposals:

Spongebob Theme:

cargo -> crusty or krusty
rust -> crab
rustc -> crabc
rustfmt -> crabfmt
clippy -> fiddler
crate -> patty

Crab Theme:

cargo -> crabgo
rust -> crab
rustc -> crabc
rustfmt -> crabfmt
clippy -> crabby
crate -> barrel, cage, idk. I haven't seen any crab[some term here] for this one yet.

I know I proposed the Spongebob theme, but I'm actually leaning towards the crab theme for simplicity and easy to remember commands / tools.

BUT

I propose that if we go with the crab theme, we include an easter egg:

crabgo sponge

It will alias all tools / commands to sponge bob related things :)

I'll keep updating this as we make progress with the discussion around the issue :). If anyone has any ideas for a crate -> crab[something] post below! :)

Rather than being escapist and just avoid problems by forking Rust (which itself brings a ton of problems), we better wait for the trademark policy draft to be improved. We have all the power to decide what the policy will eventually be, and we all can participate in this by suggesting improvements. Yes, the first draft is stupid and even disrespectful to all people who put a lot of effort in Rust programming language, but there's no point in panicking and straight away rolling out a whole separate project.

It's all fun, ha-ha, we have our own programming language, look Rust Foundation, we can live without you, we have power, ha-ha, but it's not rational. Early panicking will lead to nothing but more conflicts and polarization in our community. I love Rust community and would not like to see this happen.

Not a lawyer but I think the mascot might be too similar that monster energy grade lawyer might try to sue. so maybe modify it a lot?

any public-facing files should have rust renamed to crab. this would include most of the markdown files in all repos, but we can start with crablang/crab.

Here, a sublanguage that implements breaking changes to crab is being discussed. I decided to create a list of the things I would like to see in such a sublanguage:

• A C-style entry point. I would like to see main() provide argv, and
• a simpler io::Error; this could be implemented by allowing main() to return a std::io::Result<(), String> or something else.
• A stable ABI
• LGPL-3.0-or-later-licensed standard/core library, AGPL-3.0-or-later-licensed compiler toolchain. *
• Proper source file license and copyright notices **

* The LGPL would preserve the freedom of the library without implicitly licensing anything linked against it as copyleft, therefore allowing crab to be used in permissively-licensed projects as well as nonfree ones. Changes to the library itself would be copylefted, though. The AGPL would specifically apply in any case where the compiler is used over a network, requiring any forks of crab to provide ways to access its source code. Otherwise, it’s the same as the GPL.

** License notices are an important part of software licensing that goes mostly ignored by even the likes of the upstream project, and they don’t just apply for the GPL family of licenses.

Please add anything more here that you’d like to see in crab :)

the current approach to renaming is based on a clever shell script that does text replacement on output of existing commands in the rust toolchain. it's fine for a proof of concept, but ideally we would want more control over exactly what is being renamed and host our own binaries.

this would involve changing the names of relevant commands, then building for multiple targets and hosting the files and using that url in the install script. we'd then need to make a script or program that automates that process.

we can start with the compiler. bear in mind we don't need (or want) to rename every instance of rust to crab, we just want the command, its documentation, and its output to be changed.

Currently, the share feature is pointing out to http://example.com.

Will coroutines with stacks be supported?Virtual thread or Green thread

We can add some functionality to something shouldn't exist in rust, such as a way to disable orphan rule or something

this would allow distro maintainers to avoid every crab program containing its own version of tokio it would also allow one to install crab libraries normally as system packages, enable actual dynamic plugin support that won't break if you breathe on it wrong and make life easier for people trying to write pure crab oses. but most importantly, it would allow me to win arguments with C(++) users on discord, making using crabs the obvious choice when i want to oxi-DO.

Summary

Now that there's a fork getting enough traction, I'd like to propose our best competitive advantage: The Ternary Operator. It'll make my code look nice and run faster I think

Motivation

Please. Listen to me, okay. It's all I've wanted since like 2015. It can't be that hard, I've made my own language before and it had a ternary operator. Just figure it out idk

Guide-level explanation

1. Get in the code
2. Make the ternary operator
3. Ship it

Reference-level explanation

It would look like this

let b = true;
let i = b ? "Yes" : "No";
assert_eq!(i, "Yes");

Drawbacks

None

Rationale and Alternatives

Rationale:

• Because it would look cool
• Because I want it
• Do it now

Alternatives:

• Failure

Unresolved Questions

• Why hasn't this been in the language for the past 8 years

Future possibilities

• Rule the world

As a computer science major student who is quite new to dev world, I wonder if such things are allowed.

Idk also that would avoid the .cl file extension which is already taken by common lisp.

I see a number of references to fungi in the repository just by looking at a single subdirectory:

https://github.com/crablang/crab/tree/master/compiler

I suggest replacing them with the word crab.

The issues in this crab repository has sole focus intended for forking the compiler as crabc and it's immediate consequences.

Please use the correct places in order to maximise collective energy and effort by direcing it to right places.

• Crab Analyzer - https://github.com/crablang/crab-analyzer
• Crab Book - https://github.com/crablang/book
• Crab Compiler - https://github.com/crablang/crab
• Crab fmt - https://github.com/crablang/crabfmt
• Crab linter Pinchy - https://github.com/crablang/pinchy
• Crabgo Package Manager - https://github.com/crablang/crabgo
• Crab Up - https://github.com/crablang/crabup
• CrabLang Site - https://github.com/crablang/crablang-site
• Ideas - TBD New effort to direct and iterate community driven ideas

Since CrabLang is a community driven effort and anyone is free to use the name collectively - this means instead of asking some central authority to do the work, we expect people to take initiatives themselves autonomously without asking permission from anyone to create a new piece of the puzzle that is required to complete it or replace it's individual pieces.

If you have a project that can be referred / linked to, please let us know in Discussions so we can include the project/s here - we are trying to make ourselves redundant in the long run but this requires focus to do that and organise properly.

For any ideas outside immediate priorities - please use Discussions e.g. ideas.

This is to keep the focus & development running smoothly with the team of volunteers we have and limited energy.

I've seen no recent issues or PRs and nothing on social media.

Is crab lang a dead project? Should it be archived?

I would like to add a GitHub Actions workflow which checks for differences in the repo that's named after a fungus and automatically creates a new branch with a pull request which then can be further edited and or merged.

This workflow would be executed daily based on a Cron job schedule.

I already have something similar in place in my GitHubBoilerplate Repo.

I might edit this later and add all the relevant links and examples because I'm on mobile right now and formatting and looking for all the links is hard to do that way.

Please let me know what you guys think.
I wanted to create an issue first and wait for feedback before I put in all the effort and open a pull request.

I'm the last one to not find it funny but I think maybe something like a water gun or an eyepatch would be less "knife in logo" 🦀

👍👍

We need to set up a functional toolchain with the renamed tools. This will help ease the transition and is the fastest way to get people using Crab. We need to figure out the best way to go about this, what repos we need to fork, etc…

just need to create the experimental branch

it will start from the current state of our master branch, which is currently synced with upstream project but afterwards will not receive updates unless they can be incorporated without too many conflicts.

I very much like @nonetrix 's proposal over here for the .crab file extension: #18 (comment)

Why?

1. It allows users to show their support for CrabLang on their GitHub repos!
   

2. Its cool 🦀😎

How?

I think we can make this work and still be compatible with r*st. We would just need a crabgo command to do the conversion. Probably something like:

crabgo crabify: .rs -> .crab
crabgo rsify: .crab -> .rs

For extra credit we can add a command to configure git with pre-commit and other .gitattributes that properly convert and / or compare .rs and .crab making for a frictionless developer experience. Something like:

crabgo gitify

Edit: typo

Edit: New proposed Commands per discord discussion here: https://discord.com/channels/1074804478651400303/1095989994033782814/1096842935049404447

crabgo convert rs-to-crab: .rs -> .crab
crabgo convert crab-to-rs: .crab -> .rs

With the following shorthands:

crabgo convert crab = crabgo convert rs-to-crab
crabgo convert rs = crabgo convert crab-to-rs

Edit:

Some common questions have been:

Will we still support .rs?

Answer: Yes

I intend for the tool to make developing with both .rs and .crab a frictionless experience. Meaning it will allow libraries written in both .crab and .rs to work together.

Will this be in main / master?

No. It will either be in an experimental branch or as a subcommand in a new repository. I personally think the subcommand in a new repository is the best way to start. Here's some documentation to reference until we get the crabgo docs up: https://doc.rust-lang.org/book/ch14-05-extending-cargo.html

Edit: My new favorite proposal is from @mrquantumoff here

What about making something like

crabgo convert rs crab

which would mean rs => crab
and

crabgo convert crab rs

crab => rs

I think this is the perfect approach. Its just the right amount of verbosity. It ready from left to right as "from -> to" as most programming languages (all that I've used) do.

I think it completely does away with the need for shorthands.

I am a green hand,and i really don't know the difference and relationship between crab and rust.

The original language that should not be named uses .rs as its file extension.

Crablang should use .cr as file extension.

Incidentally, there exists a .cr TLD.

So in the same way that people have been using .rs TLD with the original language that should not be named. https://en.wikipedia.org/wiki/.rs

Users of Crablang could use the .cr TLD. https://en.wikipedia.org/wiki/.cr

Can we use Cargo or fork the repository for crablang?

As it stands many references to Rst can be found even in the issue templates, this is not a issue for now to my understanding since it's just a draft but might be in the future. All references of Rst should be removed to avoid issues with the R*st Foundation. Thanks for the crabs! Have some more crabs for the effort

A higher level easier to use language. This one is ambitious and will probably consist of some R & D fun to start. One of the most beautiful things about crab is its memory management and thread safety. It would be amazing if a simpler to use strongly typed scripting language such as c# operated with with entirely coerced lifetimes (by default at least unless explicitly typed) and coerced borrows / moves / mutations (also by default unless explicitly typed) based on how the code is used. Pretty much flipping all of the explicitness of rust on its head. Would be a great gateway to bringing on other developers and teaching them the ways of the crab :)

Edit:

Currently the favored name is shrimp!

crab -> shrimp
crabc -> shrimpc
crabgo -> shrimpgo
crabby -> shrimpy
crabfmt -> shimpfmt
crabup -> shrimpup

Code

fn main{
    break rust;
}

Meta

rustc --version --verbose:

<version>

Error output

error[E0425]: cannot find value `crab` in this scope
 --> test.rs:2:11
  |
2 |     break crab;
  |           ^^^^ not found in this scope

error[E0268]: `break` outside of a loop or labeled block
 --> test.rs:2:5
  |
2 |     break crab;
  |     ^^^^^^^^^^ cannot `break` outside of a loop or labeled block

error: internal compiler error: It looks like you're trying to break crab; would you like some ICE?

note: the compiler expectedly panicked. this is a feature.

note: we would appreciate a joke overview: https://github.com/crab-lang/crab/issues/43162#issuecomment-320764675

note: crabc 1.72.0 (5680fa18f 2023-08-23) running on x86_64-unknown-linux-gnu

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0268, E0425.
For more information about an error, try `crabc --explain E0268`.

I never wrote break crab in my source code and if I do, I don't get the joke message.

Hello sirs, thank you for the fork. It is a very nice fork and I am looking to incorporate it into my daily programming but I like to use the logo for purposes related to microblogging and was wondering if it was ok? Is it ok to edit the logo to a theme too?

I'm sure there's many things people want in rust but will never happen because it'd break backwards compatibility.
This fork is free from all of that.

If so should probably reset the version number to 0.0.1 or something.

Why have the Lang part? Just call it Crab.

This is an issue to be ignored in Rust for the long term.
rust-lang/rust#68007

Also, there is already a PR for this.
rust-lang/rust#96574

Could we consider adding it in Crab lang? 🦀

People are very excited about issues such as:

1. #20
2. #10
3. #12
4. #51

And many more ideas sprinkled throughout the issue boards and Discord server.

Even Graydon, the creator of Rust himself, had things he wanted to do differently: The Rust I Wanted Had No Future

I am a firm believer that in the world of software, we can actually "have our cake and eat it too". With the exception of meeting deadlines... so we just won't set those 😎

And I think Rust has proven this theory with its 0 cost abstractions.

So in order to accomplish this... Lets just add crabc as a dependency in Cargo.toml! It might look something like this (see the bottom [crabc]):

[package]
name = "super-cool-package"
version = "0.1.0" # I've accepted that 1.0 will almost never be a thing... so 0.1.0 will do :)
edition = "2021"

[dependencies]
# async stuffs
tokio = { version = "1", features = [ "macros" ] }
# serialization cause its cool
serde = "1.0.147"
serde_json = "1.0.87"
# This one seems to be popular lately
futures = "0.3.25"
# We are gonna do an internet!
http = "0.2.9"

[[bin]]
name = "bootstrap"
path = "src/main.rs"

# Here is the fun bit!
[crabc]
# Options: git | path | url
source_type = "git"

# This can point to a git repo,
# path on host machine (including binaries referenced from PATH environment variable), 
# or a crabc binary being hosted on the internet somewhere
source = "https://github.com/crablang/crab.git#experimental"

# Optional. Will default to using the bootstrapped crabc installed on host machine to 
# compile the experimental crabc. But if the project requires a more complex 
# build of a crabc compiler, then we can point to a build script.
script = "build_from_source.sh"

# Optional. Flags to compile crabc with. Is ignored if using a build script 
# as the build script should provide those. 
flags = [ "nightly", "crab-file-extension", "ternary-operator" ]

Why would we do this?

Currently if users want to use experimental features that aren't in master or nightly, they have to git clone <branch-with-cool-feature> and build from source. This is not a seamless experience and does not streamline the adoption of the most requested features such as the .crab file extension

Also, if a project requires a specific compiled version of crabc with a specific experimental feature, the author of the project has to be relied upon to provide that documentation. This would integrate that piece directly into the build process.

Potential downsides?

I was actually struggling to think of anything reasonable without feeling like I was grasping for straws. This normally leads me to believe I'm on to a good idea. I was able to think of one tho:

1. compiler conflicts 👀

If one user created a package that requires a specific crabc compiler with specific features enabled, it would make the package unusable in other projects. This sounds scary at first (I was actually concerned about this when it occurred to me) until you realize that this is nothing more than a standard dependency conflict. No different that 2 crabc crates conflicting with each other on dependencies. It will be up to the project author to maintain crates that have high compatibility within the crabc ecosystem by building it with features standardized in master. If they diverge with custom compilers, they will have to make note of such. Projects do that today such as rocket.rs v4 and lower with nightly features.

Potential implementations:

1. We could go the route of integrating this feature directly into crabgo. I personally like this idea best for crabgo as it becomes an "it just works" implementation which is always my favorite.
2. We could create a crabgo-crab and cargo-crab subcommand. I really like this idea for cargo. It can be hosted on crates.io and allow for cargo / rust users to point their Cargo.toml to crabc if they so desire! :) I think this would be HUGE for streamlining adoption. It will also help with interoperability between the rust and crab toolchains.

Note that this is a rough draft of an idea that came to me while taking a shower last night.

And another note: I'm not in love with the [crabc] syntax in the Cargo.toml above. We might be able to literally use the exact same syntax for [dependencies]. We can refine that in the comments. Just wanted to get my idea down and shared with you guys.

Do you love it? Hate it?

Is it engine to the rocket that CrabLang needs for taking off and going mainstream? 🚀

Or is it a rabid dog that needs to be taken out back and put down? 👀

Lets refine this thing together in the comments! :)

Edit:

I really like @HTG-YT 's proposed syntax here: https://discord.com/channels/1074804478651400303/1095989994033782814/1116011823733424128

source = { git = "https://github.com/crablang/crab.git", branch = "experimental" }

Would match with the current dependency syntax in Cargo.toml

Edit:

And additionally as noted by @HTG-YT , the source_type field would be rendered unnecessary! 🎉

# specifying a path to crabc
source = { path = "path/to/crabc/bin" }

# specifting a url to crabc
source = { url = "https://example.com/crabc/dist/some-crabc-here" }

Hi all - would love if there was an easy way to install crab via crabup.sh (much like there is a rustup.sh for rust).

Looks like crabup.sh is already registered; do one of the maintainers here have it and could we take use of that for installing crab?

As we all know, almost all of the concerns of the community that led to the creation of this project appears to have been addressed.
With the recent dismantling of the core team, and the new re-architecture of the internal governance structure, it appears the processes(and/or the atmosphere) that's been causing many of the past dramas and science fictions has ended.