Being tied to the code editor is the entire point, otherwise I would have just used GTKwave. Integrating it into the code editor - specifically VScode allows me to support terminal links (instance paths and timestamps from sim logs), first class remote SSH support (instead of having to use a laggy VNC session), and design hierarchy to RTL. Though you need a separate extension for that, because the waveform viewer is language agnostic and simulator agnostic by design. If you have ever used Verdi, it does design hierarchy to RTL, and I wanted to make a modern and open source version of that.
Surfer is fantastic, and the developers of Surfer are pretty great people too! It has been on my to-do list to learn Spade.
I'm working on a digital waveform viewer for VScode. I started it back when I used to work for an FPGA company, and needed to debug soft CPUs. Now it's starting to rival the proprietary software. I should probably do a show HN at some point...
Another point about HFT - They're mostly using FPGAs (some use custom silicon) which means that they have much tighter control over how DRAM is accessed and how the memory controller is configured. They could implement this in hardware if they really need to, but it wouldn't be at the OS level.
Yeah, I was a bit surprised that the author didn't mention that facet of Open AI. It did mention infrastructure goals, but the reality is that Open AI's infrastructure spending commitments have inflated the stock prices of quite a few hardware companies (like Micron and WD) and caused a strain on the market.
The real danger here is how over-leveraged Open AI is. No other AI player is as exposed. Their massive spending commitments are all precariously balanced on the other end by their user base, and if that evaporates, the whole thing will fall apart and that could crash the stocks of other players ...and by crash, I mean bring them down to a realistic value. But the economy is counting on this to work, which is why I believe that Open AI's strategy here really is to make the market exposed to Open AI's risks.
Crazy idea, but maybe change the rules of Show HN so that you are required to include in the headline how long you have been working on the project. As an example, something like:
Show HN: My Project - A description for my vibe coded project [3 weeks]
A lot of the good stuff I see on Show HN are projects that have been worked on for a long time. While I understand that vibe coding is newer trend, I also know that vibe coded projects are less likely to stand the test of time. With this, we don't have to worry about whether a project is AI assisted or not, nor do we ban it. Instead just incentivize longer term projects. If the developer lies about how long they worked on the project, they will get reported and downvoted into oblivion.
You have to understand the people in the article are execs from the chip EDA (Electronic Design Automation) industry. It's full of dinosaurs who have resisted innovation for the past 30 years. Of course they're going to be blowing hot air about how they're "embracing AI". It's a threat to their business model.
I'm a little biased though since I work in chip design and I maintain an open source EDA project.
I agree with their take for the most part, but it's really nothing insightful or different than what people have been saying for a while now.
Kind of a wild idea, but have you considered using this as a markup language for logic diagrams? I'm thinking something like mermaid - https://mermaid.js.org/ While this might not be super useful for chip design, it is a fully functional HDL, and since it is gate level, it would map nicely to diagrams.
> every mention in a package.json or requirements.txt
OK, what about those of us who aren't writing libraries?
As a personal anecdote, the amount of opportunities that have been opened up to me as a result of my open source project are worth way more than any $1 per mention or user.
As much as I love Zed, I am of the belief that VScode (and its derivatives) will remain the dominant build-your-own IDE for a really long time unless something like Zed can support web based extensions. I created a VScode extension for chip designers and I would love to port it to Zed, but I can't because it's a visualization extension with a custom webview.
I realize the irony here that Zed is fast because it's not web based, but I stand by my claim that being able to optionally display web UIs would be a really cool feature to have. It would open the door to a lot of extensions.
Dating apps are a Skinner Box by nature. They give randomized reward in the form of likes and matches. If you're attractive, you're the product because you don't need premium service to get more dates.
Give me Yelp for date spots and take a cut of the ad revenue. That way, there's at least an incentive to get people to not ghost each other long enough to actually meet up for a date. Hopefully that will do some level of incentivizing human connection.
Another one is custom CSS (though it doesn't look like positron does that.) You can change styling properties like spacing and weighting as well.
I have a love/hate relationship with the VScode webview panels, but the message handler is not my favorite implementation in the world. I would love a way to send binary data, and get semantic token colors.
The only issue is that when you have a custom build of VScode, you have to manage a fork of VScode, and potentially pull in updates as VScode updates. How do you manage that?
Unfortunately socketed processors only really work with DDRx type DRAM interfaces. GPUs use GDDR and HBM interfaces, which are not ideal for sockets. In the case of HBM, you have 1024 data traces per DRAM chip, which would make the socket have an insane number of pins. GDDR has fewer pins, but makes up for it with higher data rates (32 pins at 16Gb/s) and that is impractical to use in a socket due to the variance in contact area resulting in impedance matching issues.
Love to see this at the top of HN! I haven't written anything with this language yet, but I have met some of the developers of this language. They're pretty great and they are doing a lot of really good work in the open source hardware community. Another project they maintain is Surfer: https://surfer-project.org/
The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."
Not exactly. The name of the game with GDDR memory is "speed on the cheap." To do this, it uses a parallel bus with data rates pushed to the max. Not much headroom for things that could compromise signal integrity like socketed parts, or even board traces longer than they absolutely need to be. That's why the DRAM modules are close to the GPU and they're always soldered down.
Also, the latency with GDDR7 is pretty terrible. It uses PAM3 signaling with a cursed packet encoding scheme. At least they were nice enough to add in a static data scrambler this time around! The lack of RLL was kind of a pain in GDDR6.
As of recent, I have had this pet theory that there's a brilliance / stupidity spectrum, but if you go too far in one direction it loops back on itself. Some things are just so stupid that they're brilliant. I really like this!
Also, I should clarify that "brilliance" and "stupidity" in this theory are not raw intelligence, but the application of said intelligence.
Not malicious, but still selfish. It's important to remember that the copilot extensions are an extremely effective way of monetizing VScode. So it seems more like they're kind of compromising on their API usage rules in order to get to market quicker. But allowing themselves to use the APIs before anyone else is in a way anti-competitive, because the only way one could compete would be to use the unfinished APIs. But that requires users to go through more hoops to install your extension.
I should also mention that I am a VScode extension developer and I'm one of the weirdos that actually takes the time to read about API updates. They are putting in a lot of effort in developing language model APIs. So it's not like they're outright blocking others from their marketplace.
Don't forget that the power rating of a laser pointer (unlike literally every other type of light you buy) is the output power, not the input power! More importantly, it's the output power of only the green laser!
The 1064nm exciter laser is pumped by an 808nm pump laser, and based on what I know about how inefficient lasers are, I can guarantee that those beams are way more powerful than the output beam! If those leak because the manufacturer cheaped out on filters, those lasers mat not visible, but they are still dangerous!
> But owners sometimes complained that it was tricky to get their vehicles serviced or repaired, because there weren’t enough certified Fisker repairers and technicians
I would bet money that most of the "certification" process for technicians (aside from high voltage electrical safety, which is common to ALL EVs) is an NDA that grants access to unnecessarily proprietary diagnostic software. All this fancy talk about certification is just an excuse to charge consumers more for maintenance by adding an illusion of complexity.
This sort of crap is exactly why we need stronger Right to Repair protection. If a company [that sells consumer products] goes under, the specs, schematics, drawings, and source code, etc should go into the public domain. It can be the owners' job to parse through it all and figure out what to do about making/procuring replacement parts and finding mechanics to service the technology, but that data should at least be available.
As a hardware developer, I love seeing EDA tools getting YC's attention and resources. When hardware designers talk about how terrible EDA tools are though (myself included,) I find that it's a lot of the pot calling the kettle black. Most semiconductor companies have the most ancient IT infrastructure and tooling. Like at my current company, we're still using perforce. Instead of using SSH, my coworkers VNC into a server to run their terminals. A surprising number of them still use Notepad++!
Encouraging modern practices and enabling developers to migrate to newer development and development adjacent tools will be the huge value add with a product like this. At my company and some of the other companies I have worked for, we primarily use Synopsys for our tooling, but in reality, we use Cadence and Siemens tools occasionally. Being able to be more vendor agnostic, and tool agnostic, would be extremely useful. I noticed that you're using ventilator, but are there plans in the future to support other vendor tools?
Promoting the use of natively running apps (even if they're thin client web apps) is a huge win in my book too! VNC and VDIs are a terrible way to work. I really hate having to deal with the 40ms latency for every key and mouse event and font scaling that never works properly.
Another question I have, is about cost - I'm not a cloud billing guy, so I don't know the numbers off hand. But from my understanding, hardware development typically sees pretty high compute resource utilization, which is why I had always assumed that in-housing compute infrastructure made financial sense. Since it's on the cloud, how does it compare to on-prem computing from a cost perspective?
Surfer is fantastic, and the developers of Surfer are pretty great people too! It has been on my to-do list to learn Spade.