Earlier quoted context omitted.
I completely disagree with this. I work on a large C# platform that interops with a ton of vendor API's, the majority of which are also written in typed languages. The disjointed, loosely coupled nature of web systems is what causes problems. In particular, knowing what a "correct input" is to web systems is very difficult, where correct means: 1) Passes the API's immediate validation 2) Passes validation inside API'…
> knowing what a "correct input" is to web systems is very difficult I cut my teeth programming an XML web service using soap and while I can't say that it was as drop-dead simple as a restful HTTP web api these days, between the wsdl and the uddi, it sure was convenient to be able to know as a client what methods were being exposed and what inputs they expected. Sometimes I wish the w3c had not required XML for thos…
Moving from TypeScript to Rust / WebAssembly
311–320 of 428 posts
Re: Moving from TypeScript to Rust / WebAssembly
#312Earlier quoted context omitted.
There isn't necessarily any inherent thing about the language itself that makes it better at WASM than others, it's more that it was one of the first languages that was ready for WASM. - It's low level like C and C++ so it maps cleanly onto WASM - In your average Rust project, all dependencies are already built from source, greatly increasing the likelihood all your dependencies can be built for WASM - Already using…
You forgot the most important thing: it doesn't need a garbage collector. This is important because wasm garbage collection is a work in progress. The solution other languages targeting wasm typically use is bundling their own garbage collector in the compiled code, which of course adds a bit of code bloat. E.g. C# blazor wasm applications are not exactly small for this reason. There was a message yesterday in the Ko…
Re: Moving from TypeScript to Rust / WebAssembly
#313Earlier quoted context omitted.
The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!
The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.
https://www.mediaan.com/mediaan-blog/kotlin-vs-java Things like state of the art type inference, data classes and lambda syntax, no semi colon and ton of other things allow for reduced syntactic noise.
Re: Moving from TypeScript to Rust / WebAssembly
#314Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev…
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…
Every time you write logic in your code, your brain is aware that the logic is dealing with a specific type. Writing a type signature on top of that is just additional instructions to the compiler about the type you have already specified in your logic. It is a minor inconvenience.
There are many reasons why Ruby and PHP won out. One of the reasons is many people misunderstand the power and flexibility of types. Once they understand this, they will know there is really no trade off between statically typed and dynamically typed. Statically typed languages are infinitely better and the only downside is a minor inconvenience.
First off, note that there is only one function in the universe that can really take every single type in existence and that function is shown below:
-- haskell
identity :: x -> x
identity x = x
# python
def identity(x: Any) -> Any:
return x
This is the only untyped function in existence. Every other function in the universe must be typed whether it is typed dynamically or statically is irrelevant, either way your code will have to specify the type in logic or in the type signature. You can see this happening in the examples below...The above example have no logic to specify a type... The minute you start to add any logic to your function immediately your function becomes bounded by a type. Let's say I simply want to add one in my identity function.
-- haskell
identity :: Int -> Int
identity x + 1 = x + 1
# python
def identity(x: Int) -> Int:
return x + 1
The very act of adding even the simplest logic binds your function to a type. In this case it binded my function parameter to an integer. Whether you use PHP or Ruby or Rust there is a type signature that describes all functions.Let's say I want to do garbage code like write a function that handles an Int or a String? That can be typed as well....
--haskell
type IntOrString = Number Int | Characters String
func :: IntOrString -> IntOrString
func Number n = n + 1
func Characters n = n ++ "1"
#python
IntOrString = Union[str, int]
def func(n: IntOrString) -> IntOrString:
if isinstance(n, int):
return n + 1
if isinstance(n, str):
return n + "1"
Let's say I want to handle every possible JSON api in existence? Well it can be typed as well. -- haskell
type JSON = Number Float | Characters String | Array [JSON] | Map String JSON
func :: JSON -> JSON
func Array x = x ++ [1.0]
func x = x
-- python
JSON = Union[float, str, List["JSON"], Dict[str, "JSON"]]
def func(x: JSON) -> JSON:
if isinstance(x, list):
return x + [1.0]
else:
return x
There really isn't any additional flexibility afforded to you by a dynamically typed language other than the slight overhead of translating the types you already specified dynamically into types that are specified statically.One caveat to note here (and this is specific to haskell) is lack of interfaces specific to record types. I cannot specify a type that represents every single record that contains at least a property named x with a type of int.
Re: Moving from TypeScript to Rust / WebAssembly
#315Earlier 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…
> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously usef…
(1) Is "batteries included"
(2) Has the gem/engine ecosystem where basically every problem is already solved.
(3) Expressive code like has_many :things
If we could get those things + static typing + performance everyone would switch. But that doesn't exist.
Re: Moving from TypeScript to Rust / WebAssembly
#316Earlier quoted context omitted.
There are not comparable afaik. WASM is also more ambitious, along with WASI (system interface) creating a portable final executable (compare to JVM), whereas LLVM is only a set of intermediate language and tools. When this transition period goes away, LLVM should hopefully compile to WASM binary as a target. The current path described in the video of WASM -> C -> clang -> llvm -> native-binary is a temporary workaro…
WASM isn't "more ambitious". It is a spec for portable bytecode, nothing more, nothing less. LLVM is one of the best toolchains for many languages. They are completely different things.
Re: Moving from TypeScript to Rust / WebAssembly
#317Earlier quoted context omitted.
Rust does not yet have local custom allocators ala C++. (You can change the global allocator, but this doesn't help the "memory arena" use case.) The feature is very much on the roadmap, though.
While this is true, this doesn't inherently mean you can't do this pattern. https://crates.io/crates/typed_arena for example. It depends on exactly how allocations and your data structure are tied together.
Re: Moving from TypeScript to Rust / WebAssembly
#318I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive? Rust being closer to the hardware should require more code, and effort, to accomplish the same task.
With the patterns and libraries used in just this example, you can write a very high performance, memory efficient web server that can handle a large volume of concurrent requests that involve database interactions: https://github.com/actix/examples/tree/master/async_pg
All of the work has been consolidated down to a single file for illustration purposes, and it would usually be spread across files. Does it seem like a ridiculous amount of additional work, compared to other languages? I am misleading you some as there is actually a lot more to write the moment we move beyond plain vanilla workflows but this example proves what is possible.
Re: Moving from TypeScript to Rust / WebAssembly
#319Earlier quoted context omitted.
Not sure if this is a place to ask this but if someone does not have experience working with Javascript, they might have trouble reasoning about this code: https://codesandbox.io/s/is849 edit: complete code ```typescript class Person { id: number; name: string; yearOfBirth: number; constructor(id: number, name: string, yearOfBirth: number) { this.id = id; this.name = name; if (yearOfBirth 2020) { throw new Error("I d…
What’s confusing? I must’ve missed it in my cursory scan.
Re: Moving from TypeScript to Rust / WebAssembly
#320Earlier quoted context omitted.
That's pretty interesting. Could you share you project? There are benchmark which compare JavaScript and AssemblyScript: https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks/issues/3#issuecomm...
I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity in…