4 ms·

I really like how javascript tooling appears to have followed the make it work -> make it good -> make it fast pattern, which is pretty much always the correct

I really like how javascript tooling appears to have followed the make it work -> make it good -> make it fast pattern, which is pretty much always the correct way to build software. It is reassuring that we have actually got the feature sets and interfaces correct, since we are now, at last, turning to making stuff really fast. If we had started with speed being the goal of tools, I'd wager they would have been nowhere near the standard they are today in those regards.

jakequade 5y ago
I like how you've followed the delusional -> delusional pattern.
c7DJTLrn 5y ago
>make it good Wait, when did that happen?
- layer8 5y ago
  Even "make it work" is debatable.
- te_chris 5y ago
  This got a genuine laugh from me. Stockholm syndrome is a prerequisite for writing JS
- Already__Taken 5y ago
  to be fair they didn't say it has completed the progression through that program.
- zeroxfe 5y ago
  I'd say when ES6 landed. I used to hate JS, but since ES6, I think it's a pretty good language for building frontends.
  - LordDragonfang 5y ago
    ES6 is indeed pretty good, all things considered, but GP specified javascript tooling, which, uh, could still use some work before it's considered truly "good".
- spartanatreyu 5y ago
  I'd say ES5 made it work and ES6+ made it good. I think by the time the Pattern Matching, and Record & Tuple proposals are completed and implemented it'll go to fast.
verdagon 5y ago
I've discovered a similar pattern, when I look at successful projects in my past. I prioritize "working", then "solid", then "fast" where it's needed. Ironically, it's this principle that makes me look to non-Rust languages; I find that Rust's borrow checker forces us into faster but less flexible patterns up-front, and incurs a lot of refactoring friction later. It's because of this that I'm interested in the PL space, and excited about upcoming languages like Lobster and Cone.
- fee1-dead 5y ago
  That's just.. not how Rust works. I assume that after being frustrated by the Rust borrow checker, you chose to use easy to write wrappers like `Arc` and `RefCell`. I think it is something that beginners often do. I wouldn't rewrite my project to some other language before I know how it is going to look like in the language. I had to be somewhat confident. If you find yourself frustrated by Rust's borrow checker, that tells me that you are not yet ready to port a project to Rust. You don't have the "Rust mindset" yet.
  - verdagon 5y ago
    You make a lot of assumptions, and dismiss my valid opinion as uninformed. I would say that's arrogant and offensive, but I'm sure you meant well. More to the point, in my many years of experience with Rust, I've found that if you're working on a stateless project, or a small project, or have a very clear picture up-front, you can know what data you will need to centralize and split ahead of time, and things will go smoothly. However, that's rarely the case in the parts of industry I've been in, where we need to prototype, refactor, and build out our programs constantly. In these cases, Rust is slower to work with compared to other languages, because the borrow checker makes our APIs brittle, causing refactors' blast radius to increase. I'd be curious to hear if your architecture experience with large Rust projects might be different, I'm always open to more data points.

jakequade 5y ago

I like how you've followed the delusional -> delusional pattern.

c7DJTLrn 5y ago

>make it good Wait, when did that happen?

layer8 5y ago
Even "make it work" is debatable.
te_chris 5y ago
This got a genuine laugh from me. Stockholm syndrome is a prerequisite for writing JS
Already__Taken 5y ago
to be fair they didn't say it has completed the progression through that program.
zeroxfe 5y ago
I'd say when ES6 landed. I used to hate JS, but since ES6, I think it's a pretty good language for building frontends.
- LordDragonfang 5y ago
  ES6 is indeed pretty good, all things considered, but GP specified javascript tooling, which, uh, could still use some work before it's considered truly "good".
spartanatreyu 5y ago
I'd say ES5 made it work and ES6+ made it good. I think by the time the Pattern Matching, and Record & Tuple proposals are completed and implemented it'll go to fast.

verdagon 5y ago

I've discovered a similar pattern, when I look at successful projects in my past. I prioritize "working", then "solid", then "fast" where it's needed. Ironically, it's this principle that makes me look to non-Rust languages; I find that Rust's borrow checker forces us into faster but less flexible patterns up-front, and incurs a lot of refactoring friction later. It's because of this that I'm interested in the PL space, and excited about upcoming languages like Lobster and Cone.

fee1-dead 5y ago
That's just.. not how Rust works. I assume that after being frustrated by the Rust borrow checker, you chose to use easy to write wrappers like `Arc` and `RefCell`. I think it is something that beginners often do. I wouldn't rewrite my project to some other language before I know how it is going to look like in the language. I had to be somewhat confident. If you find yourself frustrated by Rust's borrow checker, that tells me that you are not yet ready to port a project to Rust. You don't have the "Rust mindset" yet.
- verdagon 5y ago
  You make a lot of assumptions, and dismiss my valid opinion as uninformed. I would say that's arrogant and offensive, but I'm sure you meant well. More to the point, in my many years of experience with Rust, I've found that if you're working on a stateless project, or a small project, or have a very clear picture up-front, you can know what data you will need to centralize and split ahead of time, and things will go smoothly. However, that's rarely the case in the parts of industry I've been in, where we need to prototype, refactor, and build out our programs constantly. In these cases, Rust is slower to work with compared to other languages, because the borrow checker makes our APIs brittle, causing refactors' blast radius to increase. I'd be curious to hear if your architecture experience with large Rust projects might be different, I'm always open to more data points.