oscargrouch

His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications. I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that. The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity.

Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).

Not if you take one of the biggest selling points of Electron.

Im working on something not quite the same thing but that deal with all this, and being able to ship with a web rendering engine and not using whatever its on the system is actually better giving all the power, bindings, compromise you can make that you are unable when you can only deal with a abstract wrapper to every web rendering engine out there.

Lower memory footprint but with much less features and a generic "no sir, cant do such a thing.." as a answer to users that will need important features to ship applications with this.

From the server side perspective, this Actor implementation is cheap(to develop), safe and more developer friendly.

But i don't know if it will be the most performant implementation as it will depends of how much state copy between threads its involved (as this is the common bottleneck in performance on a multi-threaded implementation).

So a more classic implementation might perform a little better, but i don't know if this will also stand true in Swift as the compiler might use tricks behind the curtains to optimize things giving the people behind this also control the Swift compiler.

Optimized for multi-core safety in a safe way, but given the safety of the actor idiom may incur in more copies, it cant be compared to the speed of a implementation that are more complicated to implement, but will perform better at the end giving you can customize better for that particular scenario.

With C++ and Rust you will be able to implement this in a more optimized way as you can look for approaches that avoid copies which can be the main factor of a slow implementation, specially in multi-threaded scenarios.

Its not all the windows libraries, but often the OS creates just one interface library to wrap the syscalls. Those do not tend to be big libraries where you should worry about being statically linked to your program.

The problem with Linux also have to do with license, giving GPL can get some program into trouble by statically linking GPL code.

There are 3 cases for me that can force one to use shared libraries: Licensing, Dynamic loading a DSO at runtime (like in Apache modules) and when you are developing a big project, but once you need to ship the production code, get it back to statically linking everything.

Other from that i don't see why you would want this.

While phone apps fall into the app store trap, browser are also falling into the cloud trap.

Its not enough to run applications on the browser, you need to fix some of the things that make browsers weak giving we need to let go all the information to cloud providers who will then monetize on it somehow.

Years ago i've put myself into this path to build something that could help a little bit on this. I hope this can cover some ground as the future looks bad for everyone else who is not part of the big tech paradise, as outside of it, everything is being sucked by a big straw and dying a long, slow and painful death..

For me there's a sweet spot that is meant for languages like Java, C# and now Swift. For me at least Swift is the natural successor of this family of language for a bunch of reasons.

I would'nt create a program in C++ or Rust if i can do it in Swift, because its much more pleasant, productive and safer (while i love the level of control and speed C++ and Rust gives you).

I would just go for C++ or Rust if the domain i'm solving require this. Even because for some problem domains there are very few languages you can use. And i'm glad that now we have more options on this space like Rust and Zig.

But for business kind of languages, applications with common business logic, for me at least there's nothing better than Swift.

Script languages can be even better at ergonomics and productivity, but they tend to have a price that its only perceived later in regards to efficiency and the lack of a proper type system.

On the server side unfortunately, Swift is too late to the party and Go is already eating the Java cake. But i see a tremendous potential in Swift for user facing applications.

I also like the Ken Thompson extensions from which part of Go was inspired by

    struct X { int a; }
    struct Y { *X; int b; int c;}

    void add(Y* self, int number) {
      self->a += number;
    }

    Y y;
    y.a = 10; // composition
    y.add(1) // y.a = 11 now

This alone would simplify C coding so much without taking any power out of it.

The other extension i would add is some sort of interface or protocol.

As soon as you can do something like "y.add(1)", having a generic contract to refer to things without having to know its concrete type is some of the good things from the OOP world.

With this you would also be able to call some cleanup code and even a initializer.

This is still C and its still much simpler than C++, and yet almost as powerful.

C should propose these kind of things even if it was not that conservative and it would retain a lot of coders that migrate instead giving C barely evolved from its 70's roots.

In most languages you can have more than one result or pack multiple values in a struct like object and that would simply solve this problem. Another way would be to return just the status code, knowing if it failed or succeeded and passing a closure to be called when the operations finish, either with 'ok' or 'failure' signal and the possible result.

Ok, we can do all of this now, but in this vision, you would have some sort of Ohad Rodeh btree, which would track all the states (it basically needs to be some sort of GC and handle all the state allocations).

