lordnaikon
lordnaikon on Hacker News
I get what you're saying. The problem is that it is not really a matter of if plugins are supported or not. Helix will have plugins in the future. There is work being done towards it – mainly design work right now and they try to figure out how to approach this best, writing "demos" etc.
Plugin systems are not easy and they have a clear vision of how this should NOT end up working. In their current state putting in work into a Plugin-System does not make much sense (limited developer time that is better spend elsewhere) regarding their project goal.
As i said you can argue that the project is in its infancy and does not work for you because of that. But the main reason is not the support or lack of plugins. As i said, even if there was a plugin system you could argue that there are no plugins available for the things you want – ending up at exactly the same point you're today. Having a Plugin-System does not magically makes hundred of useful plugins appear out of nowhere.
Helix does not want to limit itself by what NeoVim is:
> If Neovim is the modern Vim, then Helix is post-modern.
/s
The ability to use plugins is no quality in itself. Even if Helix would support plugins tomorrow, it would not magically mean you could use the same (or equal) plugins from your vim experience – someone needs to write them. You can argue that the Helix Project is in its early stages but many of the features you get by crafting your vim config are running out of the box in Helix now.
There will very likely be a time when Plugins are supported, but this time is not now. I like the approach to make first class integrated functionality rather than the mess we currently have in vim. Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim. If you need functionality on top of it, plugins will come into play. There is a reason why astrovim, spacevim etc. are popular, people don't want to spend to much time configuring the most basics that everyone is expecting today.
So if Helix does most of the things you need today i would encourage you to try it out and if it does not have a feature that you really need, plugins wouldn't help much either because somebody needs to write it in the first place and by the current userbase its very unlikely. It seems that most of the people are just gathering around the main project and make PR's directly which somewhat guarantees a certain amount of quality.
> Ditching Rust ...
have i missed something?
No, the primary reason is limited access to the energy market and limited resources on their island and that they're an island. And there is China. Hydrogen is a wonderful alternative if you don't have alternatives. But its awful if you have plenty, like the rest of the world.
I hope you don't want to play the "hydrogen fuel is the way to go, look at japan" card. There are very good reasons for japan to invest in hydrogen that are not applicable to the rest of the world.
The main problem is the mess that is called html/css. You can't "just" build a simple browser with limited resources anymore. And by limited i mean thousands of man-years of work backed by a multi million organization. I don't know if it is a calculated taktic from google to rapidly expanding and driving the web forward (i still hope the intention – at least at the beginning – was in good faith) so that nobody starting today from scratch could ever catch up. But i guess everybody that started to build a simple hobby web browser knows how unachievable this task is. If we ever want competition in this field again and don't want to handover the web to google, we need to start from scratch or at least start to massively deprecate stuff. And by the grave of Alan Turing start by making a website fail to render if the html is not correct.
What was the result of your benchmark – just a ballpark number would be great on what to expect from the async version.
It is to be honest. I checked out various OS's and being involved in one of them ( Redox OS ). The problem is that this is "just" the OS part. There are multiple layers above and multiple layers below. Understanding the ins and outs of modern processors (pipelining, branch prediction etc.) motherboards pcie, things like coreboot, modern RAM etc. multiple layers of software abstractions until chrome or firefox have rendered the pixels i command with the javascript engine ... that is just humongous compared to a simple 6502 setup where i am able to really understand every aspect, can replace pieces, build things on top (hard and software) .. making my own RAM ... just for fun. Its a different kind of thing.
This sounds super awesome! I can't imagine how interesting those times might have been. I started to play around with a 6502 just because there is the possibility to understand the system to some extend. Modern day software engineering is like sitting in the golden cage. Not because the the systems are inaccessible like mobile devices or Apple Computers – you can still get pretty far on Linux systems – but the main reason is that you just can fit all the stuff in your brain. If you try to understand how your Angular/React/whatever project is getting their pixels to the screen all the way down – its just a project for a lifetime and even that is not enough. Understanding modern x86 processors is almost impossible – yeah to some degree enough to understand some basic concepts to not shoot yourself in the foot with how the cache works etc. but getting your hands dirty with an 8-bit processor and reading the datasheet is just something very different.
If you fight with the rust compiler the same amount as you do with a C compiler than you're making something wrong in both languages. Don't get me wrong but the rust and C compiler are on the direct opposite of the spectrum – for me. I love how the rust compiler is holding my hand to avoid all the nasty bugs i would introduce into my code.
Which is in part written by the author and creator of Swift. Keep this in mind while reading this. Not to sound judgmental but I would be curious while Bill Gates explains to me why windows makes sense for X.
Is this what is known as pi or dependent types?
Hardware can misbehave. If the kernel can detect that it is reasonable to shut down the machine and preventing data corruptions. I cannot think of a kernel developer who would laugh at that.
> I don’t know Rust well
That is one problem and i don't want to attack you. This is something Rust needs to work on! Rust is indeed a relatively hard language to learn and understand and it is not really clear from the beginning nor in the intermediate level if its worth the effort. I can only speak from an empirical standpoint. Time showed – to me and maybe i am the only one – that i have fewer bugs in general, especially in the late stage of development. Rust tends to feel a little viscid in the beginning but it catches up later where you don't try to find a race condition in a 100k cloc Program. Rust has a good way to reason about your program especially in a multi threaded environment. And this is where Rust is fundamentally different of what we – as programmers – have experienced in the wild. Yes there are many efforts in academia and research languages but non of them are used outside.
Rust does nothing new or has concepts that are not strongly researched in academia. Rust is trying to bring those findings into the wild.
In Rust practically nothing can throw null pointer exceptions or class cast exceptions. Rust don't let you express ill-defined semantics with multi threaded code – you can't have data races.
And this implies – of course – that the set of programs that you can write in safe Rust is smaller than in C/C++/Java/C# ... you can't possibly write programs with data races or dangling pointers / null pointers. Thus making like 60% of all CVE's (i pulled this number out my ____) impossible to write.
Rust can't prevent you from making logical errors but it can help you preventing various categories of bugs we see in the wild exactly now.
Rust has many problems of its own kind, but none of the ones you listed above. immaturity in its ecosystem due to its short lifetime, steep learning curve and many more. But it can deliver very well in certain disciplines today.
Still no date as input type :(
You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (besides memory) garbage collection is helping you with. You have to mitigate those problems still in garbage collected languages like Swift, Go, Java, Python (to name a few) and various other solutions to help with this (try with resource, with statement, immutable message passing etc.) Rust tries to give you one solution "to rule them all". Is this better, worse? Idk – nobody does, the Rust people are trying to figure this out :) Nothing is carved in stone. And if you're more productive in another language you should use it! But you can only know by figuring this out for yourself. Rust works well for me – that's no guarantee that you have the same experience. Rust is still hard to learn and one needs to question himself if the effort in learning pays out at the end – it has for me, i guess/hope ;)
I can assure the lower bound is at least one. Thanks for boosting my productivity!
It is even worse. You can recover from backups but that implies that you already know at which point you destroyed your data and how fast you discovered that – if that ever happens. Imagine you're collecting data over a substantial period of time (maybe do calculations based on it that influence how you're collecting further data) and you're very smart and backup all your data let's say every day. The problem is if your data gets defects due to the file-system it is very unlikely to detect that. You can run your system for like a year without apparent problems whatsoever. Lets say that error accumulates and you eventually detect this by accident. Your backups are pretty much worthless ...
Is this also true to user downloads from a website? The majority of your clients get our apps via Enterprise certificates not through the Apple store process.
Is this only true for store downloads? Because the majority of our apps is delivered simply by a website download through the device via Enterprise certificates.
> I'd rather work on modern AND stable language (I actually do, its not Swift, buy that's not my point)
Greetings fellow Rust user ;)
Sure. It is a private field(no pub) preventing you from constructing that type with a literal. It is of type "unit" '()' so it does not add up space for the type. "unit" has only one value that makes it "zero-sized". because i did not supply an "constructor" to that type it is not constructable outside the module and can only created by types in the scope of the enclosing module. Its more or less a private constructor known in C++/Java ... etc.
Steve Klabnik has a more complete write up regarding this http://words.steveklabnik.com/structure-literals-vs-construc...