seeekr

To me it seems like it's depicting a situation where the string hasn't been pulled fully, so some of its slack hasn't straightened out into the otherwise resulting triangle yet.

Is that true? It seems that our eyes are mechanically capable of looking in divergent directions, what's the reason that we're not able to "uncross" them beyond looking straight ahead? (Edit: Anecdotally I can confirm for myself that I'm not able to do it, so wondering if there's anyone that can.)

probably a riff on "das Auto" (Volkswagen ad)

To save others the click: Their issues were simply that Swift has no fast JSON impl, and in Rust, when using serde (most popular library handling JSON marshalling), it leads to binaries getting a bunch bigger. That's it. So yeah, same perspective -- unless either of the above matter in your case (in 90%+ of cases they don't), JSON is just fine from a perf perspective.

super cool, and if this works you'll bring a big part of what we dreamed of as "the future" into the present!

Not true, not sure why GP said that. Been writing Rust for many years and code does not just break on compiler upgrades. Super stable overall, including the wonderfully evolving ecosystem!

They just changed the assignments of what tapping the right stalk once vs twice does -- before, once brought you into cruise control and twice into autopilot. After the change, that order is reversed by default, but you can change that from the settings.

I think at some point the absurdity of the numbers (now it's 2M, soon it'll be 10M, 50M, ...) will become so great that NHTSA will stop calling this a "recall", and then this term will no longer be usable for clickbait article titles. Absurdity because it'll get harder and harder to imagine how a company might bring in millions and millions of vehicles in for service repeatedly, from a logistics and cost perspective, and still be able to grow and make a good profit.

cheeky one: "Cabin Noise during Acceleration with Ludicrous Enabled" (https://service.tesla.com/docs/Public/om_media/plaid_reactio...) :D

You're not alone, I do that too sometimes! But I've also found that most people have a hard time doing or following along with something like that. Possibly because in the end it does require a whole lot of skill in using git, because you will usually want to rewrite history in some ways, and large numbers of developers are very uncomfortable with that.

minor nitpick: "e.V." in Germany is "eingetragener Verein", "registered association" and is a form of association that's extremely common and use for all kinds of things, e.g. local sports groups, interest groups, etc, so "e.V." in and of itself doesn't have anything to do with industry, though as in the above case it can be used that way!

In this context "TC" probably means "Total Compensation", and "TC 0" meaning "currently not earning anything at all".

Have been using Moom for ages, and still sticking with it for now! Works well!

Location: Europe, close to Vienna

Remote: Yes, preferred

Willing to relocate: probably not, open to being on-site as needed

Technologies: current focus mostly Rust, Elixir/Phoenix, JS, Svelte, GraphQL, but have done + am open to many others (Java, PHP, C#, C, ...)

Résumé/CV: N/A (not maintaining any such thing)

Email: denis, plus the usual thingy, and ends with productioneer.io

I'm patient, curious, I like thinking + planning. I like understanding systems and problems. I like running things in production. I like making things efficient. I really like inspiring + supporting others. I love coaching, mentoring, guiding humans.

I aspire to be the best engineer I can be. And the best human being, too. I believe in kindness, imagination, communication & co-creation.

  Location: Vienna
  Remote: Yes
  Willing to relocate: No
  Technologies: Rust, JS/TS, Elixir
  Résumé/CV: https://www.linkedin.com/in/denisandrejew/ | https://www.upwork.com/freelancers/denisandrejew
  Email: denis /at/ productioneer /dot/ io

How does something like this happen? Shopify should be absolutely on top of its game here, seeing as user experience seems to be one of their main priorities?

Nowadays it's not that hard to get UX/DX right if you are actually committed to it.

Rust is amazing for CLIs (Go potentially as well, too little experience with that personally!), but if you're already quite comfortable with JS & have existing investment in it for CLI or related code, then ´npx <tool> ...` while asking the user to install Node (or Bun) is an acceptable tradeoff in most cases. Updating via npm is also easy enough for users, though it's not self-updating of course, but basically no CLI will do that fully automatically for you. Not even Cloud SDK CLIs. And for good reason.

I don't disagree that it's not the best of comparisons (and I wonder if a better one could be imagined + implemented...). But still, it's not like we turn on Autopilot/FSD only "on empty highways", far from it! Certainly it's a tool where the user needs to learn its strengths and weaknesses and use it accordingly, but it is useful in so many more situations than not, that it's also not a terrible or meaningless comparison to make!

Anecdata: Almost all (95%?) of my highway driving (Europe) is on Autopilot. I don't even enjoy doing the driving myself any more in those situations where I know that Autopilot is doing a pretty good job. In particular, Autopilot does a better job than I can in conditions of heavy snow / rain / otherwise poor visibility conditions. I feel a lot safer being the operator than the driver in those instances! (The alternative would often be to slow down by a significant amount, and/or use up more of my focus/attention, leading to either less safe driving or forced breaks.)

This looks like a blog post, but it's actually a writeup by a user/customer (aka case study or similar). Would recommend putting that into the post header somewhere, so as not to confuse readers who didn't navigate there by hand.

I'm confused by the fact that there's no mention of interaction with the Hyper project's authors. I'm fairly certain that Sean & contributors will want to address the underlying issue, if they haven't already done so (clearly they were describing the potential for misusing the Hyper API very directly in the docs!), and pointing that out and clearly stating when and how that has been or will be addressed would shine a much more positive light on everyone, including the security researchers.

I see that there's an 1.0 RC release and the offending API seems to have changed and is probably not amenable to this type of misuse any more. The article authors could have easily added some info about that -- I certainly would have appreciated not having to go looking for that myself.

Thank you for posting this. Really resonates.

I'm passionate about building the best (technology-based) products I can imagine, using all of the tools I've learned in my life so far, to the max, mainly intuition ("gut" over "brain", perhaps) (love making amazing decisions that hold for a really long time!) and imagination. Steve Jobs and Elon are probably the two biggest inspirations, and so are the respective companies they've built.

At the same time I'm also passionate about being kind, being myself as fully as I know, keep growing and enhancing that. I'd love to get the chance to build these things fully into new companies I imagine creating.

I'm also way into "woo-woo" (some might call it, especially on tech-/regular science-focused sites like HN) stuff like channeling. And all kinds of personal expansion-related things that are less "out there" but still quite on the edge, like conscious sexuality as a tool for human growth and blossoming, exploring the meaning and use of emotions, even and especially also in professional & business contexts, etc...

Basically I want to be as fully what I see as a fully human being as I can, and practice and bring that into what I want to accomplish in tech, create environments for others to explore the same, if they wish. Current companies and orgs are boring and outdated in many ways, and I have a desire to build and offer something new, that's much more aligned with who we really are.

I'd also be super eager to connect with folks raising their children in new and better ways. I still believe, as I did before I had kids, that "it takes a village to raise a child". So far I haven't found that village, or (most of) the people who would make up that village. I'd so love to start meeting those! (Kids are <= 10yo, we're living a somewhat nomadic life, between Austria, Germany, Croatia, Canary Islands, ... and I used to have a strong calling to come to California as well, which has been coming back recently to some degree...).

No idea who might read this and resonate, but there it is. Thanks again for posting, made me feel a little connected at least :) I usually only read 99.99% of the time on here, but this got me out of my shell for a few minutes at least :) Very much agree, current internet needs a lot more of this particular vibe that we used to have back in the day, e.g. with actual old-fashioned forums inhabited by basically only those folks who really cared about some topic or idea that then realllly connected with each other!

