Copy-pasting the if/else code (step 2) and then executing resulted in it spinning for about 20 seconds before I lost interest and killed it. The "Hello World" (step 1) did complete, after about 6 seconds.
Works for me, looks like your internet might be slow, at least when connecting to this site, as I believe it works by running the code in the cloud and streaming the results to you. Or perhaps it works on the machine, not sure.
It takes some work (mostly due to LLVM building code to run later in its build system as it goes), but it's very feasible. LLVM has been ported to Wasm (and before that to JS) many times, for example:
This is a pretty cool idea. Thanks for investing time into making these. There's a few unsolicited (That's the way we do stuff on the Internet :P!) usability/UX improvements that I would like to suggest:
The stability of the compiler endpoint/service is really finicky, and it performs poorly (those could both be related to load issues, maybe it's just front-HN-page syndrome). Not sure if it's possible to replace it with another one or try hosting your own perhaps?
The code transformations are really unpredictable. Sometimes it asks me to copy/paste code, sometimes it starts with its own version of the code. Sometimes the next step "undoes" my fixes (I know Rust so I was "rushing" ahead with some changes, which is my fault). There's a few ways that could be done here, but IMHO the best would be to have a "use this snippet" button and to just not touch the code from the previous step. If the lessons have chapters and you want to set up the editor for the user, that's fine, but make sure it's obvious someone's moving onto the second chapter of the tutorial. At the end of the day, if you choose to just have manual copy-and-paste (the least ergonomic choice, IMO), that's also fine, but just make the experience consistent and predictable.
The layout is extremely disorganised on the page. There's a giant disconnect between the console, the editor, the run button, and the hints, and the test results. There is no well-defined user flow on the page, interactions feel very erratic. I can't offer any ideas here for how to fix the layout, because it will get very wordy. To sum it up though, the page needs more structure/hierarchy. This will also create space on the page, so you will be able to use some whitespace/negative space to create hierarchy too (it's a bit of a chicken & egg problem lol).
Lastly, the "checkpoint" doesn't always pass when it probably should, because there's no hint as to why it didn't pass, apart from a compiler warning. The compiler warning is important and should be fixed, but a couple of times it was simply because the injected snippet came with "previous" problems that distracted from the step/instruction at hand.
I can't really comment on the quality of the tutorial since I stopped after 16 steps; I couldn't keep going any more because I was incredibly worn out by the poor UX. Proceeding to the next step was was always some struggle in relation to UX, and not the content of the tutorial.
With that said, some things for content until step 16, I think some concepts are a bit inaccurately explained, but I suppose one could let that go because you wanted to keep the tutorial short.
Back to the drawing board. I have been spending a lot of time on lesson creation, because that's what I've been doing, then I run through the course because I made it and I know how to pass the tests. I'll need to take a step back, gather more feedback, and address the problems you've raised.
Keep up the good work! I love interactive learning as a concept, and I think you're already most of the way there. Most of my complaint was more design related than lesson related.
I realised later that I can jump to lessons, so I skimmed what the rest of the content is. I think content wise it's good. Given its "Rs for web devs," my comment about inaccuracies might've been unfair. I assume the lesson meant to be bite-sized and playful/exploratory. So, its in a good format for that.
Not OP, but lifetimes are pretty brutal in many cases. Consider deserializing a struct with fields that are borrowed--I'm not sure if it's straight-up impossible or just prohibitively difficult, but it's painful. Not an issue with a GC language.
I'm still rooting for Rust, but it's not for everything (yet).
Life times are either easy for trivial matters or add a lot of boilerplate in the other cases.
Many people just go RC<> but then you have RC<> everywhere.
I do understand the motivation to have lifetimes and no GC, and it's cool, but it makes things that are trivial in a language with GC often difficult in Rust (the problem might be with me only as I've stopped working with C around 1995 and have been on GC/automatic RC since then, starting with Perl).
"Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful."
I believe the author is present, and this should have been a [Show HN]. The submitter's username matches the author's username on the site, and the submitter has replied to feedback comments as the author would.
(Not the previous commenter, yet thought this context was the most relevant)
We can always update the examples. The principle of not commenting about superficial annoyances is unlikely to change, and I think it's helpful (that's why we added it! actually, users asked us to add it, IIRC).
As first I thought this is about "Rust programming concepts that can benefit you in JS as well", but this way it is good too. And maybe just my bad english anyway.
