I can't agree with him more that Github went to absolute shit and I can feel React crap emanating from it without even looking at the code. There's everything in the world wrong with React and I would easily call anyone advocating it a code-monkey in their face. It's not about JavaScript itself - it's about the framework ideas, which are absolute trash. If anyone's offended by a code-monkey, I feel like maybe they should be.

State manager isn't there yet, but it's coming.

Putting React with those two is a wild take.

> 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.

Probably but as soon as you have a modicum of logic in your page the primitives of the web are a pain to use.

Also, I must be able to build stuff in the 1% space. I actually did it before: I built an app that's entirely client-side, with Vue, and "serverless" in the sense that it's distributed in the form of one single HTML file. Although we changed that in the last few months to host it on a proper server.

The level of psychological trauma that some back-end devs seem to endure is hilarious though. Like I get it, software sucks and it's sad but no need to be dramatic about it.

And btw, re forbidding stuff: no library, no process, no method can ever substitute to actually knowing what you're doing.

Can you elaborate more on how this works? Do you mean JS loading server generated HTML into the DOM?

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 entirely agree. It is what I do when I have to - although I mostly do simple JS as I am a backend developer really, and if I do any front end its "HTML plus a bit of JS" and I just write JS loading stuff into divs by ID.

When i have worked with front end developers doing stuff in react it has been a horrible experience. In the very worst case they used next.js to write a second backend that sat between my existing Django backend (which had been done earlier) and the front end. Great for latency! It was an extreme example but it really soured my attitude to complex front ends. The project died.

That's hilarious.

Casey Muratori truly is right when he says to "non-pessimize" software (= make it do what it should do and not more), before optimizing it.

The problem was that the front end developers involved decided to use Next.js to replace the front end of a mostly complete Django site. I think it was very much a case of someone just wanting to use what they knew regardless of whether it was a good fit - the "when all you have is a hammer, everything looks like a nail" effect.

I did a search and a lot of people are promoting the concept. Maybe it makes sense if you have a strong reason to use micro services, but for the vast majority of systems it seems crazy!

We could go further and have a language written to run in a sandbox VM especially for that with a GUI library designed for the task instead of being derived from a document format.

I think HTML inside JS is a code smell. I cannot even imagine why you would need CSS inside JS.

* 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.

From a philosophical/language-design standpoint, it ticks so many boxes. It had the potential to be wildly popular, had a few things gone differently.

If the language tooling and library ecosystem were on par with the titans of today, like Rust/Go, it really would be a powerhouse language.

Still much better than GCCGO, kind of useless for anything beyond Go 1.18, no one is updating it any longer, and may as well join gcj.

For regular common code that is indeed not an issue.

They both work out of the box without MSVC installed.

It's only ImportC feature that requires MSVC. The work required to get clang working in its place hasn't happened yet.

D definitely missed a critical period, but I love it all the same.

IMO, the bigger issue is language tooling.

    void abc() { def(1.0); }
    void def(double) { }

... Now, get started on ImportC++!!! (Only joking... kind of. ;-) )

I could tolerate the noisy language bits, but:

The standard library (Phobos) was so riddled with paper cuts that every day I used it felt like trying to navigate the surface of a coral reef... barefoot... in a hurricane... while blindfolded. It drove me off after a few months. (That was last year.)

A Phobos V3 design has begun, but given how few people they have to work on it, I am skeptical of it ever developing into a library that I would want to use. Here's hoping for a pleasant surprise. :)

Heavy reliance on the range interface, without automatic support for common range-like types like arrays, so calling code must be cluttered with wrappers.

Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)

The doubly-linked list implementation had no obvious way to remove a node by reference; removal of an inner item seemed to require traversing the list.

Inconsiderately designed class hierarchies. (e.g. InternetAddress & Internet6Address shared a base class that lacked a port field.)

Inconsiderately designed interfaces. (e.g. CRC32 could deliver a result only as a byte array, which fits the generic std.digest interface, but not as an integer, which is how 32-bit CRCs are often used in the real world.)

Unfortunate naming choices scattered about, such as a function name implying behavior subtly different from what the function does and a user probably expects (leading to surprising bugs) or named after a specific computer science algorithm instead of its purpose (making the needed operation hard to discover).

Various types and functions defined without the attributes required by other parts of the stdlib, or required in order to use/override them in safety-minded code. (e.g. nothrow, @safe, scope)

Time module lied about system clock resolution despite having internally retrieved the correct value from the OS.

Generally useful functionality kept private within the library, rather than made public, forcing users to either re-implement it themselves or lean on arcane trickery to get at it. (e.g. string escaping.)

Logger output customization was needlessly difficult.

No viable async/coroutine support. Vibe.d is the closest substitute, but is a third-party package, integrates poorly with Phobos, isn't documented very well, and is buggy.

...

Mind, these are just highlights of things I discovered while using D for one small project (a network protocol library and tool) so this is by no means a comprehensive account of problems in Phobos. All these problems could be worked around, but I ended up spending far too much time investigating them and developing workarounds instead of being productive.

I acknowledge that I was new to D, so some of my complaints might have had solutions. (However, I would point out that a solution that isn't easy to find might as well not exist.) Regardless, the pattern was clear: Phobos was a PITA to use. Too many paper cuts.

> a standard library you like?

I stuck with C, C++, and Python for more than a few years. Their standard libraries all have significant problems, but none frustrated me so much as to drive me away from the language.

The issues you have are examples of known problems that PhobosV2 has suffered under. Coroutines, for instance we would like to have in language, a proposal (me, not Adam) have already made one, but it's sitting till next year. Naming and interfaces issues are a big part of what will change in PhobosV3.

But D arrays/slices are already ranges. Is this referring to string autodecoding or something else completely? I fail to recall any situations where builtin types required wrappers often.

>Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)

This is mirroring C++ iterator design and IMO the right move though I agree that specifically for ranges it is rather awkward to use in practice.

What would you return instead? A pointer? What if one wants to find the position of the element and do something after that with that position/subrange.

The time module "lied" seems like a straight up bug. Can you give any more details on it?

Thanks for responding well to constructive criticism.

https://github.com/dlang/druntime/pull/88

I really dislike this for headers, but also, this marker is only valid inside code blocks and is optional.

> How do you specify the language for code blocks so they can be syntax highlighted?

See above, with ###Go and then add Prism.js into your document.

Also I commented with some feedback in another part of this post.

    require 'foo'

    module MyPreferredNamespace
      include Foo
    end

Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing.

I'd like to hear of a real use case for namespaces that existing conventions don't already solve.

Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing:

    module MyGroup
      include Module1
      include Module2
      ...
    end

Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace

For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby:

   def wrap_load(path) = class_eval(File.read(path), path)

   module Test
     # some_file.rb will act as-if defined within Test
     wrap_load("./some_file.rb")
   end

Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.

This is not the Ruby ethos.

And why would you bother doing that when it would be a breaking change?

It will be identified as such by e.g. the default `inspect`, but nothing stops you from `include`-ing MyModule into another module or class, or even the global scope so that you can reference MyClass without MyModule.