I found this article also very interesting: https://extremelearning.com.au/unreasonable-effectiveness-of-quasirandom-sequences/
It focusses more or less on one sequence but provides use cases and in-depth knowledge
Software engineering, Rust, Zig, embedded
I found this article also very interesting: https://extremelearning.com.au/unreasonable-effectiveness-of-quasirandom-sequences/
It focusses more or less on one sequence but provides use cases and in-depth knowledge
Didn’t read all, however, thanks for sharing. Made me laugh and I certainly needed a good laugh today
C’mon, a little bit of flexing is so nice.
But, I get what you’re saying. I usually filter out this bullshit (because I’m a Rustacean myself 😜) but this doesn’t mean that it is as easy for someone else as it is for me.
Helix editor was my gateway drug to neovim. May be helpful to others as well
For all of you, who want to start neovim, or just started (nyself included) than kickstart.nvim is a great start: https://github.com/nvim-lua/kickstart.nvim
I think they also live after the mantra “move fast and break things”, in cars that literally means breaking bones.
Fair enough. There are pretty pedantic processes to qualify automotive software, but these are obviously not perfect and bad quality software may still be deployed to the cars.
However, I would not throw OEMs like Tesla and others into the same category regarding Software quality.
How do you mean this?
I assume so
Automotive, Aerospace. Everywhere where you need safety qualifiable software (safety as in ISO 26262 or equivalent)
Interesting. Can you provide a good link regarding generational index?
Do you know which extensions are good? I used to use 🤪 vscode but changed to helix and then neovim due to the memory and cpu usage vscode does require.
Rust and Zig are currently my favorite languages.
The first-class dev and debugging experience, is this with Visual Studio or Rider as IDEs?
Because I currently do C# with Linux + neovim + Omnisharp as Language Server and it is really slow and bad. Do you have any tips?
I agree about the increase on other communities (in particular the cs career questions you mentioned). I am not sure about deleting them, specifically since I consider these parts of this community as well. Just my 2 cents …
Afaik it had more to do with another layer of abstraction then with compike time.
Too be frank, it is pretty short but your summary is on-point. I would only add, that Svelte also dropped it due to the additional compile step.
However TS can still be used in most of the frameworks including Svelte.
I started hearing of it in 2021. Read through the documentation in February of 2022 and started to learn it in Fall of 2022. Ever since then I use both, Rust and Zig depending on the small project or concept I currently want to explore.
I wrote a blog post that describes the 3 things I like about both languages each: https://zigurust.gitlab.io/blog/posts/three-things/
Might be interesting.
I think the article is ok, and yes I read it ;)
I think the title is unnecessary click-baity, because there are some relevant truths to it.
Most relevant truth us, that a lot of applications won’t need async since they are not large enough, not IO bound etc…
I think one of the misconceptions in this article is, that the author arguments that you need to be an Amazon or google to benefit from async. This is not completely wrong but, as a software developer in the embedded system industry that I am, I must say it is also very relevant for embedded systems.
If someone read the article and is unsure about async, I can recommend these two articles that provide insights “from the other side” these means devs that actually find async relevant and beneficial:
https://notgull.net/why-you-want-async/
https://without.boats/blog/why-async-rust/ The article from boats is absolutely worth it. Even if you are an async sceptic.
Finally regarding the introduction of async APIs and abstractions into any code base:
Creating an async application or sync application is an architectural decision. And since architecture is the sum of all decisions that are hard to change (I think this is from Martin Fowler) thus decision - async or sync - is hard to change and one must live with it.
Yes, there are languages like Go or Erlang that resolve this async vs. sync problem, they come at a cost (having a runtime, at least Go has one afaik, I no nothing about Erlang). And choosing a particular language is also an architectural decision and hence hard to change.