oscargrouch

> Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any software written in any language could be extended with code written in Rust.

Ok, but you kind of added complexity to your codebase. Now you will need not only C++ coders, but also Rust coders. If you are Mozilla or Google you can do that, you eat complexity for breakfast.. But they are probably not the companies you need right now to keep your steady growth, unless of course you are lucky that they created some killer app in Rust because of their in-house use of it. Like Google did recently with Kubernetes, only it is in Go of course, but i guess it checks the square of a killer app which helps into the language adoption as a programming trend.

Speaking of Go, it once was suffering from the same problem Rust is going through right now. It was sucessful in a first phase because of its community, but it needed more to start having more adoption and mind share. Then, Docker happened, and Go found a sweet spot to aim for and take it to the second base.

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end.

C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and you can even see this reasoning being used as a reason why they created Go).

Then Go showed up with simplicity and a good story in performance and memory, deploying simple binaries in a world of complex server infrastructure paved out by Java was a very handy and right on time approach.

The problem with Rust now, is that it is target the system programming, in a era of system programming renaissance given the whole mobile app scenery.

The problem is; there is already a lot of C++, C, Java, Objective C and Swift code there, so it will be hard to have a good reason to rewrite complex stuff with a lot of man hours in it in Rust.

Every language needs a platform. C is here because of Unix, C++ because of Unix, games and early 2000 and 90's era startups. Java and C# because of bussiness software, Go because of the cloud, Ruby and PHP; because of webservers, Rails an blogs, Python for educational purposes, Data Science, ML and now AI.

Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable.

Its really tough, and if Rust dont find a platform to grow it will be very hard to advance any further. But, there's always new tech waves and tools that will marry perfectly with them.

Lets see which languages are able to be a perfect fit for them in years to come. But right now Rust will depend a lot of the community it already formed to keep sharp and maybe be lucky to surf one of those waves.

Maybe if you turn that url into a hash, than just use the hash to check if the package has a local copy already, it wont be so bad. But you will need to add the package version in the URL so that you know you will always have the package you really want in your local cache.

No, because of the sendfile syscall, where the kernel pass all the file data without switching back to userspace.

Even if you can in theory save some time with small files with sqlite, you would be back to read/write IO and userspace/kernel byte buffer switching.

And it probably wouldn't be faster than something like a mmaped file anyway (unless the SQLite Db is also mmaped).

> They’re not cheap sketchy products, you keep mischaracterising electron apps so that you have a point.

I still have a point even if/when the electron based ones have more quality or are better from the consumer point of view, because my point was not about the final quality of the finished product, but about scale and economics. Im not saying that every electron app will be inferior, this is illogical and unsustainable..

Rather im arguing that the whole model that the Electron represents will flood our desktops and even phone with cheap, memory hog apps, even when some of than are great, collectively they will be a nightmare to our computers. Users will blame the OS, or they will figure it out when they close the Electron apps, seeing their computers working better (And i guess when they get to this they will blame the company that created the product, and the bad word might start to spread).

Even with all the computational power we have now, we will have a even worse user experience than we had in the 90's with very limited computers compared to nowadays.

> Let the market decide. If the native apps are superior, then customers will choose them more often and companies will feel the pressure to use them.

My point being in the end, you wont have any options, and in some cases great products might vanish.

Im very critical of all things Apple, but this is one of the things i think Steve Jobs got right, and no wonder Mac OS and now iPhone worked out as a shield for great products that would not survive in the "worse is better" environment of Windows and the Web.

They are also great, accessible, popular, etc.. But if they were the only game in town a lot of great products would not have survived and others would not have been created. Thats what i fear about if the Electron trend gets too much hyped.. We will move fast and break a lot of great things in between.

If it gets popular, but not the monopolistic kind of popular, then its great, and good that its there as an option. But in tech we use to jump from hype to hype. (And you also can see what im trying to elucidate here by following whats happening in the NoSQL vs SQL database front)

> Except that they don’t need to consume 1gb+ and they don’t need to feel sluggish.

