QaspR

joined 1 year ago
MODERATOR OF
[–] QaspR 10 points 2 months ago (1 children)

I would very much like to address some of these points, since I don't think you are making a good argument here.

I shall preface this by saying that comparing Rust to TypeScript is a bad idea. They are meant for fundamentally different things and you should not regard Rust as a TypeScript replacement. I will do my best to show why Rust took the paths it did whilst being as brief as possible, but if TypeScript is your measuring stick, you should stick to it.

First of all, cargo does a lot of stuff. This is true, but you are comparing Rust to TypeScript here, and therefore you should compare cargo to npm, npm is the same thing. It does everything all at once, and everyone loves it. Cargo doing everything it does is meant to be a convenient way to interact with Rust projects. That being said, if you don't like Cargo, you can use rustc directly. You can compile Rust code much the same way you would C/C++, with a Makefile.

Multiple string types: As compared to TypeScript, this would seem like an unnecessary complication, but let's compare it to C++ for a second. In C++ you have two string types as well, namely const char * and std::string. These are 'basically' the same as &str and String respectively. It comes down to whether or not you want your string to be heap allocated or not. Allocation is not something you get any control over in TypeScript and for that reason it is possible to have a single unified string type. Also, TypeScript hides the internal representation of strings from you, which is convenient, but can be a real pain in the butt if you're trying to do low-level manipulations.

I would agree that Rust's syntax can be quite terse, but this is due in part to it being a strongly typed language, unlike TypeScript, which is very weakly typed and can therefore simplify a lot of things.

Async code looks ugly in rust. Yeah, it does. Mostly because it's not doing the same thing that it would be in TypeScript. TypeScript async code and Rust async code are fundamentally different. If you have a look at async code in modern C++ you will see a lot of the same complexity as you do in Rust, since it's more closely related to what Rust does.

You say that rust has many different integer types, yet in C you can 'just write int and be done with it'. This is patently false. Here is a catalog of Rust integer types and their C/C++ equivalents:

  • i8 -> char
  • u8 -> unsigned char
  • i16 -> short
  • u16 -> unsigned short
  • i32 -> int (This is the only one you would get if you just write int.)
  • u32 -> unsigned int
  • i64 -> long long
  • u64 -> unsigned long long

In TypeScript you have just number, that's true, but it's a managed language. Again, this hides the complexity from you, but it comes at a steep cost. If you actually want to do low-level manipulations, you have to drop down to something like a Uint32Array type, which is exactly equivalent to [u32] in Rust.

Having to use #[tokio::main] to make an async main. This makes me think you don't understand how async code works. The reason you can just write async code in TypeScript is because there is a runtime. Your code doesn't just run. You need a browser or a Node.JS server or something similar. That is what tokio is (kind of). This also addresses the bloat argument for tokio. Rust does not have a runtime, and therefore when you want to write async code, you need to add one. In TypeScript land, you just get the runtime whether you want it or not.

As for GET requests being 32MB, I don't understand what you mean here. The request itself will never be that large. If you are complaining about the binary size, though, you are likely compiling in debug mode. Switch to release mode and add -C opt-level=3 to the compiler flags and you'll get a binary that's way smaller.

About the libraries, Rust is a young language. Libraries can be hard to find for specific purposes, but that will change over time. Axum doesn't have a home page, btw, because the docs.rs page is more than good enough.

