That is quite a move. Like moving from USSR to USA.
Moving from TypeScript to Rust / WebAssembly
231–240 of 428 posts
Re: Moving from TypeScript to Rust / WebAssembly
#232> For example, the data might contain additional fields or even incorrect values for declared types. I understand 'incorrect values' (this is true, see https://github.com/Microsoft/TypeScript/issues/15480 ) . But TypeScript definitely doesn't like adding additional fields. Right now I'm working on TypeScript, added the new Fastify raw body plugin, and forgot to extend our custom Request type. The error is: Property '…
Something like this is valid TypeScript I think?
interface MyType {
a: number;
}
function process(value: MyType) {
console.log(value);
}
const value = { a: 1, b: 2 };
process(value);Re: Moving from TypeScript to Rust / WebAssembly
#233Earlier quoted context omitted.
This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you…
They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…
I am currently writing a hobby project in Rust with Rocket and Diesel. I could bang out a working prototype very quickly with either Python or something like ASP.NET, but I picked Rust because I want to get better at it.
Many of the things you say are true - Rust libraries in general need some love and polish before they can be beginner-friendly, but some are getting there. The difference between Diesel and Rocket, for example, is quite stark. The former has only the barest minimum 'examples' and 'guide', if they may be called that, and I feel like I'm expected to read and understand its source code to become really proficient with it. It takes a lot of experimenting and trial+error to do anything beyond the basics. Rocket, on the other hand, has a very comprehensive guide with useful examples and, so far, has been enjoyable to work.
That said, there are still a lot of "convenience" features missing. My current notable example is forms. As I'm doing it (I haven't looked into any addons to Rocket for this), I have to write out the HTML for the form myself, along with any Javascript I might require for validation, etc, then write the server-side methods for GET/POST, making sure to maintain the state myself. In this regard, something like Django's effortless ease to get a form on screen and store its data into a database really showcases where Rust (Rocket) still has a long way to go.
Hopefully, with more people using it, the tools and libraries will improve and mature, particularly the documentation.
When all is said and done, I enjoy "slogging" through Rust a lot more than I did working with Django, even with the slower progress. Something about this language really speaks to me.
Re: Moving from TypeScript to Rust / WebAssembly
#234Re: Moving from TypeScript to Rust / WebAssembly
#235Earlier quoted context omitted.
Rust actually can be a higher language. It has true generics, static algebraic data types, functional programming features, and so on, even as it is closer to the metal. It is closer to Haskell or OCaml, but more pragmatic.
In what ways is Rust more pragmatic than OCaml?
Does not really require you to drop to a lower-level language for performance, unless you really need to use assembly for something.
OCaml is great for the application level stuff, and also performs quite well in general. But for building fundamental parts of the stack in which perf is important (like the multi-threading runtime, the garbage collector, etc.) you need to drop down to C++, C, or Rust.
OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH.
Re: Moving from TypeScript to Rust / WebAssembly
#236Earlier quoted context omitted.
Less testing, Documentation, Guarding against typos, better IDE support, better performance; But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier". The world would be nice if management people understood not al…
> the 10x programmer is not a myth You are right that quality of programmer skill and productivity has high variance, but the way people talked about the "10x programmer" was a vague vision that people pasted their ideas and personal bugaboos onto. So people got into increasingly-heated arguments and talked past each other. When we create social concepts, we need to strive for something like falsifiability -- somethi…
Is less because there are a few 10x programmers, and more because there are a whole hell of a lot of 0.1x programmers.
Re: Moving from TypeScript to Rust / WebAssembly
#237Good idea.
TypeScript is too Java/C# for my taste. Rust feels more OCaml-ish.
It has more predictable performance than JavaScript and often it can be better.
If Rust gets a bit more ergonomic (via language or crates) it could be a good alternative and finally save us from the horrors of Electron/Slack/Bitbucket/etc.
Re: Moving from TypeScript to Rust / WebAssembly
#238> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…
WebAssembly with Rust is sometimes bigger and "just as fast as JS".
But it's way more predictable, no more crazy 95th percentiles.
Re: Moving from TypeScript to Rust / WebAssembly
#239I will only nitpick on the part about TypeScript not being type-safe enough, where extra fields are possible or wrong types can be sent over the wire. io-ts [0] completely solves this issue, to the point where I don't think it's less type-safe than Rust in any practical manner. I've been writing apps in TS this way for the past year and I have quite a large codebase in production. The errors you mention do not happen…
I love things like this, but at the same time when I look at the API this library provides, it's not junior-friendly. Even though I acknowledge it solves some problems I'd like to solve, if I put code using this library infront of a junior developer, they'd be paralaysed, and at best, if they weren't, write code with it that another junior wouldn't understand. That makes it difficult for me to justify introducing it.
I agree in principle, though in this particular case io-ts does not tend to produce incomprehensible code. Maybe if juniors use it, it would, but it's easy to encapsulate the IO codecs in their own modules where the functional style of io-ts/fp-ts does not leak out to other parts of the code and only types can get reused.
Re: Moving from TypeScript to Rust / WebAssembly
#240Earlier quoted context omitted.
For the most part, lifetime is inferred from scope, so there isn't anything special to figure out; objects live exactly for as long as you can see and use them. This also includes such things as lock handles, or references to refcounted objects.
Only in the most trivial cases. Tons of real Rust uses copying or RC/ARC or even unsafe to avoid dealing with complex lifetimes because it's... complex.
Copying, refcounting and locking work within the exact same semantics. They're among the most typical tools that are used to transmit or share data, so I'm not sure why it should be strange to see them used in most real programs?