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.
i agree that the plug-in chaos of vim and even emacs is exhausting. there’s so much churn, abandoned packages, and all this decision making that you have to do to get started. but at the same time you can’t expect to be able to build all the functionality into the editor. my workflow is greatly simplified by using tpopes vim-fugitive, it’s a fantastic git interface and it makes total sense to be part of an editor, and the lack of a similar thing in helix was the first reason i went back to vim after trying it out. if helix had plug-ins i’d probably be implementing that functionality myself! there are tons of other things like that. sure i could start building a git interface into helix itself but that both seems like a failure to separate concerns and a possible waste of time if it gets rejected by the maintainer etc.
> The ability to use plugins is no quality in itself
Theoretically no, practically, it is since someone is indeed more likely to extend the functionality via a plugin since the barrier is lower vs. adding the same thing to the core
Also, for some things that someone could also be you
> Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim.
Or you'd just copy the plugins/configs of someone who spend those days already, just like in those astro-space-packages you mentioned
As far as I remember they stated that plugins won't be supported back when I tried it. No idea if that has changed.
Of course the plugins need to be written but my point is that they cannot be written at the time.
I understand and support the idea of Helix to be useful out of the box for many use cases. However for me the editor in its current form is not sufficient. As I already stated I use many (wonderful) plugins in Neovim. I could not justify going away from the status quo because it is pretty good. I have my setup configured so the ease to jump into is not really a valid argument for me and I suspect for many more Vim users.
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.
I don't think you get my point. In the end it's simple. Helix misses many features I want and that exist in (N)Vim. To support all these features you need plugins because they cannot be all maintained by core and everyone wants different features anyways.
As long as there is no way to extend the editor for me or for anyone else (aside from contributing to core), I am not interested in adopting it when I have another option that already does all of these things I want.
So yes you need plugins but for that you first need a plugin system. If that takes a while I am totally fine with it. I am all for good software. But why should I currently choose it over nvim?
Helix will get plugin support sometime, it's basically a matter of when not if.
Also; the scripting languages seems to become an S-Expression like lisp dialect.
They did lay off their Servo developers, and a few of their Rust developers.
They did not lay of all of their Rust developers, or even most of them. WebRender and Stylo are now integral parts of Firefox, and are actively maintained by teams of people, and a lot of new code continues being written in Rust.
The Servo DOM and HTML engine is massively complex - far moreso than Stylo or WebRender - and nowhere near ready for production use. Mozilla decided that rewriting the remaining parts (read: vast majority) of Firefox slowly, in-place, would be a better path forwards than maintaining two massively complex browser engines in parallel and trying to swap it out completely.
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.
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.
Not true. Panasonic is a Japanese battery manufacturer that Tesla is a customer of. Japan carmakers aren't going for batteries despite having local capabilities. Instead they want to go for natural gas based hydrogen fuel. South Korea also.
I don't know enough about Japanese law to know either way, but measuring needs, capabilities, and/or national strategy by observing the things that companies are doing is often a bad yardstick.
At best, this is twice removed from the facts at hand. [future capabilities and limitations exist] > [they're interpreted by legislators who design regulations and subsidies] > [automakers build whatever makes them money]
If look at the US automotive market, you might conclude that automakers have found the best way to decrease emissions is by making cars larger. This clearly isn't the case, this is simply what the regulations have encouraged companies to do.
Large companies are politically connected. The car manufacturers represent a large amount of exports and are politically connected. The politicians and lawyers aren't making decisions on their own. The car companies bring their engineering and science expertise to the table when crafting national policy.
Yes, and they do that with the interest of making money, not with the interest of ensuring national energy/resource security.
They're not building hydrogen vehicles out of some long-term concern about resource availability. Note how those same automakers don't sell those vehicles in the rest of the world, even though they're on the same planet with the same amount of cobalt.
Japanese automakers are building hydrogen vehicles because 1) they are being subsidized, and 2) they get a seat at the table to influence regulators.
Mirai has begun selling in California and its even more than the Model 3. It is definitely not subsidized. However, the price between model 3 and the Mirai make me wonder. I don't understand the science fully and I know most people don't know either except for the physicists. I don't trust Elon and batteries could be a short term thing.
Ah, looks like it has -- last time I checked I thought you could only get one on lease. Honda's FCX Clarity is still limited production and lease-only.
But yes, the Mirai and the fueling stations are definitely subsidized, both in Japan and in California.
Yep. They give you $15,000 fueling credit for 3 years but this is definitely a forward deposit for building out infrastructure. If you subtract the $15,000, the Mirai 2020 is within acceptable price range of the Model 3.
I am not the most scientific person but I don't like Elon Musk's history and that he didn't address the science properly. Elon Musk bought Tesla and scrubbed the founder's name because it makes it better for storytelling purposes. When mentioned fuel cell vehicles, he called it Fool Cells and wrongly brought up a 2 step process. Theatrics and logically true but wrongly used. I am familiar with these techniques used by bullshitters.
Google "wind power max efficiency". They knew the max capabilities of wind power in 1919. In other words, even if they improved the wind mill or turbines or the materials they are made from, they knew the upper limits or max value of this renewable wind power.
I believe the physicists that work for the Japanese and Korean car makers are aware of the limitations of battery power and have already mapped out its trajectory. With that knowledge, they have still decided for hydrogen power.
> they knew the upper limits or max value of this renewable wind power.
We also know the upper limits for solar. And for the current battery tech. And solid state battery tech. And the theoretical max for any battery that still follows the laws of physics as we know them. Your point being?
Hydrogen makes very little sense. Or rather, it only makes sense to keep the demand for fossil fuels high - because this is the cheapest way to get hydrogen (see natural gas reforming). Electrolysis is inefficient and expensive.
Not to mention the infrastructure required to compress/liquefy, ship, and building refueling stations.
All that for what? To feed it to a fuel cell and get electricity back. Just use the electricity to charge a battery and skip all the middle men.
If you have electricity, you are better off using batteries. The energy grid will likely be available close to you, transportation is taken care of. At the end of their useful lives, batteries can be recycled and we get most of the material back.
Due to hydrogen embrittlement, hydrogen tanks also have a shelf life.
This has little to do with physics and more to do with incentives from the fossil fuel industry.
That is Elon's talking point. He isn't a technical person. He bought Tesla and scrubbed the founder's name for business storytelling purposes. So natural gas produces hydrogen, this hydrogen is stored in a tank, and then converted to electric when it is used. There is no 2 step process but Elon dismissed this technology for this reason. I don't trust this guy. There is nothing he knows that the Japanese carmakers don't. I am only suspicious that the Model 3 is cheaper than the Mirai. It might be a short term play that I don't fully understand in the same way I don't understand have Citadel and Virtu make money from buying trades. However, I think they are up to no good.
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.
>> And by limited i mean thousands of man-years of work backed by a multi million organization.
It's so sad. We're so trapped. Fortunately, Google (or any other) can't completely alienate a huge part of the web. So eventhough they control the browser, they don't control its content...
Absolute numbers vary with each machine, to the point they’re irrelevant in isolation.
However, in terms of relative performance the async version was 10x to 20x better. Bear in mind it was a simple hello world benchmark. I also disabled keep-alive. Reusing a connection gets you even better performance.
Rocket is a well designed framework, so I’d expect it to perform similarly to other rust frameworks once the async version hits master.
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.
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.
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.
The overall experience is similar. Rust definitely has better error messages. The difference is that in C once your program actually compliles it can also easily segfault at runtime. With D and Go you just compile the program and it works. It only complains when you're doing something awfully wrong instead of being a grammar nazi all the time. Additionaly, D allows you to enable or disable certain features if you wish to. Want safety? Use @safe and @trusted functions. Want to disable the GC? Use @nogc functions. And the list goes on. One can enable all of these on demand.
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.
Given that he explains his thinking and reasoning in that post, one can either accept or challenge his logic and discuss it accordingly. There is no need for unprovoked attacks on his credibility. Doing so just suggests you don't feel qualified to evaluate the arguments he makes, in which case it's probably better to ask questions than attack.
It does not seem like an attack to me, rather informing readers of possible blindspots or conscious/unconscious bias in the author's point of view. I think it's only human nature to cheerlead something that one has put a significant amount of effort into making. I, as someone who does not know Swift and who its author is, would be more inclined to seek out alternate points of view after knowing that the author of this article is also the author of Swift.
Just as one would take any marketing/promotional material for why a company's products are better than competitors with a grain of salt, and would want such material to be clearly marked as marketing material, I think bringing to light the author's relationship to the Swift helps, and does not hinder, further discussion.
If presented in the context of a substantive comment about the assertions, I'd agree with you. Without any such substantive comments it's simply assuming the worst about others. The HN guidelines [0] are actually pretty darn good guidance for encouraging intelligent discussion of complex topics, and by my read advocate for more thoughtful approaches to commenting on multiple fronts here, including not posting shallow dismissals or assumptions about astroturfing and shillage. Again, if there is a concrete objection to the logic the author took time to detail in their post, by all means that's a great topic for discussion, and that's where we would all actually learn something positive instead of just insinuating something negative.
> If Neovim is the modern Vim, then Helix is post-modern.
/s