How can you pronounce this word?

What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.

Did anyone say that something was wrong with typescript? It’s my preferred language these days, in non-tech enterprise you’ll basically have to use it and since it’s good enough for everything, it’s easy to have small teams that can all work together in one language. This means the frontend developer gets to go on vacation (or call in sick) without bringing a laptop. It also means you can easily share in-house libraries and ask each other for ideas/troubleshooting more easily. And so on, there are obviously downsides as well but over all it’s a joy to work with.

That doesn’t mean I don’t want Rust “people” to work on frontend stuff for Rust. Typescript is good, I like using it, but I’d like to have options. If not for anything else, then for Typescript to take the best parts of Rust and use them.

I don’t personally think we’re going to see a massive shift away from a JavaScript world until someone like Microsoft starts driving the change. The amount of resources they pour into Typescript means it’s not likely to leave my world any time soon. But if it did, and something better came along then I’d be happy, not sad.

Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid.

Larger bundle sizes - yes that's still true.

And not all GUIs are web GUIs, so WASM isn't the whole story.

Yeah played with some Leptos wasm and i believe something simple like their book tutorial was like 335kb or so. Not that shocking and for me personally totally acceptable. I do wish browsers would ship with their std lib for wasm. So wasm is can become more competitive on bundle sizes with Javascript which has its std lib shipped with browsers.

Yeah also note that 335kb of wasm isn't as bad as 335kb of javascript.

Its true that large javascript bundles are bad because big files take longer to download. But the arguably larger problem is that parsing javascript is really slow. This isn't as big an issue with wasm - the browser can parse wasm many times faster than it parses javascript. If I recall correctly, wasm parsing speed is about on par with the speed of parsing pngs.

So having 335kb of wasm is similar to having a 335kb image on your landing page. Its not ideal, but its not a showstopper.

My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.

It’s not WASMs fault. Rust produces large binaries for whatever reason and people like to write their WASM in Rust. I’ve ported Rust to equivalent C and it was 25% of the size and similarly for loading times.

it is rather simple, JS tooling cares A LOT about the size of their dependency tree. Statically compiled languages do not (except if they focus on embedded programming). Having a binary be 2mb vs 30mb is not a big deal for a desktop application

Just for reference I was testing this the other day and compiled some simple C++ to WASM and adding:

std::cout << "some text";

to the code increased the binary size by like 5mb. Turns out std:cout pulls ALL currency-formating, date-formating and i18n code in the c++ standard library into your binary

ansi C printf does not meaningfully increase your WASM binary size

If you want your code to be able to be loaded on-the-fly and fast you need bundling tools, just like JS does. Bundling is a really hard problem, game devs struggle a lot with it as well (although their problem is usually bundling assets, not code itself)

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes:

- A custom panic message (so you know which line of code crashed)

- Some monomorphized formatting code to output that message

- The infrastructure to generate a stack trace after a panic

- Logic to free all the allocated objects all the way up the stack

If you compile this 1 line function:

    pub fn read_arr(arr: &[usize], i: usize) -> usize {
        arr[i] // (equivalent to 'return arr[i];')
    }

... You produce 20 hairy lines of assembler: https://rust.godbolt.org/z/dhz34KEvj

In contrast, the equivalent C function is this rust code:

    pub fn read_arr_unchecked(arr: &[usize], i: usize) -> usize {
        unsafe { *arr.get_unchecked(i) }
    }

And predictably, the result is this gem - identical to what the C compiler outputs:

    example::read_arr_unchecked:
        mov     rax, qword ptr [rdi + 8*rdx]
        ret

But nobody writes rust code like that (for good reason). You can get a lot of the way there by leaning heavily using rust's iterator types and such. But its really difficult to learn what patterns will make the rust compiler lose its mind. There's no feedback on this at compile time, at all.

I'd appreciate any more tips or resources you might have about reducing Rust code bloat. I want my library [1] to be acceptable to the most strident anti-bloat curmudgeons, so they'll make their UIs accessible.

[1]: https://github.com/AccessKit/accesskit

I don’t know many good resources to learn this stuff unfortunately.

The things I reach for in practice are godbolt and cargo asm[1] - which can show me the actual generated assembler for functions in my codebase. And twiggy[2], which can tell you which functions are the biggest in your compiled binary and point out where monomorphization is expensive.

When I’m developing, I regularly run a script which compiles my code to wasm and tells me how the wasm file size has changed since the last time I compiled it.

Some tips:

Try to avoid array lookups with an index when you can. When looping, use slice iterators and when making custom iterators, wrap the slice iterator rather than storing a usize index yourself.

Be careful of monomorphization. If you’re optimising for size, it can be better to take a dyn Trait rather than making a function generic.

And play around with your wasm API surface area. It takes a lot more code to pass complex objects & strings back and forth to javascript than other types.

But otherwise, good luck! Love the project.

[1] https://github.com/gnzlbg/cargo-asm

[2] https://github.com/rustwasm/twiggy

Great project - this is important! Love your clear motivation statement at the top. I do wish there were some code/data examples within the README, but clearly that's not holding people back from using it.

Rust can be the same size if you put the same code into the binary, sometimes even smaller.