I just want to note that it seems incorrect to call this a superficial resemblance in terms of syntax. I went and read through the whole thing, and the syntax for the type hints seems to be as close to 100% TypeScript as possible, which is to say, it is very close. There may be some features missing that TS supports, but the bulk of it is there, and what's there is basically Typescript, which is the best thing that could possibly be accomplished here.

Typescript has been doing a fantastic job, and this proposal is continuing in that same vein, truly absorbing as much of that as possible back into JS!

Kudos to everyone involved, great effort!

And re "[the type hints] do nothing": The section at the end of the proposal clearly explains why that must necessarily be the case: Evolutions of JS must not break the web (especially) for the users.

Quoting: "TypeScript's model -- which has been highly successful for JS developers -- is around non-local, best-effort checks. (...) Additionally, defining a type system to run directly in the browser means that improved type analyses would become breaking changes for the users of JavaScript applications, rather than for developers. This would violate goals around web compatibility (i.e. "don't break the web"), so type system innovation would become near-impossible. Allowing other type systems to analyze code separately provides developers with choice, innovation, and freedom for developers to opt-out of checking at any time."

So this proposal provides the best possible path forward for JS, based on what folks are voting for with their feet by using TS: Making JS compatible with TS-style type hints that can be used by external tools (i.e. not the JS engines executing the code at runtime) to validate the code in a best-effort manner while the developer is looking at it, while not changing JS runtime semantics and thus never breaking the code while the user is running it.

Note that this seems to be a relatively old project, first commits from 2015. The project seems active, but most of the work seems to have been done around its inception, with some significant activity from 2020 onwards. Speculation/interpretation: So this might be a project that was used internally by some company, but perhaps not any more, and they've decided to open-source it at some point (2017-2018?) because some folks were/are still excited about it and want to keep developing it.

This might explain some of the "why yet another RocksDB-based KV store?" line of questioning.

They just keep building on top of the things they've already built that are working really well, expanding into related services. Doesn't seem that different from what AWS is doing, just with a different focus and in a different place in everyone's (or the Internet's) stack.

I was expecting a horrible mess when I clicked through to TFA, after having read comments like yours, but then... I actually enjoyed what I found there. Maybe it's because I'm quite interested in C++'s ongoing modernization story, even though it's unlikely to ever catch up to Rust (and others) in terms of safety?

Last update on Twitter:

"While I don't think it's ideal to need a huge social media push to get things accomplished, thanks to the momentum this thread has generated it seems like we've got a path forward with Tesla towards getting this taken care of the right way."

Tesla is a big company by now. Probably a lot more people working there in Service Centers than in the core manufacturing & engineering. Hard to get everything right. Lots of room for improvement for sure. Rooting for Tesla to work these things out over time! (Disclaimer: Owner + shareholder, both out of conviction.)

Snowpack is no longer maintained, and the people previously working on it are now developing an SSG tool based on Vite. Source: https://vitejs.dev/guide/comparisons.html#snowpack

While the title of the video is clickbaity, it's entirely accurate, and it's a message worth spreading. Hope YT will reconsider, acknowledge their mistake and fix it as best they can. Good luck, Ann!

I am assuming the authors made a good faith attempt at comparing apples to apples. In another comment thread on here, there is one of the authors answering questions, about fsync, durability etc: https://news.ycombinator.com/item?id=31543212

Their paper (https://www.usenix.org/system/files/atc20-conway.pdf) reports a 6-10x speedup on insertions and 2x lower write amplification as compared to RocksDB, on fast NVMe hardware, for certain benchmarks. The authors found that RocksDB (and other storage engines) start being bottlenecked by CPU and have come up with some ways of tackling those bottlenecks, including a novel data structure named STB-tree. The current SplinterDB version has a list of acknowledged significant limitations and is not recommended for production use by the authors (yet).