I only had to read the first few sentences of the first point to see that the author thinks problems are easy because they don't understand the difficulties.
Parsing C function prototypes doesn't give you enough information to write safe language bindings. For example if you see "char* make_stuff(const char* param);", you don't know whether the memory pointed to by 'param' can be reused after the function call, or whether the function actually took ownership of it. You don't even know how many bytes of memory 'param' has to point to, because you don't know whether 'param' points to a null-terminated string or something else. Likewise you don't know how many bytes of memory the returned pointer points to, you don't know whether the caller is responsible for freeing it, and if they are you don't know how to free it. You don't know whether it's safe to call this function concurrently from multiple threads. You don't know whether 'param' or the return value are allowed to be NULL or not. And this is nearly the simplest possible example!
My thoughts exactly. For somebody complaining that these tools don't exist because people are too lazy or whatever he himself is too lazy to do a quick google search to see that these tools do exist. I was using SWIG (http://www.swig.org/) 15+20 years ago to bind C/C++ to Perl and Java and it still exists. However your point above stands in that you have to annotate the headers with enough information about memory ownership to make it work.
The tone of the article also goes mad bigot when he starts whining about (AI) ( Aliens and immigrants ) taking our jobs for less money.
As someone who found an old I-94 in his wallet last week and spent a while as an alien, I try to be sympathetic to those sort of rants. It is genuinely frustrating when employers solve problems by finding a cheaper labour force instead of automating an unnecessary process or fixing the underlying technical issue.
A company I once worked for that will remain nameless paid an entire team of people in the Philippines to read global weather reports and respond to them instead of integrating with the relevant APIs, solely because it would have been a higher upfront cost to get expensive US-based engineers to do the work, and I found it infuriating: partly because the time of the two groups was valued so differently, but also because it was just so inelegant and pointless.
* I was using SWIG 15+20 years ago to bind C/C++ to Perl and Java and it still exists.*
(OK, who broke the * for italics markup?)
I've used it. It took the entire thing you want to call and generated one giant file of munged C. That's sort of where that idea takes you.
But the author is on to something. There's a C to Rust translator. It sucks, because it works by emulating C pointer arithmetic in unsafe Rust, using its own set of primitives along the lines of "offset this pointer by this much". Now you have ugly, unsafe Rust.
What's needed is something that infers the meaning of an ambiguous function call from the code. Something that reasons like this:
Function call:
int read(char* buf, size_t n)
Is "buf" an array, or a reference to one item?
Examine C code for "read". Is it ever used in an array context, like subscripting or pointer arithmetic? Possible results are "no, definitely not an array", "yes, definitely an array", and "can't decide, code is too confusing". One would like the third case to be rare.
If it's an array, how big is it? Possible results are inferred from the highest subscript seen, as an expression. Is it an expression on some variable at the interface? If it can be determined that the length of buf is n, the function call can be changed to a Rust slice for which .len() will work.
Pointer arithmetic needs to be analyzed by symbolic execution, treating each pointer as an (array, pointer into array) pair. If the array associated with a pointer never changes during the lifetime of the pointer, tracked all the way down the call tree, then the pointer can be represented as a subscript. Subarrays passed by pointer become slices.
This won't work all the time. Sometimes you'll need hints from the user. It would be tempting to guess using something like GPT-3, doing the conversion to safe code, and seeing if it worked. Most of these things are idioms, which is how humans convert them. Translation can be wrong in two ways - subscripts going out of range and being caught, and things using too much memory because a worst case overestimated something.
All the heavy work is in figuring out the equivalent, but not identical, data representation. Once that's figured out, converting the executable code is reasonably straightforward. There's already a dumb C to Rust translator for most of that.
I agree that static or dynamic analysis of the implementation or users of the API would let you do some interesting things here. But that is not easy and not the OP's point. The OP's point was that all you need to do is parse the prototypes and why hasn't anyone implemented that already.
> (OK, who broke the * for italics markup?)
You did by including a space after the asterisk ;)
The trailing one can have a space but the * leading* can't have one
I didnāt take the AI bit to be about ātik er jurbsā but rather about employersā attitude towards developers. That would be more in keeping with the theme of the overall rant.
All those difficulties are real, and yet, FFI exists and is useful. Of course it won't work in 100% cases, but it would work in many cases, because all those things that you describe aren't random - usually libraries have certain conventions on what the pointers mean, who frees them, etc. What the author is asking for is extending the basic service FFI provides to make it more useable and accessible. Still wouldn't solve 100% of causes, and still the questions like "is it thread safe" would never be part of it - so what? There are many use cases which can live without answering this question.
> I only had to read the first few sentences of the first point to see that the author thinks problems are easy because they don't understand the difficulties.
It's because you haven't read it till the end. He explains these things haven't been solved exactly because they are difficult and (he believes) unmonetizeable.
... and yet, Ada95 managed to include (as part of the standard for the language) the ability to bind to C, C++, Fortran and Cobol. All of which have absurdly different calling conventions and assumptions about memory.
I don't know anything about Ada95's FFI but it can't magically answer the questions I posed. Either it requires extra information not in the prototypes, or it makes assumptions about the C code that won't always be true (and will have catastrophic consequences when they're not true), or it gives up on safe binding and offloads responsibility for handling those issues to the programmer.
I actually really dislike this whole post. Thereās a really condescending tone lurking just beneath the surface for most of it. Itās also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I donāt care if he even has any good ideas because heās made me so mad just by his writing style.
I started with some interest in this post but stopped reading when the author started saying nasty stuff about Bezos's wife. How is she remotely connected to this post? Why try to shame her for her looks or cosmetic choices?
The author is trying to hard to be edgy without being humourous or having the depth of idea that could have saved this.
Author belongs to the special class of people who think sounding like a dick makes them more authoritative. All their posts are like that.
> class of people who think sounding like a dick makes them more authoritative
It's a writing style. Like it or hate it.
Nonetheless, criticisms of writing style are far too cheap and shallow for HN. Be better.
I disagree, I think it's a perfectly reasonable to critique someone's writing, and by extension the author.
You can't be rude and justify it by saying "it's just my management style" or "it's just my personality".
If the "writing style" consists of calling a random woman, one who has no connection to the topic at hand, cheap and nasty names - then it's better that such drivel is not even submitted on HN. We are better than this.
Contrarily I love this post. The first point I don't care about because I avoid C whenever possible but I agree with all the rest.
Electron is awful. So are phones. These things don't have to be so.
I don't find it whiney at all.
I do agree it's a little condescending, and that it's got a bit of a rambling flow; from semi-technical to straight bitching, all the way around to political.
And randomly insults Lauren SĆ”nchezās appearance; seems like a weird thing to throw into an article about software..
Gerald Sussman of SICP fame was asked why they stop teaching SICP and he said that the way programming was being done changed mid 90s. It moved from programming from first principles to programming against an API. This is still the reality of most.
You have to be big enough or brave enough to move back to reinventing the whole universe.
In theory, any large company could use projects like Oberon and "STEPS Toward The Reinvention of Programming" as an inspiration and create a full stack that runs GUIs on all platforms.
In practice this is a monumental undertaking that not even companies like Apple could do. They still reused BSD for macos and KHtml for Safari.
Apple could absolutely do it (or Microsoft, or Google, or Amazon) but thereās no justification for it from a business perspective.
Google sort of did it with Android and Apple with iOS and it worked out really well for them.
fuchsia seems like a solid attempt by goog to write a ground up os
What are the advantages/disadvantages of Zircon over seL4?
I've read up a bit on seL4, but can't seem to find the rationale or design decisions behind Zircon. Not sure why Google needs to roll their own microkernel when there is a fast, secure, formally verified one they could use.
> could use projects like Oberon and "STEPS Toward The Reinvention of Programming"
Like Dart, Flutter & Fuchsia?
I actually really like this whole post. Every time I think about quitting HN altogether a rare gem like this comes along. You should be able to have a little fun with common pain points we all have to deal with. The author has some pretty good suggestions as well. But I almost lost my drink with this one:
ā Imagine if the EC2 were as clean as, I dunno, z/OS, which has more or less been around since the 1960s. That would be pretty cool. I could read a single book instead of 100 books on all the myriad tools and services and frameworks offered by Oligarch Bezos. He would be hailed as a Jobs-like technical innovator if he had some of his slaves do this, and he would be remembered with gratitude, rather than as the sperdo who dumped his wife for sexorz with lip filler Cthulhu.ā
Comedy gold.
Part of what makes it funny is that if Bezos somehow got IBM to license z/OS to AWS to offer z/OS as a service on-demand, that it would likely be incredibly lucrative.
Feels like a list of stuff where he massively underestimates the complexity of the fields he's talking about.
Drag and drop UIs have, as he indentified, been tried. They were a leaky abstraction where incremental functionality was difficult to implement.
I think he means things like XCode's Interface Builder.
He's not massively underestimating the complexity as much as saying that huge swaths of that complexity are unnecessary, were it not for business requirements that often require us to do things the cheapest way possible (like hiring "fungible" web engineers to build an electron app instead of paying native platform engineers to build a first-class native app) -- and thus cause long-term harm.
I have lightly used both web UI stuff and native UI stuff, and on the desktop at least, web UI concepts are lightyears ahead. I think native UI development for PCs will return when and if the concepts there catch up with the present state of the abstractions and patterns that work for web dev. GTK, the one I know the best, is still in an era where object orientation is a new and technically difficult thing to achieve. Not bad at all, but we can do things so much more advanced than that if we port over the lessons learned when inventing ways to manipulate and efficiently push updates to the document object model.
There are some projects working on this but they are not yet at the level of "copy paste works," or "you can use either a retina or non-retina display and it won't look badly scaled or blurry on either." But I hope this will be sorted out soon because there is a lot of software I want to write with it.
No, Visual Basic worked fine. People built an entire generation of native business apps in it. Drop a bunch of labels, buttons and textboxes, wire the list view up to the database, and away you go.
The hard problem is native vs. cross platform.
So the answer is _Electron?_
I think way to many people massively underestimate the complexity they add to a problem when their solution involves Electron, React, and npmā¦
Iām less convinced than most commenters here that heās underestimating the difficulty of some of what he proposes, he ends with:
ā The reality is theyāre all quite possible, but nobody makes money doing them. Engineers are a defeated tribe; itās cheaper to hire an āAIā (Alien or Immigrant) slave to write the terraform or electron front end rather than paying clever engineers well enough to build themselves useful tooling to make them more productive and the world a better place. ā
Amidst his snark (which Iāll acknowledge will put some readers off) and some borderline probable racist dog whistling (which certainly put me off a bit), he is totally acknowledging that these ideas require smart engineers with budgets and mandates to spend the time making them come true. Heās not suggesting the 12 week boot camp front end engineers should be parsing c header files and inspecting deeper I to he c code to discover the stuff you need to use those to auto generate interfaces for other languages. But surely some of the senior AWS engineers should be spending their time investigation his ideas about ec2 and cloud and OSes?
I've never seen a web UI that couldn't be built, and built better, in an hour with an old school drag and drop gui builder. Unfortunately the web was built on markup, and markup is a terrible way to define a UI. There is really no way to make a good gui builder for html/css, so we are stuck with literally the worst possible way to build UIs today. CSS is 24 years old, and nobody has figured out a sane way to use it yet. We've gone from inline styles to "semantic" to BEM, and we've come full circle to what are basically inline styles (tailwind) and they all suck. Even html frames and tables were better than what we are using today. In many ways the history of building UIs in HTML is just people trying to find ways to mimic a frames/tables layout without using frames and tables.
There are a ton of effective drag and drop GUI builders for HTML/CSS: Webflow, Squarespace, Wix, and Plasmic to name a few, and that's just the current generation (see also: Dreamweaver et al.).
> Even html frames and tables were better than what we are using today
How? CSS and HTML can do practically everything frames could do (the only thing I can think of that doesn't apply is independent histories). There are a lot of different technologies at your disposal -- grid, which is probably the most intuitive; flex box; or just `position: fixed` divs.
Are those building a GUI? Or just a website? As far as I know theyāre mostly about markup.
The whole HTML-ization of GUIs is crazy... It's like "ok, let's make a language that represents semantics of documents and leaves most of the presentation to the tools, so we could concentrate on content and not focus too much on irrelevant details of presentation" - "ok, cool idea, now let's take this language and use it to build pixel-precision GUIs that have no semantic content at all". Ugh, talk about right too for the job!
Is a gui tool really faster or better then directly writing the code? It is like using a cli vs using a gui... propably a hybrid approach would be best...
> Engineers are a defeated tribe; itās cheaper to hire an āAIā (Alien or Immigrant) slave to write the terraform or electron front end rather than paying clever engineers well enough to build themselves useful tooling to make them more productive and the world a better place.
Offensive passage that subtly implies immigrants from the developing world are slavish (and dehumanising them as well, using the word alien), incapable of intelligence, and who're undercutting honest-to-god 'engineers', and preventing the world from becoming a better place.
I'm astonished that hordes of people are still ready to sell their first born if they can get a citizenship amid such a culture of passive racism and superiority complex.
There is no racism here, subtle or otherwise, and I say this as a black engineer watching this happen every single day. Engineers are not allowed to talk about how their jobs are being replaced by web development in every possible corner even where it doesnāt fit.
It is much cheaper to hire 5 offshore web devs for 5 weeks to force a solution into a web interface and then have an onshore dev spend 2 weeks turning web UI into an Electron app than it is to build any other type of solution.
He is simply stating the issue rather than not stating it.
> I'm astonished that hordes of people are still ready to sell their first born if they can get a citizenship amid such a culture of passive racism and superiority complex.
Can you imagine how bad it is where they come from?
No. He is just astonished. I am also astonished that a so called good manager will outsource a project to a "third world" country because he thinks this is cheaper and the poor guy in the third world country must reinvent the wheel and be "creative" because he is denied money (for equipment) and knowledge. ("just take this code and continue").
> have all the functions described in it turned into reasonably safe FFIed function calls
Many langs get close with the ease of importing C headers (Go, Rust, etc), but once you ask for reasonably safe FFI'd calls, you're asking a bit too much since ownership goes out the window. Otherwise, if you mean turned into acceptably-unsafe FFI'd function calls, agree just about every lang with C interfacing built in should have that.
> Itās fascinating to me that people find it easier to write a pile of React and HTML on top of electron rather than dragging and dropping native widgets for a framework like we did in the old days.
Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech. Once you see the difference in time to market, not to mention reduced maintenance cost, it'll be less fascinating.
Other than those points, I somewhat agree w/ the others, or rather don't strongly disagree (the condescending tone notwithstanding).
> Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech.
Two things on this: this was Java's promise (and Swing delivered on it for the desktop). And the expectations of a web app/electron app are still lower than those of a native app.
>Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms
oh, it has to run in a browser too so that users don't need to "install" it.
Can Qt help with this? I'm unaware of it's WASM support, but it seems like just a matter of time before they have all the GUI elements.
Many Electron apps are native on mobile. So we really mean on all 3 desktop platforms.
The answer is obviously Qt or Java. It works.
And many Electron apps are not native on mobile, just use a web view, and share many resources with their Electron cousins. Same with the web apps.
As someone who has written multiple Qt and Java GUI apps, it always seems fine at first until your UI needs become more unique (and you're subclassing QWidget/JComponent) and you have to jump through hoops to get something a web view has (e.g. streaming video).
I don't like the lack of native any more than the next guy, but I can understand sacrificing native benefits for cohesion/features. If you can tolerate a middleground of non-native but no-browser-bloat, Flutter or .Net Maui may mature enough to help for the complex uses.
Let's be honest, if you're making a webview for the mobile app it's going to be pretty different from the desktop Electron version. You're going to share many resources, yes, but there's going to be a lot of divergence.
Sure, writing your own UI components sucks, but it's not that much worse than writing a UI component for Electron. If you need to stream something from the web, QMediaPlayer works fairly well from my experience.
Also personally I consider Flutter to be native.
> Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech.
I think you've missed the point of the title.
I really dislike the article, here are some reasons (referencing the numbered arguments in the article).
1. There are many such parsers. Rusts bindgen [1] is one of them, I have written a proprietary one last year. This is pretty common to do for narrow use cases, there just isn't one for "Convert a C API to Ruby"..
2. "Most VM designs Iāve seen are basically just student exercises". Seriously? Create a better on and get rich then! I'm pretty sure Google would pay good money for something better than v8.
3. You can run z/OS on EC2. They do very different things. It's like saying I wish that cars were as simple as a strawberry.
4. "People used to make GUI frameworks which did more than electron apps, looked better and fit in the tens of kilobytes range." That's correct and that's why lots of apps are based on native UI frameworks. For some use cases, electron seems to hit a sweet spot (mostly not having to write UI for each platform and the web too). If you don't like electron apps, don't use them, most run in the browser too.
5. "Compilers and interpreters should learn how modern computers work." I don't know where to begin here. Modern compilers optimize for latest hardware all the time, one recent example out of thousand others is this [2] where V8 redundantly inserts short functions into memory regions close to the code they are called from in order to get more instruction cache hits.
[1] https://github.com/rust-lang/rust-bindgen
[2] https://www.techradar.com/news/google-chrome-is-now-dramatic...
Look, I agree that the article could've used a more productive tone but saying "just don't use Electron apps" is misguided.
We don't have a choice. IMO it's perfectly fine to be consistently unhappy on that point and to rant about it.
You can be perfectly unhappy, sure. My point was just to go a little deeper than just rant and talk about the economics of why companies choose electron in spite of all the disadvantages it comes with.
I agree on that but from my side the answer of "why use Electron?" is fairly obvious at this point. I could be wrong.
For a guy like myself it'd be more interesting to have the much more tricky discussion of "how can we not use Electron without spending millions on inventing a cross-platform native GUI toolkit?".
I recognize that's a personal preference, yep.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.