The problem is that it's real easy to just add a bunch of crates to an application, similar to the nodejs/Python approach.

Most people slso don't seem to turn off many parts of the standard library they don't, even for platforms like WASM. Maybe it's useful to have a stack unrolling panic handler during debug but in release you can just abort and save up to megabytes of space.

There's also a lot to be gained by tweaking the compiler optimisers. By default the optimizer is multithreaded, which makes compiles quite a lot faster, but reduce that to a single thread and suddenly a lot of optimizations can happen that wouldn't happen by default.

I wouldn't write code like described here in C, but I imagine Go and C# are better choices here. Maybe even that Java library the name of which I can never remember, or that Kotlin project that compiles Kotlin to Javascript with super easy interaction between frontend and backend.

I love Rust but if you're going to pick a systems programming language for your frontend, just make desktop supplications. Web is a nice fallback but if it's your primary target, there are so many better options out there.

And since everyone likes to talk about how great and magic the WASM sandbox happens to be, who cares if C is being used.

When you ship javascript, the Browser already has a lot of the bigger libraries built in. When you ship rust/wasm, you need to ship all of the basic types like Strings, Vecs, + a lot of the std

> What's wrong with TypeScript.

I love typescript, but, from my PoV, what I miss in typescript is:

- An actually sound type system: This is a big one. Can you figure out why this[0] is unsound?

- I regularly have to do `as ` assertions, and I know it's not because I'm bad at typescript because it's often the recommended solution from cream-of-the-crop tS libraries for certain issues.

- Traits

- new-types

- Algebraic data types: Option and Result. 'nuff said.

- Pattern matching: :cheff's kiss:

[0]

    export function useSetter<T, K extends keyof T>(
      state: T,
      setState: (n: T) => void,
      key: K
    ) {
      return useCallback(
        (val: T[K]) => setState({ ...state, [key]: val }),
        [key, setState, state]
      );
    }

Where did you check that?

If you're talking about Wasm with Emscripten, yes there's a cost of loading the runtime because Emscripten comes bundled with a lot of stuff.

I'm skeptical that just wasm itself was slower or heavier.

