Wow this is pretty cool! I'm gonna give a try.
For me, this is actually what most of my slack usage is. Just writing notes to myself and then occasionally messaging others.
What is the memory-safe subset of Java? Java is memory safe by definition. Sadly, the definition might not give people what they want, which is bug-free code.
High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)
Grew up on C++ and the paradigm (& loved it), but then moved to interpreted for use cases.
I think the uncoolness of them is due to OOP methodology... programmers today seem to want to be easier to get moving, but then spend more time debugging OR the debugging has been "placed onto" DevOps / use of Cheap fast hardware. IMHO
I'd say just try it out and see how you feel. If you feel defeated and discouraged, then that's the end of it :) However, if you feel motivated to get better results, then you'll find the info you want easily (esp. how to solve the problem[s] that tripped you up)
IPSC ( https://ipsc.ksp.sk/ ) used to be my favorite until they stopped organizing it :'( - but you can still play with the problems and see how you would rank :)
I would advise against reading a bunch of materials first before you do your first contest -- a lot of those stuff are niche and probably doesn't feel different from leetcode grinding, so only do as much as you feel motivated to read and practice.
I've read this and it gives a pretty good overview of the history as well as current events surrounding the semiconductor industry. I think it gives a good high-level overview so you'll have the foundation to dig deeper.
I don't think that this book by itself would be enough to understand the semiconductor business, but it's a great place to start to get acclimated.
And it's not just needing to buy the ASML machine. There's a ton of proprietary knowhow to actually get it integrated into a fab so that yields are reasonable.
Agreed. IMO, it all started with Hooks. Things really went downhill from there.
useEffect is terrible! Example, how easy it to forget the dependency array?! Because of that, you have to setup linting rules to fix the poor API provided by that hook...
I think this is an artifact of HN's voting system. Most readers probably don't have enough karma to even downvote. For the ones that do, guideline discourage downvoting for comments that you disagree with.
And I can see why the majority of HN readers would upvote the top level comment. Particularly since it's a popular re-hashed opinion.
Top comments aren't a good survey of the opinions of a specific community for that reason.
As someone who used to use React and now has to grapple with an in-house web framework: hooks are right on the money and offer tools
backing some of the best devex in web right now.
I've been using React and writing it professionally since early days before they even supported using ES6 classes. I have also answered questions for years on one of Reacts largest discord communities.
Hooks were nice when they came out, but woefully under-documented. The fact that decent docs for hooks first development came out literally just this year when hooks have been out for years is kind of a shame.
As opposed to useEffect, most other hooks are fairly straightforward, but the fact it years of articles upon articles of mistakes and documentation to explain useEffect to both experienced and non-experienced devs alike shows that it really wasn't that great of an API for end users.
In fact the most common topic nowadays is how much you need to avoid useEffect, especially if you're not a library developer. None of this was documented/mentioned when it first came out.
Yes it does enable powerful workflows, but plenty of other frameworks/libraries handle the same thing in a nice way with much less drawbacks than react. (ex: automatic dependency tracking, etc)
The number of times I have to tell people to stop putting things in effects at all, or that the reason something isn't working is a stale callback due to missing dependencies in my opinion shows that its not really a good API for the average dev to be using.
Your last paragraph rang so true. Webpack will tell you that you are missing a dependency and ask you to include it or remove it. I feel useEffect is a fine api. It’s not the apis fault if I shot myself in the foot with it.
> There is zero functionality that has been removed from class-based components.
No, but the React ecosystem has almost collectively migrated away from class-based components or deprecated support for them.
> Devs use hooks primarily because hooks are better.
You avoid much of the dependency array issues by using class components. But you have to deal with `this` and it's significantly more keystrokes. It's more of a tradeoff in my opinion.
I don't see where you said that. It sounded to me like you were insinuating that hooks are inherently better than class components, and that zero functionality has been removed from class components, they are still viable (but they have largely been left in the dust by most popular libraries).
Also, devs don't use hooks primarily because they are better. They use them because they are idiomatic React in 2023.
It is not akin to saying that. Please argue in good faith [1]. Writing idiomatic React code makes a lot of practical sense (easier-to-find examples e.g. in the docs, wider library support, onboarding newbies). You can choose to use hooks while acknowledging the tradeoffs from class components.
I'm 49 and started with the Commodore 64, and function based components with hooks are so much cleaner than the old class based components, it's unbelievable.
The classes had closely related functionality spread out over several different methods making them hard to understand at a glance, function based components are very concise.
I think people who dislike hooks tend to overuse useEffect (it's rarely needed) and to do too much inside components rather than inside custom hooks.
For what it's worth, that's not at all my experience on the teams I've worked with. I was around when hooks were released and it was an immediate and significant improvement to our team at the time.
My experiences with jQuery are literally the exact reason why I like React.
I strongly suspect most HNers who are overly critical of React (and/or general web framework complexity) have never had to write and then maintain a large web application in jQuery.
JQuery is just a hammer. Its not a framework. It does provide utilities like selectors, events, triggers, dom manipulation etc. React is a component based framework. It contains pages, routes, state management, caching etc.
You cannot compare those two.
In a way jQuery is low level just above vanilla. Wheras react has a minimum of 500 execution layers. Thats why its slow and painful in many cases.
To be pedantic, React is a library, and doesn't provide page abstractions, routes, or state management outside useState and useReducer. It also doesn't have very strong opinions about how you structure your application (what a framework does). That's what Next.js is for.
In my experience, a lot of people don’t actually know how to use hooks correctly and find them frustrating as a result. It depends on what you’re used to, but I find that class based components leave too much room for scattered logic. Let’s not also forget those who abused `shouldComponentUpdate`.
Every other framework not only has its own implementation of hooks, but notably: every one of them is faster, smarter, easier to write, or a combination of all three.
I agree that useEffect is bad.
But there are other SPA frameworks that do things better. In fact, just about any other framework does things better.
Vue3/composition API -- probably the simplest if you're coming from React. Definitely feels like it was inspired by hooks.
Svelte/store -- svelte has a term called 'hook' but it's unrelated. The equivalent would be Svelte's store.
The other frameworks use something called 'Signals' (Preact, Qwik, Solid, Elm and even Angular/backbone though I don't personally have in depth knowledge of all of these).
IMO, I would prefer Svelte if you are adventurous, or Vue if you like React but just want something like 'better React'.
I mean, Svelte/store is something completely different though, isn't it? it's more akin to Jotai/Zustand/Redux and friends than it is to hooks. If you had to compare Svelte with React, the thing "closest" (while stretching that word very much) to hooks would be the `$` reactivity things Svelte does? Because if you want a state management solution, react has that as well (many, in fact). Just not built in, and a lot of them work really well
Effects are not required to be idempotent, so it's not just an optimisation. React documentation has an example where the effect establishes a network connection. Even if there's time to connect between renders, the remote system doesn't necessarily handle such short-lived connections.
This isn’t quite true. If your effect depends on state, that state must be included as a dependency.
This is easy to miss, so you install an eslint plugin to warn you about missing dependencies.
This causes the opposite problem - adding dependencies unnecessarily to silence the warning. Then you need to ensure those dependencies are stable to avoid running the hook on every render. Or ignore the warning with a comment, and you’re back to square one.
It’s all too easy to write an effect that either doesn’t run when it should, or runs when it shouldn’t. This is especially true for inexperienced developers.