Memory safety is not a buzzword. In mission-critical software (which you would never write in TypeScript, because it's buggy as all hell), memory safety is something you have to have. If you are using C/C++, your memory safety is 'trust me bro'. 'Just use a garbage collector' is not an argument. When people want memory safety, it's exactly because they don't want a garbage collector. I won't go into the specific details, but you are pigeon-holing Rust in with languages like TypeScript and Java, which are designed for different use-cases. Again, Rust is not a 'better TypeScript' and you should not use it if TypeScript is what you need.

Also, any program you write should be extensively tested before release, so you’d catch those memory errors if you aren’t being lazy and shipping broken software to the public.

Not true. Most memory errors that end up being exploited don't cause any bugs and are extremely hard to predict and test for. Rust provides a way for you to write robust software that has some strong guarantees about what the memory of your program looks like. If done correctly, it eliminates the risk that you may have forgotten a scenario in which your program would not be memory safe.

'Just use C/C++': No. C++, for starters, tends to be much slower than Rust and C is way too low-level to get anything useful done without first having to re-invent the wheel. Rust is a modern language, C and C++ are relics of the past. They are rife with problems and technical debt and the fact that they are designed by committee is the reason for that.

If you don't see any reason to continue with Rust, then don't. People like Rust for reasons that would not make any sense to you as a TypeScript programmer. Rust is a good programming language, TypeScript is a patch on top of a broken language. TypeScript is meant to be easy to use and is therefore hard to use for anything other than what it was designed to do.

[–] QaspR 2 points 5 months ago (4 children)

I shall take your critique to heart. Haven't actually thought of that as an issue 😂

 

UnCube is a FOSS web-based speedcubing timer built with Angular Material.

I've been developing this software for the past year or so with no help, so I thought I'd post about it here and see if anyone is interested.

Right now, only the basic features are functional, but I've got a few GitHub issues open that people can contribute to.

You can find the GitHub repo here.

6
submitted 5 months ago* (last edited 5 months ago) by QaspR to c/cubers
 

Finally, UnCube has solve-synchronization. This feature has been a long time coming, but I've been taking a break from development on this app.

For the time being, at least, I'm back.

Some things to look forward to:

Statistics are coming. Soon users of the app will be able to view and export their solve statistics. (Open to suggestions as to the format of the exports)

Help wanted

If you are a graphical designer (and are willing to work for free), UnCube needs an icon/logo. See the GitHub Issue on this for more information. If anything is unclear, you can post a comment there asking for more information.

[–] QaspR 15 points 5 months ago (8 children)

Bro forgot to turn off his phone before they shot him.

[–] QaspR 1 points 5 months ago
[–] QaspR 10 points 5 months ago (3 children)

Darn. They missed the hyphen.

[–] QaspR 2 points 5 months ago (1 children)

Well that clears it up

[–] QaspR 2 points 5 months ago (3 children)

If this is a reference, it's lost on me 😂

21
submitted 5 months ago* (last edited 5 months ago) by QaspR to c/[email protected]
 

Have been struggling to find some nice Rust wallpapers, so I decided to make one for myself.

On the left is Ferris on a canvas. On the right is Corro the unsafe Rusturchin. (The contrast between safe (art-like) and unsafe Rust is supposed to be the joke here.)

Edit: The original image is 1080p. I got the drawings of Ferris and Corro from rustacean.net

[–] QaspR 1 points 7 months ago (1 children)

Name a country where it is not the case that your first paragraph is true.

[–] QaspR 90 points 9 months ago (3 children)

1h ago... 5min ago. You absolute canine. Man's got stamina for days

[–] QaspR 19 points 10 months ago

I for one am thankful for the admins' continued dedication to platform stability.

[–] QaspR 1 points 11 months ago

Ditto on that.

[–] QaspR 2 points 11 months ago

LeftWM. I've been using it for about a year now and I have no complaints vIt doesn't hold your hand as much as other WMs, but it is extremely powerful if you're willing to do some manual setup.

 

To clarify here, I don't feel like I'm significantly smarter than most people, but I feel like people have a hard time doing any sort of thinking about stuff. Especially when it comes to verifying "facts."

9
submitted 1 year ago* (last edited 1 year ago) by QaspR to c/cubers
 

Hi everyone.

This is just an update about the speedcubing timer I've recently started developing. Refer to the previous post for more details.

First things first

The name has changed. As previously mentioned, I was still on the fence about the name and there happens to be a timer called Cubetime that already exists. For these reasons, I have decided to rename the project UnCube.

The old link qubetime.codelog.co.za still works, but in the coming months I will disable the subdomain and remove it's CORS entry.

The new domain is uncube.codelog.co.za.

New features

Account registration is now open! On the main page you'll notice a login button on large screen devices and a menu button with login and register buttons on small screen devices. Though registration and login is now possible, it is not yet possible to save your solves to the cloud. 😞

Also, even though sessions persist, I have not added the logic for checking if a session exists, so reloading the page returns the login/register buttons even though you are still 'logged in.'

Boo! I want to see the source code!

FINE!!! Here you go

As always, let me know if anyone has any suggestions/issues.

EDIT: Added link to GitHub repository

TL;DR Remember that new broken speedcubing timer? It just got a bit better!

 

So, I know that there are loads of great speedcubing timers out there, but I've always felt that these are half solutions that leave a lot of manual work for the user of the timer to do things like synchronising solves between devices.

As a Computer Scientist and hobbyist speedcuber, I felt that I am in a unique position to offer a solution to this problem.

Over the past few weeks, I've been developing a new speedcubing timer that (for now; open to suggestions) I am calling QubeTime. Although QubeTime is in BETA right now and most of the eventual functionality is still missing, I thought I should release it to the public so that I can get feedback as soon as possible.

With that in mind, please send me your suggestions and feel free to contact me using my business email.

The current list of planned features include:

  • Multi-device cloud synchronisation
  • In-depth solve statistics.
  • Import/export to/from all major* speedcubing timers.
  • Easy solve sharing with link previews. (Twitter cards, etc...)
  • ?? Speedcubing news bulletins ??
  • User solve comments.

TL;DR I'm building a new speedcubing timer, it'll have lots of cool features.

view more: next ›