It's sorely lacking Haskell features, I have sometimes written functions to simplify my code to find out the function signature is several lines of code and MUST use references

    fn apply<A, B, C, G>(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C
    // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
    where
         G: FnMut(A) -> C,
         B: Copy, // for dereferencing
         A: Clone,
    {
         move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }

all this did so I could write in my code

    ...
         .filter(apply(second, i))
    ...

I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware.

Is that not the case? It certainly looks nice, but is it ready for use?

The main issue was that V promised automatic memory management like Rust, but without the "trouble" caused by the borrow checker, which is something anyone who knows about the problem more deeply would laugh at.... last I checked, they were still at the same stage as a few years ago with that: "it will be working soon". It will almost certainly always stay there.

The problem is that although the creator is gifted, he seems to not have much theoretical PL design knowledge. That is an issue for something as complex as this; this automatic memory management without a GC is cutting edge research and we don't know if we can make it work without making sacrifices like Rust did. You have to sacrifice something and that means while you won't have to worry about memory management, the work for the programmer becomes harder. Or just use a GC.

Vlang is worked on by a large group of different developers, not just the creator. It seems this gets lost in a lot of narratives, as if it's a one man show. If you check V's GitHub, it's clear to see they have many contributors and developers who are professional programmers or have extensive backgrounds.

Autofree already works (to a significant extent) and has been demonstrated[1], for years now. Vlang's Vinix OS[2] uses autofree.

The situation (as I understand it) is unlike using a GC, autofree requires the user to have knowledge of memory management and how to use it properly. One of the objectives of Vlang is to be easy (easier) to use. Using a GC as the default, proved to perform very well with the language, and presented less complications for users.

It appears the strategy of the Vlang developers (as stated on their website and documentation) is to go with flexible memory management. That is the GC can be turned off whenever the user wants (-gc none), and other memory management options can be used such as autofree (-autofree) or their arena allocator (-prealloc).

This flexible memory management strategy would be somewhat similar to what Nim did, and interestingly, I don't see people crying as much about it. Furthermore, there is more to Vlang as a programming language than just autofree, as if its the only thing that counts. People use it for many other reasons.

1. https://www.youtube.com/watch?v=gmB8ea8uLsM (Autofree demo) 2. https://www.youtube.com/watch?v=mJG4Zg6Ekfw (Vinix OS)

Reminds me that I need to check https://vale.dev/

This is another one that tries to attack the same surface area as rust but aims at being easier.

Have you tried Vale or Lobster though? Research in memory management semantics is a lot more sophisticated than you might think.

Everybody is trying to make a more user-friendly Rust. The problem is that it is not clear yet whether that's possible, and if it is, how it may look. I know Vale and have tried it, though it's extremely early to judge anything so far. It does have a much stronger theoretical background than V, but even the theory is not completely clear at this point.

There is also Carp by the way: https://github.com/carp-lang/Carp

People should be allowed to have a difference of opinion and like other programming languages, without a swarm or mob of evangelists going on a downvoting party. If others like Rust or Go, that's their preference, but it's not necessary to bully other programmers.

Lots of people like Vlang, so better to accept that. Not everybody is going to prefer or think the same in regards to programming languages.

The website is terrible.

What is the alternaive?

GitHub container registries are free for open source projects. For now...

SSR is included? Do you have some project that is completely build with this stack. Some real life project?

We use SSG under the hood, a good example would be our main website https://pynecone.io which is fully built in Pynecone.

This is another problem of Phoenix. There are some big projects running on it, like cars.com but the code is not public and also they have a team of people who are good programmers and can bug-fix or pay people who can help bug-fix things for them. Watch the presentation of their switch to Phoenix and the gotchas they have encountered - for example how at first they didn't take into account the impact on Phoenix when users of sites like cars.com have opened 10 or 20 tabs (that have to be updated via websockets) instead of just 1 or 2 when they are comparing their dream car and how they thought that switching to Phoenix was a bad idea. Of course, they are smart ()or have money to pay smart programmers) and they solved this problem and now are happy with Phoenix ;). But as I said in previous posts, unlike with PHP that is very forgiving for sloppy code, Elixir does need higher skill level and the barrier to master it much, much higher than PHP.

Hi, software developer at Cars.com here. While I appreciate the ego boost of thinking that we're somehow better than average, I don't believe this to be true. You can get away with sloppy Elixir code just as easily as you can in PHP, Ruby, Python, etc.

> they thought that switching to Phoenix was a bad idea

If you have the time I recommend re-watching Zack's talk. This is not a take away, or implied.

I work on an application that's probably about as large as Cars.com and we've never run into an issue that was caused by phoenix or elixir specifically. We've had to write a few things in house that may be available off the shelf in other languages, but it's never been especially difficult or time consuming. Most of us are average devs, and it the tools just work. We love how easily we can run things in parallel and we have a lot of soft real time problems that the language makes trivial.

We also onboard a lot of people with no elixir experience, and most of them are committing code within a day or two. The docs are great and the surface area is pretty small. On boarding just isn't an issue.

You’re misrepresenting what’s being said in this talk (the relevant part of the talk is around the 15 minute mark at : https://youtu.be/XzAupUHiryg ).

The tldr was that they had patched some of the library code without considering the ramifications of the change. At no point in the talk is it said that “switching to Phoenix was a bad idea”.

Also, none of the issues they talk about are related to the lack of static typing.

So? Laravel uses type hinting, ok.

This has absolutely nothing to do with your previous post grossly misrepresenting a talk. You hadn’t even mentioned Laravel in it.

Type hinting is not equivalent to a static type system, which is what the parent was asking about.

Finally, in either cases, it changes nothing to the fact that the pain points mentioned in the talk were not caused by the lack of a static type system (which is not to say it cannot cause pain points)

I guess he is talking about macros and perhaps the syntax which I also didn't like and is one of the reasons why I consider PHP better (even though the naming and parameters inconsistency could be better). Check for yourself:

``` iex> length([1, 2, 3]) == length [1, 2, 3] true ```

or (taken from the Elixir docs):

---

Take the following code:

``` if variable? do Call.this() else Call.that() end ```

Now let’s remove the conveniences one by one:

do-end blocks are equivalent to keywords:

`if variable?, do: Call.this(), else: Call.that()` Keyword lists as last argument do not require square brackets, but let’s add them:

`if variable?, [do: Call.this(), else: Call.that()]` Keyword lists are the same as lists of two-element tuples:

`if variable?, [{:do, Call.this()}, {:else, Call.that()}]` Finally, parentheses are optional, but let’s add them:

`if(variable?, [{:do, Call.this()}, {:else, Call.that()}])` That’s it! Those four rules outline the optional syntax available in Elixir. Those rules apply everywhere consistently, regardless of the construct you are invoking. Whenever you have any questions, this quick walk-through has you covered.

---

I don't like this possiblity to use so many syntaxes good, especially if you deal with mulitple parameters in functions. Elixir doesn't have C-like semicolons or braces like in Lisp so multiple parameters are hard to parse sometimes.

The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict and he mentions the optional () e.g. IO.puts "Hello" vs IO.puts("Hello").

> I don't like this possiblity to use so many syntaxes good

There other side of the coin is having specialized syntax for each construct. For example, PHP currently lists [56 keywords][0], and each keyword generally comes with their own grammar rules (I picked PHP because it was an example you mentioned above).

Elixir, on the other hand, has [15 keywords][1]. Defining modules, functions, conditionals, and so on, all use the same syntax rules. At the end, you end-up with less syntax because the whole language is built on the few affordances above. The other benefit is that developers can also extend the language consistently, since the constructs for designing and extending the language are the same.

> The creator of Elixir himself answered that one of the things he thinks he could do better at the beginning was to make the syntax more strict

If I could go back in time, I would have made it strict since the beginning, but we have already made it strict over time through deprecation warnings in the last 7-8 years. Given a time machine, I'd probably not have changed the notes you mentioned above. :)

0: https://www.php.net/manual/en/reserved.keywords.php 1: https://hexdocs.pm/elixir/syntax-reference.html#reserved-wor...