The problem is that is built around V8 tied up to Node.js, so i cant see how it will get any better giving V8 is a state-of-the-art VM already very optimized and using little resources as possible. Also you are tied to blink/webkit which together with V8 will consume a good chunk of memory and you as a dev will be unable to optimize further, giving you can use anything other than JS and blink.

> We’re also not talking about replacing every native app with electron.

Of course not. But the problem here is the trend. Companies will see how cheap it is to just reuse cheaper human resources being used to the company web dev, and how fast you can prototype an app.

The other companies who create better products because they care more, will have a hard time competing with the cheap sketchy software that cost less to build, and the worse products will likely win.

Its "the worse is better" all over again.

Take a look at the apps you are executing now.

Now imagine if they were all electron based and therefore consuming 1GB+ each?

Also we need to take into account that it feels slugish and they are not as responsive as other apps, and i guess it has to do with JS VM reaching the tipping point of what it can do and optmize..

Anyway, my main point is that the big problem will happen when you stack those things.. than a computer that should be more than enough, just isn't.

Even the user with low tech awareness, will close the app and feel his computer is working better.. and they will blame the company who makes the app for making their computers feel slugish in the end.

I know its off-topic, but this remind me about some things, now that Firefox is taking the heat and losing more and more market share..

First about that famous Joel Spolsky post warning about software rewrites using Netscape as an example. Then the fact that Firefox have waited too much to create a multi-process browser which was really a needed rewrite to really catch up to Chrome.

If my memory doesnt fail me, Chrome was launched in 2008 and Firefox came up with the multi-process only 4 years later, in the end of 2012.

And then theres this rewrite of core pieces in Rust, that i'm sure was great for Rust language and community growth, but i dont think it was a good move for Firefox, because it take a lot of effort to stabilize the core pieces, specially while at the same time refactoring a compiler in the middle.

Rust turned out great, with a great performance, but what if it didn't?

Or maybe i'm being a half empty glass kind of person, and Firefox were actually turning out to the same faith, and at least a good tech, Rust came out of all this mess?

We need to remember MS bought Github recently, and with that Electron. Electron is based on Chrome so..

It makes total sense for them to concentrate the effort in Chromium and Blink, and just reuse it as their default Windows browser.

I think this is much more about Electron than it is about Edge.

LMDB is a key-value database. The Euclides DB build on top of a existing key-value database, LevelDB (could be LMDB) as the persistent layer.

Im not familiar with EuclidesDB, but from what i've understand from the documented architecture it uses gRPC to expose a RPC interface over the internet, and abstract away the objects in the domain of machine learning (like images) tied to PyTorch.

Anyway, its a higher level concept and architecture modeled on top of a key-value storage like LMDB, which is a lower level building block for this product. LMDB being comparable to LevelDB, not EuclidesDB.

(It looks that the author is here, so please correct me if im mistaken in any way)

For me, its basically to add support for metadata in REST, by using things like JSON-LD to describe the layout of data and be competitive with what GraphQL is offering.

Of course there are a common definition for data and metadata, trying to define a common standard.

It's funny how in the end this will end into reinvent a thing like protobuf, but in JSON, much more verbose, and that can't be read by a human anyway.

GraphQL at least do all this while being human-friendly and allowing to define whats needed 'by hand' or by a machine. (But i also dont think this is a great thing to use if the communication is internal and M2M anyway, but its a great solution to serve some api to a bigger crowd of heterogeneous clients)

I used to be pessimistic about it too. I think it will happen in a proper way in some places, in others it will be used as a tool to amass more power, as the human nature implies it will.

But the silver lining is that we are creating a collective conciousness through tools like the internet. Humans can naturally create this collective sentient being when forming a tribe for instance. Our problem, in our particular point of history of civilization, was always the problem of scale.

Now with the internet we are again able to form this collective mind in a bigger scale. We are still in the infancy of this process, and thats why this collective is acting as a dumb giant. But I think that as we evolve in this process, this collective mind will get more sophisticated. And soon we will be able to collectivelly control whats best for the greater good, trying to repel all hostile movements that could try to control the resources to the benefit of a few.

The problem is: it will take a lot of fight to get there, some of us will fall, but i believe that some of us will get there first.

