Threads for iddan
-
Finishing the implementation of a new formula engine for React Spreadsheet which supports dependant formulas and ranges. https://github.com/iddan/react-spreadsheet/pull/248
-
Are the Python and TypeScript type systems similar?
-
Yes and no. Python’s type system affects runtime in the sense that you can analyse it on runtime while TypeScript’s is build only and removed at build time. But both serve the same core goal of adding stricter typing to dynamic languages (Python and JavaScript) and they learn a lot from each other.
-
No. Assuming we’re talking about mypy (Python doesn’t have a blessed type system, but type annotations), then mypy by default is nominally typed rather than Typescript’s structural typing (though Mypy has support for protocols, which look like structural typing)
Ultimately Python’s object model is very different from Javascripts due to descriptors, so it makes stuff like Django models hard to model. On top of that, mypy doesn’t have some extremely useful type system utilities like declared type guards and type intersections.
In my experience, mypy often feels like its approaching what many have experienced in OOP languages, whereas Typescript’s structural typing + type level programming aims to go much further.
That being said both tools have similar onboarding strategies and work reasonably well with a typed/untyped code mix.
-
Don’t ES6 classes have descriptors (or at least getter / setters)?
And unless I’m misunderstanding what you mean, python does have
typing.TypeGuard
-
-
-
When I was working on Cayley it was very missing. Standard iterators in Go will make any stream processing work much easier to go about.
-
Actually, not programming a lot. I’m working in a YC startup and the focus rn is on growth so I’m mostly writing sales emails and other prose. Last week I used some of my code smarts to find leads and enrich their data (small scripts in the Developer Tools + Excel can take you really far).
-
I remember spending so much time installing different builds of Chromium OS and Android X86 on my netbook. This was the first time I encountered the terminal, BIOS, etc. I’m glad there’s an official solution if I would need to modernise an old computer of a friend
-
Met some friends for speciality coffee and spent time with my family (It’s the end of the weekend in Israel)
Rust and Go fits different purposes. And why should OCaml be chosen over Go? The main point of using Go is to get amazingly short compilation and test cycles, even for large projects.
Rust and Go are similar in that they’re some of the only memory-safe ahead-of-time compiled languages at our disposal.
The specific criteria that the author was using were these points:
OCaml can be picked over Go if point 2 is more important than point 8 for your software.
It’s not discussed in the article, but the OCaml compiler is also fairly fast, particularly compared to the Rust compiler.
The bytecode compiler is much faster than the native code compiler though. To the point where in some cases I found myself using the bytecode compiler because compilation times were dominating my otherwise short test cycle.
With OCaml you get more safety and expressivity
I agree. But is there measurably more safety than in Go, though, from a deployment/security perspective?
Yes.
Golang’s type system doesn’t even attempt to prevent nulls, which are the most common type error by a wide margin. There is an enormous difference.
nulls is not a common type error in Go. I understand that it may look that way from a syntax perspective, but in practice, and from a deployment/security perspective, I don’t believe that this is the case.
I wish there was statistics available on this for Go.
While not a direct answer to your question, some of the concerns raised in this paper make me want to believe that you are much more likely to shoot yourself in the foot in Go, security and deployment wise.
https://arxiv.org/pdf/2204.00764.pdf
I’m not sure that’s the case. They seems pretty common to me and I’ve certainly encountered them in Go projects I’ve used.
OCaml compilation and test cycles are not appreciably different from Go’s during development. I’ve used both. OCaml gives me much better type safety. In Go what I’m always wary of is the default emptiness of values which aren’t initialized for whatever reason. E.g. if I have a struct type and add a new field, the compiler doesn’t help me refactor my code in all places which work with this struct to ensure that the new field is handled. In OCaml it does.
I think the author agrees here : Rust and garbage collected Rust fit different purposes.
That’s very subjective so probably not exactly what the author has in mind, but what I imagine a garbage collected Rust could be is a language whose design would de-emphasize performance a bit in favor of ease of use. So no lifetimes, no multiple variants of string, but the type safety story. And I imagine the performance would be in the same ballpark as Go, hence the mention.