With this btree you would be able to create branches of the whole universe of states in a memory cheap way. Once theres a possible state change a new branch is created, and once consolidated(not just one, but it might change many states of the tree) it would be passed as the "front state".

If a side-effect prevented the change in state from occurring nothing would happen as the original state would keep the same.

I know this sounds trouble and that we kind of have the tools for this, but i've noticed that we have a "fractured state" problem where we end up doing much more work that it would be not actually needed if we managed to pack it all in a ubiquitous initial signal that would get 'sliced' into other signals with transforms, but would be consolidated into one again.

Rendering got that right, with a back buffer with a bunch of intervening state that is flipped as front once its all set. If things are breaking in the back buffer, just try it again or fail the whole state tree all at once, keeping the last good state intact.

We already do this manually in code, but we manage a lot of fractured states giving we don't have the bird-eye view perspective.

If you had something managing it all, looking at diffs, etc, my intuition(maybe wrong) says that it would make a more efficient and stable program, more performant, with more memory efficiency and easier to reason about from the developer perspective.

I think your perspective have all to do with experience. My younger self used to see new languages as magic wands, secret recipes that would make my code lead me to new things and discoveries.

Now my modern self understand how naive i was, and that actually man-years, algorithms, experience and resilience are super important, all that of course with a good sense of opportunity and also luck to make the right thing on the proper time (nor before or after).

Reading codebases of others, with pearls collected over the years of how to do well some things in particular fields gives you a bigger perspective that as long you are able to choose the right tool for the job, the quality and excelence of the final product will depend much more of this experience than of the programming language chosen.

The ecosystem around the language also matters a lot. For instance other languages might be more suitable or performant than Go in cloud, distributed and server computing. But the fact that you will have a great ecosystem giving the language community will make new projects more likely to succeed even if other languages might be better in performance or memory footprint for instance.

The most upvoted comment in this section for instance is in denial and trying to validade the hype. Because theres nothing more comforting than feel good emotionally about something, and the people that also have gone through this and know what you are experiencing, that warns you about it, are perceived as enemies. Because you are breaking this "feels good" cycle, so you must be the enemy right?

(But the thing gets me a little scared about is that the last hypes have been much more ferocious, reminding a lot religious cults dividing people between the ones that believe and the ones that does not)

I'm not a language researcher/expert but real life code is full of colaterals and side effects, specially having to deal with things like network the expectation that f(x) will always resolve to a valid answer without resorting to result being of another sort even if normalized to the expected type (eg, you are doing a simple integer calculation and define that the negative numbers will be used as error codes to deal with side-effects).

I wonder whats the state-of-the-art approach from the FP community and if there's no really good answers, just patches like exceptions are, if in fact is the expectation and the classic assumptions of FP that are actually sort of broken?

I know i'm tripping here, but wonder if we managed to program in a "multidimensional-state paradigm", where you could call a "multidimensional f(x)" where in one dimension of the state it will always be a valid reply, and the side effects would be another f(x) that would solve the side-effects in parallel, but both functions would be intrinsically bounded to each other like in the schrodinger's cat experiment.

(Edit: to be clear here, is about the language itself to automate this, instead of expecting us to manually handling this or resorting to band-aids like exceptions which just forget about the state it was handling before. Its akin to state auto lifetime management as GC's, ref-counts, etc do, instead of expecting us to manually release the state as in a call to C's free())

I think capitalism will find its way over organic forms of financing things, even complex and expensive ones. We will go through this crysis phase where the old ways dont work anymore, and the old pals with their expensive lawyers and lobbies will harass and squeeze everybody in their way.

We already have forms of doing this right now of course, but the old, centralized, man-in-the-middle-who-steal-all-the-value, pyramidal, egotistical way are still coexisting with the new ways.

What needs to die is a way of life that is in the end burning and eating all of our planet resources like there's no tomorrow.

The internet revolution is here to stay and it can change our way of life for the better or for the worse, if we just let them impose their monopoly in a insane global level. If this happens instead, it will be pretty hard to get out of it as this new class of rulers will have power never seen before.

I think WASM used in this way will turn out to be the "new flash".

People coding into this sort of platform will ask for the whole language std, which in turn will have to be compiled to WASM, which will make massive blobs. And this is exactly what GWT was about, only that it was more sane giving it was compiled to Javascript.