My guess is that they will make this explicit in SIL first, to be able to add that into the language syntax later.

For instance, as far as i know, the auto ref-counting model is on SIL, who injects lower level refcounting ops into the intermediate code, before going through the LLVM pipeline.

This was a good thing to do, now that they are willing to open the ownership model to other kinds of ownership. Which will probably be controlled by the dev in the end.

At least, that's what i understood from what i read. Its SIL only for now, but it means what is it implying it means. A opt-in manually controlled ownership model when ref-counting is not the best approach.

The most something follows the most intuitive way of making one thing, less arbitrarity and change for change itself, it might also be only noise, so the author can claim its a original work just because it uses a different sort of symbols. Byproduct of individuality and ego.

Most people can detect noise and arbitrarity. But if you are making something really original, giving you are being a pioneer into something, in that case you can define the direction of something, where that direction should serve as a guide to things that will follow.

I dont know about others, but my brain tend to be anti-noise (and i fell this pattern in a lot of other people too), because theres too much information for us to consume, that having to handle some people "cheating" to give a apparent originality, can make anyone who feel its the "noisy arbritrary sort of change" that is being presented, to dislike the "noise" almost immediatly.

Technology should be aiming toward zen-budism, less ego and therefore, less disonesty and less noise.

You make a excelent point. People in power positions trying to take advantage of näive.

The recipe here, is that you create a untrue image of a "Emerald City", where everything is possible for the people that work hard, show them the great Wizard of Oz as a example of what you can acomplish, and wait the dreamers like Dorothy to pile over in order to fulfill their dreams. You will have hard-working, starry-eyed workers accepting almost anything.

Sure, the Big Corp™ also use a gaming system to its own advantage, making a feist from the naive.

It's ok to be skeptic when in your environment they actually swallow the dreamer type. We always need to be smart, detect what's really going on and adapt to the environment.

Sometimes you just wasnt lucky to find a good fit for you. But whatever happened its good to survive not only the outside world, but to fight for your inner fire. The thing that will make you move on with a sense of purpose. But of course you shouldnt let people take advantage of that, and a lot of people will actually try, not only professionally.

> However others are only fluent and comfortable in that one legacy technology and are not really experienced in the fundamentals. A surprising number of those people exist. That’s who we want to avoid.

'The Prince' has a whole chapter about wheter employing mercenary soldiers can be considered a good thing. And he gets into the conclusion that mercenaries must be the last kind of resource you want to employ in an army, and that is better to avoid them.

To stitch this with what we are talking about here, in my experience, people that get stuck in a given technology are more conservative types, who do just enough to fit in a given position, and make it as solid as possible, so to garantee their paychecks by the end of the month, and to be perceived as a perfect fit for that position, and consolidate the job for years to come. Its on-pair with mercenary because, theres no cause or love for the tecnology, for what we can achieve with it, but those values get corrupted when they clash with a solid and continuous source of income.

More inovative people are more bold, and take more risks, but a lot of companies wont like them, and they wont be perceived as a good fit for the company (in their speech of course they do, but not in real life).

I guess the first, is more of the profile you are saying you are trying to avoid. And i think thats good, because this profile tend to have a more parasitic relationship with the company. If your company moves faster, maybe they wont make a good fit in that sort of environment.

Also its good to avoid people that have a tendency to game things. There a lot of people in this world, that dont care much about anything else and just do enough to understand the game of a given system and score enough to win in that sort of game consolidating its own position. (For instance, that puzzle based hiring interview iss being gamed right now, and companies are not hiring what they think they do right now.. humans will adapt to the games til they mean nothing anymore)

A good fit for a Astronaut for instance, is that kid that was dreaming about the space, and will do everything to make this dream come true. When theres a real problem, or something that requires real passion to be done, that 'kid' will make the difference.

Nothing can work as a suplementary replacement for real passion.

(From someone that has real passion, and cant understand how people can live without it)

Its funny. Im creating a multi-os application platform based on Chrome runtime, and thats how im packaging my multi-target binaries.

