5 ms·
Beware the greenfield effect. I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it
by namuol 1y ago
Beware the greenfield effect.
I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it’s better” is essentially a fact of life no matter the tech choices, at least for the first big rewrite.
First, you’re going to make better technical choices overall. You know much better where the problems lie.
Second, you’re rarely going to want to port over every bit of technical debt, bugs, or clunky UX decisions (with some exceptions [1]), so those things get fixed out of the gate.
Finally, it’s simply invigorating to start from a (relatively) clean slate, so that added energy is going to feel good and leave you in a sort of freshly-mowed greenfield afterglow. This in turn will motivate you and improve your work.
The greenfield effect happens even on smaller scales, especially when trying out a new language or framework, since you’re usually starting some new project with it.
[1] A good example of the sort of rewrite that _does_ offer something like an apples-to-apples comparison is Microsoft’s rewrite of the TypeScript compiler (and type checker, and LSP implementation) from TypeScript to Go, since they are aiming for 1-to-1 compatibility, including bugs and quirks: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
- janderson215 1y agoThis is a good take, so thank you for sharing. Can you please rewrite it in Go?
- kristianp 1y agoMicrosoft rewriting typescript tools in Go and getting a 10x speedup? It's wild that they would choose Go for that. And a surprising level of speedup. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
- tapirl 1y agoMy surprise is typescipt is so slow. I have never used it yet, but I think will never too.
- tgma 1y agoI suspect the particular use-case of parsing/compiling is pathologically bad for JavaScript runtimes. That said, they are still leaps faster than reference Python and Ruby interpreters.
- deleted 1y ago[deleted]
- antonvs 1y agoTechnically Typescript can't really be slow, since it's just a preprocessor for Javascript, and the speed of its programs will depend on which Javascript implementation you use. Typescript's sweet spot is making existing Javascript codebases more manageable. It can also be fine in I/O-heavy scenarios where Javascript's async model allows it to perform well despite not having the raw execution performance of lower-level languages.
- IshKebab 1y agoDepends what you mean by slow. The Typescript code was 3x slower than the Go code, and a 3x overhead is pretty much the best you can do for a dynamically typed language. Languages like Python and Ruby are much much slower than that (CPython is easily 10x slower than V8) and people don't seem to care.
- EMM_386 1y agoAt the risk of feeling silly for not knowing this ... why is TypeScript considered a programming language, and how can you make it "faster"? I have used its it came out so I do know what it is, but I have people ask if they should write their new program in TypeScript, thinking this is something they can write it in and then run it. My usage of it is limited to JavaScript, so I see it as adding a static typing layer to JavaScript, so that development is easier and more logical, and this typing information is stripped out when transpiled, resulting in pure JavaScript which is all the browser understands. The industry calls it a programming language, so I do too just because this is not some semantic battle I want to get into. But in my mind it's not. There's probably a word for what it is, I just can't think of it. Type system? And I don't understand a "10x speedup" on TypeScript, because it doesn't execute. I can understand language services for things like VS Code that handle the TypeScript types getting 10x faster, but not TypeScript itself. I assume that is what they are talking about in most cases. But if this logic isn't right, let me know.
- tgma 1y agoIn my experience, Go is one of the best LLM targets due to simplicity of the language (no complex reasoning in the type system or borrow checker), a high quality, unified, and language-integrated dependency ecosystem[1] for which source is available, and vast training data. [1]: Specifically, Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across time.
- weinzierl 1y agoAFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
- deleted 1y ago[deleted]
- tgma 1y agoNot that much different than a type checker in any language (arguably it is the same thing). I have been using various LLMs extensively with Rust. It's not just borrow checker. The dependencies are ever-changing too. Go and Python seem to be the RISC of LLM targets. Comparatively, the most problematic thing about generated Go code is the requirement of using every imported package and declared symbol.
- steveklabnik 1y agoThe borrow checker does not change behavior, so any correct program will be fine without borrow checking. The job of borrow checking is to reject programs only. mrustc also does not implement a borrow checker.
- KRAKRISMOTT 1y agoWell it certainly makes error handling easy. No need to reason about complex global exception handlers and non-linear control structures. If you see an error, return it as a value and eventually it will bubble up. If err != nil is verbose but it makes LLMs and type checkers happy.
- wiseowise 1y agoA tooling team selects language widely used in tooling circles - wild, shocking.
- lelanthran 1y ago> And a surprising level of speedup. Not surprising at all; I keep pointing out that the language benchmarking game is rarely, if at all, reflective of real-world usage. Any time you point out how slow JS is someone always jumps up with a link to some benchmark showing that it is only 2x slower than Go (or Java, or whatever). The benchmarks game, especially in GC'ed languages, are not at all indicative of real-world usage of the language. Real world usage (i.e. idiomatic usage) of language $FOO is substantially different from the code written for the benchmarks games.
- igouy 1y agoPerhaps "real-world usage" is "… rarely, if at all, reflective of [other] real-world usage …". Perhaps when you write "idiomatic usage" you mean un-optimized.
- dgb23 1y agoIt doesn't surprise me at all. Idiomatic Go leans on value types, simple loops and conditionals, gives you just enough tools to avoid unnecessary allocations, doesn't default to passing around pointers for everything, gives you more control over memory layout. JS runtimes have to do a lot of work in order to spit out efficient code. It also requires more specialized knowledge from programmers to write fast JS. I think esbuild and hugo are two programs that showcase this pretty well. Esbuild specifically made a splash in the JS world.
- kristianp 1y agoHere's the FAQs, where they explain the decision to go with Go and not, say, rust. https://github.com/microsoft/typescript-go/discussions/categories/faqs https://github.com/microsoft/typescript-go/discussions/categ... Hejlsberg also says in this video, about 3.3x performance is from going native and the other 2-3x is by using multithreading. https://www.youtube.com/watch?v=pNlq-EVld70&t=51s https://www.youtube.com/watch?v=pNlq-EVld70&t=51s
- bboygravity 1y agoCounterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.
- ctxc 1y agoThis is akin to saying if you rewrite it in Assembly it would be better than Rust. True, but what are the tradeoffs? Why doesn't everyone write it in assembly? It _would_ be bigger and eat more RAM and CPU. But that does not imply "shittier". There are parameters like dev time, skills available in the market, familiarity, the JS ecosystem etc that sometimes outweigh the disadvantage of being bigger/slower. You're pointing out the disadvantages in isolation which is not a balanced take.
- encom 1y agoAll those parameters mentioned are exclusively for developers. End users don't care and will get a worse product when you choose Electron instead of doing it properly.
- Sammi 1y agoEnd users care that they get a product at all. Which they won't if it's too costly to make. There is a balance that is appropriate for each project. Or else we should all be writing machine code by hand.
- pkolaczk 1y agoRust has been shown by Google to not be any less productive than other mainstream languages though.
- aaronblohowiak 1y agoLink? I’d love to learn more!
- szszrk 1y agoOK, but you phrase it like it's something bad, while you say it's very, very good in practice. But maybe for different reasons than language change. We should state: "this is true and really works, just remember language was likely only part of that". It's rather "embrace" instead of "beware".
- atoav 1y agoYes and no, Rust is suitable to solve a certain set of problems in a certain way. Or you could say: Rust brings certain qualities to the table that may or may not suit your project. A hacker blog I read regularly made a challenge about the fastest tokenizer in any language. I just had learned basic Rust and decided why the heck not. I spent 15 minutes with a naive/lazy approach and entered the result. It won second place, where the third place was a C implementation and the first place was highly optimized assembler. This is not nothing and if I had written this in my main language (python) I wouldn't even have made the top 10. So if you want a language where the result is comparably performant while giving you some confidence in how it is not behaving, Rust is a good choice. But that isn't the only metric. People understanding the language is also important and there other languages shine. Everything is about trade offs.
- s3p 1y agoI'm a little confused, why beware of this?
- deleted 1y ago[deleted]