Sure, some specialized applications (probably the ones that use C/C++ unique libraries like MMPEG) might benefit from it, but if we are complaining about modern Javascript libraries sizes now, i guess this will make us miss the good ol' days.

I hope browsers don't fall for this and keep WASM blobs working on the background as modules and accelerators as they should.

I'm not an expert in USA culture, but looking from a distance it looks to me that this is cartesianism (as in pattern-matching) applied to social sciences, which as it turns out, is a legacy of the 19th century which lead to it's most extremist version represented in fascism.

I say this because here we have this too, as in any other part in the world, the only difference is that the targets are others.

Remember the obsession of those folks to measure and document people turning this into some sort of science where you could classify people objectively giving some properties drawing hard lines that would not be crossed. Once they defined what was the superior type it would be a matter of marginalize and eliminate the weaker to achieve the super race.

We all still do this here and there, but is much more organic, subtle and disguised as something else.

Anyway is funny to think that in US (and Brazil), the last wave of immigrants arriving were considered the low people and only with subsequent waves of immigrants the old "dirty ones" got some sort of social upgrade.

As irish in the US were marginalized and later the jews, polish and italians replace them as people with less value.

Here for instance, japaneses and italians were treated pretty badly in the beginning of the 20th century. (It was even worse for black people).

Its funny to see how people don't learn with history. There's no nobility by birth, at most it was the parents passing education and culture to their children. Leave a human alone in the forest and if he manage to survive it will behave like an animal.

Ok, but even if there's more Rust code in it, i think the expectations of the parent poster are unreal, as for safety, only if V8 VM were rewritten in Rust, and giving its a JIT VM sensitive portions of code would need to be in 'unsafe{}' anyway, so how much safer would it turn out to be even than?

Anyway in security terms it will probably turn out negligible as the percentage of code in safe Rust are probably low compared to the whole thing.

Than in memory usage, if it replicates Eletron,it would turned out almost the same, giving is not the C++ core the one that is most memory hungry.. is mostly the renderer process with WebKit and V8 executing big portions of javascript code in memory.

Giving if such a branch existed, it would use typescript which in turn is the same V8/javascript pipeline that is memory hungry.

So, addressing to the parent poster, i don't think it would change much in terms of security or memory pressure if compared to Electron.

Sometimes i think Rust give some people high expectations, that it would be very hard to actually replicate in real life experiences, giving software is much more complex and as in Deno, requires other core parts that cannot be realistically rewritten in Rust, and even if they could, while we can see how software written in Rust can be safer, it still needs to prove the claim for bigger, sensitive pieces of software that requires a lot of "unsafe" techniques to work like JIT's and OS's and therefore might not feel that much of a difference giving the size and complexity of the project.

The big problem of this use for me is that people from the US tend to think in terms of "race". Like if there is a homogeneous "latino race" where it boils down to the average mexican immigrant that the US is more used to.

For instance, you can see this in north-american films, where the mexicans are hired to play Brazilians, where we (brazilians) can spot right-away they dont look like any type of average looking brazilian. But im pretty sure it make sense for the crew of the film and people watching it, even when they speak spanish.

Just to give you a glimpse of famous brazilians north-americans may know: Rodrigo Santoro, Morena Bacarin, Alice Braga, Gisele Bundchen, Alessandra Ambrosio, Jordana Brewster, Camilla Belle, Kaya Scodelario, Wagner Moura.

The thing is, i've just give you this sample, so you can see how they don't have any resemblance between each other or homogeneous look. The ones that speak perfect english can perfectly act in roles not meant for "latinos" and nobody notice it.

I think nowadays is right to use this term in the same sense as you use for Europe to define France or Italy as part of Europe. Albeit is even wrong to use in the sense of a continent giving America is just one continent, with north and south.

Anyway if you dig down and look to all the inconsistencies of the term it boils down to some sort of racial profiling thing, because it makes no sense in any other way you look at it except for labeling it as "not white".

Latin-derived language speaker here (Portuguese). Also by studying other languages it turns out that English is quite good at expressing simple and composable symbols and structure.

While i would choose a latin-derived language to write poetry, speech or a novel because the expressivity, at least in those contexts are unparalleled, for clean, honest and even scientific terms, if there's a need for a human language, the english language, at least for me, is what suit those the best.