Im using a SQLite btree file as backend, working basically as a key-value store. On the header i define what target triples are supported (the ones the dev built the binaries), and on the runtime open, see if the current host is supported and unpack the bynary payload always checking the hash before running it. (If its on the filesystem already see of the hash matches with the one saved before on the DB as a record)

Giving its a db the owner of the public-key signature(the creator of the file), can modify and add others binaries latter.

Im not disclosing it now, because its just part of a bigger platform, and you dont distribute only the apps, but a whole "container"(not in a Docker sense, but as a multiplatform container more focused on final users instead of cloud backends).

I hope i can launch it soon here on HN.

> For the love of God just use SQLite if you want an embedded database for structured data, even if it's just eav. If you just need key/value there are battle-tested, well maintained options.

You can also use the SQLite Disk Btree as a key-value data store. I've just implemented a solution that does so in C++ with a LevelDB-like api.

You should use the backend Btree api (the same the VDBE/SQL engine uses to store stuff) and create 'tables' the SQLite uses for indexes. The integer-key based is used for ordinary SQL table .. (1 PK = 1 Record) and the blob-key type, where its agnostic about whats on the key. (Thats the one you use to create the KV store)

There are a couple of details, to make it right, but its not that hard, and its a great solution.

> From our POV, the more people trying to accomplish these things, the better

Sure, im totally ok with this vision, given this is how people create new things, even if it looks 'solved' in a given context.

> As developers and humans, we want these things to exist!

The more iteration, the better.. we definitely need more polished tools in this space.

