In general relying on excessive detail or jargon is symptomatic of not really understanding something when required to explain things in simple terms. I believe Richard Feynman said as much.
The general idea is people hide behind that detail/jargon precisely because they don't REALLY understand it enough to explain in simple terms what it is. That doesn't mean everything IS simple of course.
I assume you know now but in simple terms: the clutch connects the engine to the gearbox (transmission), so how well the clutch is engaged (connected) helps control speed. Gears multiply (increase or decrease) power from the engine depending on the gear you've selected.
> Gears multiply (increase or decrease) power from the engine depending on the gear you've selected.
Gears change how many times the wheels turn for every engine revolution.
Engine power is the product of angular velocity (rpm) and torque.
Gears are tangentially related to engine power output since they allow a user to select how fast the engine is spinning, but an engine outputs the same amount of power at a specific RPM regardless of what gear the transmission is in. 1800 RPM in 1st gear and 5th gear will generate the same amount of kW (or HP, if you prefer)
Understood, but in this (hypothetical) example his mother probably doesn't know exactly what angular velocity or torque are, so making things even simpler with a laymans "power" serves to get the point across.
One could include torque in the explanation to which the follow-up is probably "what's torque?".
The simpler one goes for that initial understanding, in most cases, the less technically correct one is; by design that helps the newbie learn and build up to a more technically correct understanding later on.
If I understand things correctly then my intuition for the answer to their mom's question would be gears wear out much less quickly than a clutch would if it were engaged all the time. Can anyone who knows more chime in?
Edit: ah wait no it's two multipliers isn't it, you're reducing overall power output when engaging the clutch?
Gears are multipliers. A clutch is basically two spinning plates - one on the gearbox/transmission, one on the engine.
When you press the clutch pedal in, it moves the plates apart so they don't touch.
When you let the pedal out, the plates move together, slip and rub for a bit, and then grab.
While they are all the way apart or all the way grabbed, they don't wear. While you are in between, they are rubbing and wearing, and trying to get the engine/transmission to spin the same speed.
> Gears multiply (increase or decrease) power from the engine
Ah, so when you want a lot of power - such as to tow something heavy - you'd want a high gear for high power, right?
But fuel consumption will be highest in 6th gear, because more power means more power consumption - I'll save money by using a lower gear, yes?
/s
Honestly I'm not sure how people who've never learned about gear ratios understand this stuff. Maybe a combination of "have you ever ridden a bike? It's like that" and "always pull away in first gear" and "when the engine makes a vreeeee sound change up, when it makes a wubwubwub sound change down."
I'll need to look into this but if anyone knows: is this available (easily) as a standalone package somewhere; think using the engine from a CLI without needing or contacting Google Sheets at all.
For 12 years visually vertically centreing text has required adding a padding or margin of a few pixels to the bottom or top, now (when adopted) it can be done properly.
Until recently I've been using Deno (mostly to avoid using Node and the tooling hell that entails) and it looks like for my use-cases Bun is getting there. I've had a pleasant experience using Bun as the basis of a test harness.
Here's my question (with a tiny bit of lead-in):
What I like about Deno is the integrated LSP (reducing tooling hell), are there any plans for Bun to feature this too? Bun already internally transpiles TypeScript which is great but having the LSP bundled too would give this single binary integrated experience a boon I feel.
Looking forward to Bun 1.0!
P.S. I'm starting to stretch my Zig muscles, you looking for Zig developers? ;)
I don't understand the hand-wringing about this. Bun explicitly says, they are a small team working very hard on some hard problems. If that's your idea of a good time, you're free to try and join. If you want a chiller job, there's 1,000 of them out there. It's not like Jarred is some corporate overlord demanding people slave for him while he sips margarita on a beach... he just wants people working on the same frequency as himself.
There's a school of thought on work life balance which amounts to wanting just enough life overhead to support the work. That 'balance' is not for everyone - but crucially it is what some people want.
>That 'balance' is not for everyone - but crucially it is what some people want
I've never seen anyone that could sustain an 80+ hour per week grind and make it out without severe personal issues (whether they are willing to acknowledge it or not). I've seen many, many incredibly talented people burn out and suffer permanent health or career damage to hit their short-term goals. I personally know an otherwise healthy 30 year old swe who had a stress related heart attack. It may be what some people want but you can't grind your way out of being a human.
But are they compensated or are we dealing with disguised wage theft[1]? A lot of times, when it's time to pay all that overtime or when someone finally speaks up about it, suddenly the "fun" stops.
Then there is the not speaking out, resulting in: 1) Burn out and quit. 2) Company dumps or fires them after burning them out. Then does the same to the new ones. Until something obvious or tragic stops them. 3) Quiet destruction of personal lives. Sometimes leading to significant health and/or mental problems, related to stress, and even suicide in some cases.
Balance is necessary, because otherwise it can be like playing with fire. It's all "fun and games", until people get or realized they got burned.
New product teams are a grind, but with the right people, also a lot of fun. It isn't for everyone. When I was hiring for a NPT working on cutting edge tech I told everyone I interviewed they the work life balance was super skewed.
The people who accepted job offers self selected for having a passion for pushing technology forward.
I tried to keep things as sane as I could, but I'd have to go in on weekends and usher people out of the office.
For some people, building cutting edge things is /fun/.
You can pretty much use tsserver with bun-types and get most if not all the features you get from deno-lsp. I know because we provide both deno-lsp and tsserver for windmill.dev to provide intellisense over websocket/jsonrpc for our monaco webide at windmill.dev and it works great :)
Fines should be at least 100% of _revenue_ from these activities to actually punish the business. At the very least 100% of _profit_ from the activity. Anything less is cost of doing business since it's by definition a net profit.
This is the most disgusting thing I have ever read. My blood is boiling to the point where I genuinely don't see a bright future.
Ben Wiser (Google), Borbala Benko (Google), Philipp Pfeiffenberger (Google), and Sergey Kataev (Google) have got to be the most repugnant people on the planet for pretending this is anything but a scheme to destroy all privacy and freedom on the web all so fucking Google can sell more ads.
Willing to relocate: Yes: U.K (I'm a citizen), South Korea, Japan, Germany, Singapore, France, The Netherlands, U.S., or within Australia if it makes sense.
Technologies: {Java,Type}Script, Ruby (on Rails), Node/Deno, React, SolidJS, AWS, Azure, .NET, C#, F#, some C and Zig, POSIX Shell/Bash, some Python, Terraform, Ansible, SaltStack.
I do DevOps and Software Engineering (particularly full-stack web but increasingly more systems programming). I will happily learn new technologies and enjoy learning in general as well as partaking in challenging environments where application of knowledge and skills solves problems.
The changes should be the main meat of most commit messages and if the intent or other options considered add value to that then they should be included below.
The reality is if the intent, other options, relevant notes etc are not valuable then they will be lost to time (no loss). If they are valuable where else are you going to put them? Some wiki or knowledge store for your project? How will you know that this specific commit and that (probably) sparse text in said knowledge store are related? Why not just put them together where they belong anyway.
Commit messages are not valuable when they are maximally short. They are valuable when they describe the changes the commit applies and ANY other relevant information for people (including the author(s)) in the future so that said people can understand the commits effect and other relevant information.
For an example of amazing commit messages look at PostgreSQL’s. They are sometimes long with the changes, notes, intent etc and sometimes short.
There's also Boon which I like quite a lot but I opted against using mostly because of all the places I would need to type where I wouldn't have access to Boon unless I ported it (a plan I assure you but one lumped behind 1,000 other projects TODO).
Addressing just the capture: I don't see the problem with `||` at all, in-fact I think it's elegant. I do like (most of) Ruby's syntax so that's probably where my fondness of this comes from but I am not a veteran or seasoned Ruby expert by any means.
The general idea is people hide behind that detail/jargon precisely because they don't REALLY understand it enough to explain in simple terms what it is. That doesn't mean everything IS simple of course.
I assume you know now but in simple terms: the clutch connects the engine to the gearbox (transmission), so how well the clutch is engaged (connected) helps control speed. Gears multiply (increase or decrease) power from the engine depending on the gear you've selected.