Apart from that its also a question of chance and historical events.. This sort of tool is great to teach younger kids to program and thinking in programming terms. But just like math, its reduced to a more symbolic level, so the word you are using to define things its not that relevant and giving that property, its a good thing that its more universal, just like in math.

Where you were in 2012?

Dart was heavily marketed as a Javascript successor by Google, this was even before ES5 changes, so Javascript was a even weaker language in terms of design, giving people were doing more and more full applications in the language.

The problem is, Javascript did a catch-up, and the Typescript technique of compiling to Javascript made it more appealing as a successor, not mentioning the design of the language (I know that Dart had this too, but having its own JIT it were more appealing in terms of speed back then).

Meanwhile Google abandoned the project that would allow the Dart VM and bindings to WebKit to coexist with V8. And now that only the Dart-to-JS path could be followed to develop for the Web, Typescript championed this path as it was the only way for them from the beggining.

So if you were following those events, you would know what sort of race i was talking about.

I agree with you that "Dart is doing fine", but is only doing so because of Flutter. As in, people learn Dart to target Flutter, not the other way around.

Im not implying that Dart is a bad language, or technology, because thats not true. Its only a problem of adoption, and it will have a hard time outside of the Flutter bubble.

If it were not for Flutter, Dart would continue is path to a slow death, not because its a bad language or technology, but because of how the events turned out to be, and a little bad luck.

Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript).

Somehow Typescript convinced people from the Javascript side of the fence that they could mix both and eventually upgrade from it. While Dart also tried the same feat, it failed doing so.

Nowadays Dart is only being considered to anything because the team behind it are top-notch and implemented themselves a platform where Dart could be the king.

Giving their talent they were able to create a great platform, where they would made even more success if they used Javascript or Typescript as a development language. But giving they wanted to save all their years of work on Dart, and giving its not a bad technology per-se, it just had a adoption problem, Dart lives on Flutter.

If you want to use Flutter go for Dart, but picking Dart to anything outside Flutter will just alienate the developer crowd as giving even Typescript is some sort of a niche language in terms of adoption, nevermind forcing people to learn Dart.

> Does it have potential as a safer, lightweight Electron alternative? Or are there better options than Deno in that regard?

If they target this, the big chunk of code will still be the same ones on Electron, so i don't think it would get to be safer or lightweight as compared to Electron.

> Deno glue code around V8 is written in Rust.

The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust.

Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing?

Because by not having direct access to the V8 api in its native language might limit you, the "glue coder", in the things you really can do.

Maybe a dual-company like Mozilla would at least make it more clear that the big guy that are just taking advantage of the free lunch is doing more harm than good?

Elastic should have a for-profit and a non-profit company taking donations that would actually control the open source code and hiring the core part of team working on it.

I mean, we know how badly Amazon is behaving here, but at least they should have a option where they could realistically invest.

Asking for a company to invest in a competitor that can grow and eat their lunch with the money being invested by them is not realistic. Even because the company investing the money would want to know if that money is actually being invested back in the open source software and not used by a competing company.

If, giving this choice, they didn't invest back in the foundation, it would be much more clear that they are doing it in bad faith.

Its the same reason any tweet by Elon Musk saying stupid stuff get 300k likes instantly.. Its about who say and not about what is being said.

If you don't hack your mind from a philosophical perspective you wont stop this tribal hard-coded neural trigger of this automatic authority following.

This is the only thing that can save us from being that person in the 30's Germany photos raising their hands and chanting 'Sieg Heil'.

Remember that this is hardwired, but it worked somehow because we used to be packed in small communities where everyone knew each other.

Now the same "wiring" is being used the same way, but now with a virtual global tribe, where we actually don't really know the people that is being granted authority or why we are supposed to follow them, because we simply follow them giving everybody is also doing it.

Just observe yourself more often and question even the things you take for granted before doing it. You will see a lot of these things are actually unreasonable giving their actual context.

> Sadly, for the fledgeling enterprise that was Android, it was better to start from Linux, and use Apache/BSD style licensing and write their own userland.

Curious about your take on this. Why do you think it would be better if Android were mach kernel + BSD userland akin to Mac/IOS instead of Linux?

Im working on something that also have the goal to give the power back to the user in terms of control, but i've also understand it the same way you do.