> LSP (https://microsoft.github.io/language-server-protocol/) is a better fit

Oh thanks, thats kind of the context i was looking for.. in what problem domain you guys were pointing to.

It makes perfect sense giving the current goals of Sourcegraph, to create a more complete solution to the dev community it targets.

(I didnt wanted to sound the "Dont reinvent the wheel" kind of guy here, just curious about what you were trying to acomplish, and used Kythe as a reference to the problem domain)

If someone is curious as i was, here's a little bit more context:

Github Repo - https://github.com/pallene-lang/pallene

More about the language - https://github.com/pallene-lang/pallene/blob/master/doc/manu...

Isn't Kythe[0] trying to achieve this already, with a graph based, multi-language framework?

Of course, there are no integration with current dev tools, but the core is there to make it work, maybe?

[0] - https://kythe.io

Edit: Nevermind my parent comment, i guess the 'pinning' concept of IPFS does what im trying to elucidate here.. sorry for the noise.

(But the block scheduling algorithm could/might change in the future maybe? turining this into a real issue?)

Its not the technical part. Overall i even think that technically, IPFS has a superior model. I understand it works, and how it works.

What im saying is the control of whats important in a organic form is no there yet. The protocol controls what blocks the peers serve and people dont have much of a saying into it.

But given IPFS its layered in a good design, this could be changed and the block scheduling/routing could be binded more to this organic page-rank by letting people control more which blocks they serve, being more content aware.

This could be even done in a topic level, say you are ok to serve "free software". I guess that if you guys implemented something like that, giving some control to the peers of what they serve, it will be much more easy to sell the concept to everybody.

> - If I run an IPFS node, will I be hosting other people's data? What if these files are illegal? How can my "computer" (I guess a node is the terminology but whatever) be sure I won't be hosting some bad stuff?

Thats some of the reasons why i prefer the 'Dat' and torrent(be it classic or DHT) model of distribution per content, instead of IPFS which is per block.

The IPFS model make a lot of sense for cloud storage.. You might create a whole CDN based on its model where the clients dont even need to care about your backend storage layer.

But in the per-content p2p distribution model, we have the 'page-rank' effect, where popular or important stuff, curated by human reasoning of whats popular and important.

This model has worked pretty well with torrent, and public interest should drive the p2p storage model, where by using blocks, you lose some of the control and the context. And to see how this is a problem, the IPFS folks created the Filecoin to deal with the problem of the incentives, which on the 'per-content' model of Dat and Torrent, its a non-issue because of the natural page ranking indexing of content drive by public interest.

If something doesnt matter much, it will go away with time, just like our human brain works.

(Of course, if IPFS add some form of indexing of content by public interest on top of the block system, and even let you control what you serve. That problem would be solved)

Is this even possible?

Its just read-only machine code, theres no stack data for instance from the last executions that you can watch for.

Maybe only if you know when the code is being executed, in which register that particular builtin write the memory address of the payload, and then go for the payload on the heap to see what's there.

To know when the code will be executed you would need to watch for the VM loop and to when that particular builtin you are interested in its on the 'execution needle'.. But to get there you would first need to find a exploit, with arbitrary code execution, where you can upload your exploit payload to hook on the VM loop (and this sounds a lot of work to me).

(Not a Sec. guy myself, so genuinely curious how this could be done, but trying to figure out a way to exploit this, i kind of begin to see how it could be done)

I will tell you what works for me. Dont try to make one language to fit all cases, but try to use the best tech for each scenario.

In the past you had to learn a lot of languages and platforms and you still need it in some cases. But for my particular needs, i've managed to narrow down mostly to 2 languages: C++ and Swift. But thats for me, for others it will be different things.

But dont try to find the perfect language.. dont be a hostage to any tech suffering with stockholm syndrome with a given piece of tech.

This weird trend of one tech-fits-all started back in the nineties with Java, with things comming out straight from the religions like 'evangelism', and calling people infidels for trying different things.

Maybe whats work for me will work for you too. I bet you can narrow down to 2 langs to do almost anything you want.

About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams.

But of course, if i were to create a program to control a nuclear reactor or a submarine i would consider using Rust or Ada. But particularly i find Rust programming more stressful than C++ without (almost) nothing to gain. And on the language design aspect where Rust is superior to C++, i prefer to use Swift if i can, which i consider 'a better Rust'.

By the way in a lot of cases you might consider using Rust or C++, you can use the joyful Swift. Using a powerful language with less of a burden.

TLDR; Where some people will try to use Rust for everything, i prefer to use a Swift/C++ combo, and given you can mix both without much problem in a single program, i hardly need or miss anything else.

The article is talking about a party. Its not in the bussiness context, which as a Brazilian myself i can say, it works with punctuality as expected.

> However, Americans wouldn't normally be late for job interviews or other important events in a set time, which is completely normal in Latin America.

Nope. Sorry, but you are completely wrong. If you are late in job interviews for instance, you will probably not grant the job, if its in bussiness meetings, it will hurt your credentials in the company and it can even lead one to be fired.

Bussiness mentality is different than party mentality. Other things you must have to take into account is local culture. Rio is more laidback, while Sao Paulo is much, much less because it has more of a bussiness culture. (And i bet its the same in the US between different cities).

Thats one of the reasons why i try to teach some people, that for some contexts, thinking in terms of 'Latin America' its just wrong and too broad of a generalization.

You cant hardly generalize the whole of Brazil, and doing so in terms of Latin America is even worse.

I dont know how much money MS do with Bing, but if i were they, i would open source everything to see a lot of Google competitors pop here and there based on their tech, and later buy the most proeminent contenders. They are locked in to the 2% position, and thats the only alternative i can see to shake things up and have a change to grab more.

They could also provide the pure search index for other companies by using their cloud infra, and charge for the cloud use instead where Bing would be only one of the clients of this open search index.

It was basically the strategy the open source world with the lead of Linux did to them, and were able to take down their dominant monopolistic position over software.

> That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.

I think Google figure it out its real bussiness like MacDonalds did: Not burgers, but real state bussiness. I think Google understood they are not in the make "valuable useful tech" bussiness as one is inclined to think, they are in the "tech talent retention bussiness".

Even if they dont use the talent, if they are able to lock the talent inside Google as a kid in a Circus, their competitors wont have access to the talent pool they need, and this will make a big monopoly on Google.

Of course, this is only possible if you have the ammount of cash and credentials Google have to attract tech people like Disney do to kids.

I think this is their real primary mission; attract human talent, retain and ultimately lock it from the competition.

Do you ever wonder why the startup scene is so dry lately, even with so many enginners and tech focused people no short of ideas? The titans are just sucking all the oxigene in the room making everyone else choke.