You can do very complex stuff without any need for React like approach. I literally said I've written a very sophisticated framework that was exceptionally snappy - that's what should be used for that 1% (not my framework, but the approach). Even better, I could introduce it very gradually and strategically on different SSR pages and then (if I wanted to) I could turn the whole app into an SPA - all without needing to "render" anything with JavaScript, VDOM or other such nonsense.
Oh no, they do that? I thought Next.js is a fully functional backend itself, like Django. But I'm shocked to learn that it's just a middleman-backend to render templates that are already served from another backend.
Server renders the page. Suppose you have a element there which reads like <div data-component="HenloComponent">...</div>. Then the .js framework which was loaded on that page queries the DOM in search of any elements with data-component attribute and creates instances of HenloComponent (which is a class written by you, the developer, user of the framework). It's a bit more complicated than that, but that's the essence of it.
Note that with this approach you don't need to "render" anything, browser already done it for you. You merely attaching functionality to DOM elements in the form of Component instances.
I don't see a problem with HTML. It's easy to learn, easy to use and a very nice format for web. CSS is also great. JavaScript is pretty great too. My point is that modern web is horrible because people with no taste and no understanding of the underlying technologies turned it into a horrible shitshow by inventing frameworks that turn the web upside down and making a bloat out of it. I don't hate many things in life, but this one - with passion, because every time I visit a website, I can just feel it's made with React because of how slow and laggy it is.
If I could make one law related to software, it would be to ban React and React-like frameworks (includes Vue and Svelte I believe): if you have to put more than one line of HTML in your JavaScript, if you have VDOM, if you have a build step - I want this to be illegal. It is entirely possible to write a js-framework that attaches itself to DOM from the top, without any kind of expensive hydration steps or VDOM or templating (I've built one). React is a horrible complex monster that wastes developers time, heats up users' CPUs and generally feels super slow and laggy. 99% percent of websites would work a lot better with SSR and a few lines of JavaScript here and there and there is zero reason to bring anything like React to the table. React is the most tasteless thing ever invented in software.
So, I also write Go and I don't get the part about tooling. I don't need formatters or linters as I'm adult enough to know how to format my code (in fact I dislike tools doing it for me). D also has dub, which is fine, as far as package managers go. The ecosystem is the only issue and Go does arguably have a lot of very cool libraries for virtually anything, but outside of webdev, I can't see myself using them. This is why D works a lot better for projects where I don't need all those dependencies and would do better without them.
I really love D, it's one of my favorite languages. I've started implementing a vim-like text editor in it from scratch (using only Raylib as a dependency) and was surprised how far I was able to get and how good my test coverage was for it. My personal favorite features of D:
* unit tests anywhere, so I usually write my methods/functions with unit tests following them immediately
* blocks like version(unittest) {} makes it easy to exclude/include things that should only be compiled for testing
* enums, unions, asserts, contract programming are all great
I would say I didn't have to learn D much. Whatever I wanted to do with it, I would find in its docs or asked ChatGPT and there would always be a very nice way to do things.
Yeah, I get it. Technically, nothing prevents me from writing a formal spec (rules are rather simple too and most are listed in the README), but I just don't expect any kind of adoption, it was really just a tool for myself to ease the pain of writing docs. Thank you for the feedback.
Markdown is unreadable as a source. This solves the problem of looking good and clean as a text document and not having to remember many rules (certainly less than Markdown) to write a valid Shrimple markup that compiles nicely to HTML. Another thing is a static site generator that's very nice for writing documentation sites -- it takes care of generating not just the html pages tree, but also inserts menu and navigation links in them correctly.
On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
To add to my other comments ITT, I was thinking how the proposed name-spacing in Ruby would work is, in one way, diametrically different from Go where you'd normally import a package with the name that was chosen by the package author. But, at the same time, you could choose to import it under a different name or with no namespace at all, using the dot prefix. I'm not sure which is better. I suppose I could agree Go has a better default when it comes to namespaces.
Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
Using Ruby modules to namespace things is certainly possible, but is very often cumbersome. Modules also "hardcode" a namespace: that is, if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere -- or, in other words, namespacing is controlled by library author, not user. The proposed feature shifts that control to library user.
The only difficulty in Ruby code is the block notation. Even then, it is very similar to constructs in JavaScript, Go, D and a number of other languages -- the only difference form JS would be that instead of `(x) => ...` you write `{ |x| ... }`.
Questions such as
> why does it not have parentheses around it but the `", "` passed to `join` does?
would be exactly the same for JavaScript, Go or D. Ruby has the best syntax with regards to blocks/lambdas/closures.
I recently read almost the whole book in a week or so. It's excellent and I feel like I can write in D pretty well after reading it. Too bad that I most likely won't be writing in D, but, at least, I'm confident I can come back to it anytime and be up to speed if I ever need to. This book should be the goto for anyone who wishes to quickly learn the language.
I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe".
Examples:
* Python preferred over Ruby
* TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS)
* Go is preferred over Crystal and D.
While Python, TypeScript and Go are quite alright, there is no doubt in my mind that their alternatives are absolutely superior as languages. Yes, in case of Dart, Crystal and D the ecosystem doesn't have the abundance of well-tested libraries, but as languages they are simply better. The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
Another thing that comes to mind is the level at which one is familiar with a particular style of code organization & a set of abstractions. For example, Rails devs really have absolutely no problem getting up to speed with any given Rails app, but people who don't practice Ruby/Rails as their primary language/framework often complain how complicated and magical it is.
That's very one-dimensional. It's usually easy to tell what the code does, but what's hard is to modify or add functionality to it. And this is because of various levels of abstractions that hide how things are interconnected.
Honestly, I'm greatly annoyed by recruiters. They don't know a single thing about programming and operate solely on keywords. My personal approach now is to just tell them "I have this much experience, I have lots of open-source code which proves my experience, get me an interview with the actual team if they like my resume". Because in 99% of cases it's not even worth the time for a call with a recruiter.
Btw, in your particular example, I think it's fair to tell them "yes, I have the exact qualifications you're looking for", because they won't be able to check anyway. And certainly not whether you had 4 or 5 years of experience with a particular thing.
Well, how ironic we're in the same boat, it seems. Only I can't get hired because I'm 40 and have many years of experience and everyone seems to assume I'm either a snowflake or will cost them. Granted, I can only afford remote positions at the moment, but then I'm not asking for a lot of money either and I'm fairly easy going. I sure have my preferences, but they're few. What's really making it all unbearable is this leetcode and multiple-round-interviews are just exhausting and they don't lead anywhere, it seems. Nobody's even looking at your published open-source code (which is what I used to do first when I used to hire people). I don't really know if I'll ever work as a software-engineer ever again. Reduced to a hobby, I suppose.
It really isn't. It's very much tied to certain stacks, while it's completely uncommon in others stacks, because they're solving the same problems in a different way. I've never touched it in my life. Sure, I can pick it up, but I fail to see how it should be considered common.
I wish this was true. You can't even get hired if you're proficient in a language, but don't know framework X. Which is understandable for, say Ruby (I don't know anyone who knows Ruby, but doesn't know Rails), but it's inexcusable for JavaScript. I've been programming JavaScript since like 1997. Sure, I'll pick up React no problem, but I won't be touching it unless I'm paid, because React is a disgrace.
But it's not just these languages. It's every other language pretty much. You want to be hired as Go dev? Better know how to use gRPC and Kafka. Java? Better know Spring. I can go on and on.
Couldn't download the official Windows 11 from the MS website, no matter which VPN or country or server I tried. They know them all by now. ALL. Ain't hard, of course, since all VPNs are mostly hosted at 4, 5, maybe 6 data-centers which belong to large companies. Which names are known to the ones who either deals with them or simply pays attention.
Pretty sure, because the static ip-addresses were offered only for the servers located in very specific countries and particular locations - namely in the US & Canada. And, "coincidentally", that's were the ip-address of their website was.
In addition, they were very adamant about advertising how a static-ip address would relieve you, the customer, of the pains of captchas and thus be whitelisted.
"Networking for Systems Administrators" by Michael W. Lucas.
In retrospect, should've been called "Networking for programmers". Short. Concise. Examples for all operating systems including Windows. That will get you started. After that, to level-up, any book with good ratings would do. And you will also know which part of the networking stack you want to learn more about, thus, you'd pick the correct book for yourself. But this one is a must have if you're feeling very uncertain about your understanding of networking concepts and how everything glues together.