That in the end the platform have to provide a better experience to the end user and also give more power/flexibility to the developer, otherwise no one will use it.

That's the reason i think it requires a lot more work to make this feasible. Only "iterational innovation" wont do it.

I hope that what i'm almost about to launch here, might reach those goals.

If you can create a binary that links with a C api, its possible.

The access to DOM apis are going over the C, so its just a matter of wrapping all up in the target language.

Im using the Chrome multi-process architecture, but instead of a renderer process what gets called is a application executable that binds to Webkit and acts as the renderer process do to Chrome now.

So this gives the application much more control over the client rendering, hooking over every event WebKit triggers, something that is not even possible with Javascript now. So its much more powerful.

You also have a "service" process which runs as a service, that is actually the one that receive every request and can launch the application process or do something else.

The requests are over GRPC, so the service process serve not only the UI requests for routes but also the RPC method calls to the API it defined according to what the app does. The API for both are in Swift, but the core runtime and system is on C++ and in a multi-process architecture, so any native app that can compile into a standalone binary and interface with a C api can also use the facilities.

The applications and resource distributions are over torrent so anyone can serve the application without any intermediaries or shipping on servers.

If a app want to talk to the cloud, its just a matter of doing so when processing the routes or the RPC method calls, but it can work offline or eventually online/offline given its design.

I've heard Kotlin can produce standalone binaries, so that means its possible (and no WebASM shenanigans with direct access to Webkit and with the real native boost)

Unfortunately i cannot ship with another SDK right now because i'm doing too much already, but i intend to create interfaces for other languages once things are more stable, and people understand better what is it's place in the game.

But is more a application and window manager as Chrome is more-less and less as Electron or Flutter, where it wraps a standalone app.

With this design together with the RPC api's exposed by each application, you end forming a local network of apps, where they can work with each-other. And with the Api's working as a social contract, you can replace the application to serve the same things without losing everything (effectively real data ownership)

But my goal is that you can just call "./pacman" and the thing pops, even being managed by a core process as in chrome. The user dont need to deal or know anything about it.

I'm doing something that while not the same thing, it let you control the web infrastructure with native languages. The first SDK is in Swift.

But im sure that with enough work a Rust Sdk could be created as most of the core functionality is exposed as a C interface.

The product i'm finishing is more of a answer to the question of if there's something between the browsers and mobile application platforms that could also work in a more distributed fashion.

Its nice to have absolute control of the rendering going over canvas if you are a flutter platform developer and i think even playing the catch-up game they should get there eventually.

But i don't think this is the real issue here.. Flutter is more of a Flash and GWT lineage, and that's fine if that's what you are looking for.

But i bet on the Web every time, its the most popular UI (and now much more) platform ever. So while some will go through the Flutter and React way of doing things, most will just stick with the web.

The web is the most sophisticated platform ever built. It gives you a lot of power and freedom, so i don't understand why some prefer to get stuck into a cubicle when you have so much space?

Its nice to have frameworks to make things easy and developers more productive, but the ones that do this without alienating the developer from the bigger, broad and sophisticated framework are just better.

Just let them be the new Flash, now at least open and over the web, and look for other approaches if you want to maintain real control and freedom, instead of delegating to the platform developers.

Sorry to say that, but this is 'ur-fascism' at its best.

The difference here is that the nazi's pre-condemned anyone who were of a give ethnic background(jews) or believe (communists).

Unlike them, you are praying that the society condemn over prejudice, people based on their past behavior, placing a star on their chest and denying them basic rights, which may start with "innocent" rights like these being taken from them.

You can only punish people when a considered criminal activity occurs, never assuming someone have ill intentions over their past behavior and therefore should be denied the rights of whatever is being negotiated.

Don't forget either that with such laws and ethical triggers in place governments, companies and individuals might just game the system and threat someone by forcing him into prison for bogus reason destroying his life even after he is free. (And how can we call this dystopian reality freedom?)

BTW The Sunde prison is exactly this case, but there are even more proeminent cases as Assange or Snowden.

Your are talking only about ICANN here of course, but the core of the issue you are defending here will inevitable lead to the consequences i'm exposing above.

I hope i can share something here more on this line pretty soon. Its not just databases and blobs over torrent but a whole web based application platform based on chrome for native applications. The SDK will start with Swift but the C interface can be used by other languages.