They are both doomed because neither is transformative enough to justify adoption. They are going to need to solve much harder problems to do that.

Take Rust as an example. It solved a problem that most people weren’t even paying attention to, because the accepted wisdom said it was impossible.

Mojo’s starting point is absurdly complex. Seems very obviously doomed to me.

Julia is a very clever design, but it still never felt that pleasant to use. I think it was held back by using llvm as a JIT, and by the single-minded focus on data science. Programming languages need to be more opportunistic than that to succeed, imo.

The github blurb says the language is comparable to general purpose languages like python and haskell.

Perhaps unintentionally, this seems to imply that the language can speed up literally any algorithm linearly with core count, which is impossible.

If it can automatically accelerate a program that has parallel data dependencies, that would also be a huge claim, but one that is at least theoretically possible.

Out of the ones you listed I’d suggest Julia or Clojure. They are simple and have interactive modes you can use to experiment easily.

Experienced programmers often undersell the value of interactive prompts because they don’t need them as much. They already have a detailed mental model of how most languages behave.

Another thing: although Julia and Clojure are simple, they are also quite obscure and have very experimental designs. Python might be a better choice. From a beginner’s perspective it’s very similar to Julia, but it’s vastly more popular and lots of people learn it as their first language.

Based on the languages you found, I’m guessing you were looking for something simple and elegant. I think Python fits this description too.

How did they ask all these random people and not bother to ask a single software engineer?

“Hi is this excuse real, or is it just a sign of an inappropriate relationship between the local council and a dodgy software company that pays more dividends than developers? Oh it’s the latter? Okay, thanks.”

Lol okay. Here are some concrete examples I don’t have:

Templates as basic generics

• Templates still show bizarre error messages far too deep into instantiation, despite at least three major features which provided opportunities to fix the problem (static_assert, type_traits, and then concepts)

Templates for metaprogramming

• 33 years after the introduction of templates, there are still many common cases in which the only good way to abstract a pattern is by using a macro, and many cases that neither macros or templates can solve
• There is finally an accepted proposal to fix part of the problem, which will be introduced in C++26, and probably not usable in real code until 2030 at the earliest
• In 2035, people will still be reluctantly using string macros and external code generation to solve basic problems in C++

Safe union types

• C++17, std::variant was introduced to provide a safe inline union type
• The main API for accessing it is inexplicably slow, unlike in every competing language
• The fast alternative is an eyesore that can’t integrate with switch statements except via weird, unmaintainable hacks
• Everyone keeps using custom struct/union/enum combos instead
• CVEs everywhere

Error handling

• C++ uses exceptions as the primary error handling mechanism
• Exceptions are so slow and so riddled with problems that some companies ban them, and almost all consider them bad practice for representing common failure paths (e.g. failing to parse something)
• std::expected eventually approved, similar to Rust’s Result type, but with no equivalent to the ‘?’ operator to make the code readable
• Now there is a proposal to introduce “value type exceptions” instead, which is gathering momentum before std::expected has even stabilised, but will probably not be available for 10 years

Subtype polymorphism deprecated

• Now that virtual methods and inheritance are widely considered tools of last resort, they obstruct the introduction of better alternatives
• Instead we have widespread use of specialised template structs and CRTP to replace instance inheritance with a kind of static inheritance designed for templates
• It’s all a hack, and as a result it’s full of edge cases that don’t work very well, and poor tool support

References

• Good C++ programmers use references where possible, because pointers can be null
• Good C++ programmers avoid unnecessary copies and allocations
• Good C++ programmers avoid patterns that can permit unintended coercions with no error
• Oh no, I accidentally assigned a reference to an auto variable in a template, and instead of giving a helpful type error it implicitly coerced a new copy of my vast memory buffer into existence
• Okay fine I’ll pass pointers to avoid this, and just trust they won’t be null
• Oh no, C++ has standardised the idea that raw pointers represent nullability even in all their newest standard library types (thanks again, std::variant)

Even following the guidelines, modern C++ is just a huge pile of half-finished ideas. It goes pretty well for the first few hundred lines of code, and then you hit a very basic problem where the solution is “yes this will work great in C++26, if the proposal doesn’t get delayed again”.

I learned through three things:

1. writing some basic functions in assembly code by hand for a course (not many)
2. implementing a basic compiler back-end in llvm (any similar IR or assembly target would do)
3. learning the principles other people were using to write fast code (in my case game engine developers)

The first two things helped me understand how common code constructs are translated to assembly, so I can do a rough projection in my head when skimming a C function. Nowadays you can get quite far just by playing around on godbolt.

The third thing helps surface the less visible aspects of CPUs. After learning how a few low-level optimisations work, all the principles and explanations start to repeat, and 90% of them apply to every modern architecture. You can set out with specific high-level questions, like:

• why is iteration faster with an array than a linked list?
• what does vectorisation mean?
• what is a “struct of array” optimisation?
• why does the ECS pattern make game engines fast?

Very quickly you’ll find lots of insightful articles and comments explaining things like CPU caching, prefetching, branch prediction, pipelining, etc.

I have no book recommendations for you. I’ve found all the best information is freely online in blogs and comment sections, and that the best way to direct my learning is to have a project (or get employed to do low-level stuff). Might be different for you though!

deleted by creator

deleted by creator

Why would you discourage interesting, original journalism over such an obtuse nitpick?

They are clearly criticising the same capitalist structures that you are. They single out the tech industry because the article is about the misuse of tech, not because they think rank and file tech workers are deviants.

Frankly it comes off as fragile and dismissive, and if that’s what we’re doing we could have just stayed on reddit.

If you see a real chance of it shipping soon, that might be good experience. As I mentioned, a surprising number of grizzled senior devs have never actually shipped anything.

But if you see better opportunities elsewhere then just go. Sad reality is that job hopping early is what gets most people a good salary. Very few companies give real raises. The only time you have bargaining power is when you haven’t joined yet or when you’ve already made plans to leave.

It’s very common. I’d bet most software projects still fail. I once met a guy who’d been a gamedev for over 10 years at some big companies, and every game he ever worked on got cancelled.

Sometimes these long, poorly managed projects do succeed though. Usually because they launch a beta or get publicly scheduled for release, and the sudden reality check causes someone senior to trim the scope down dramatically.

It might be worth sticking around if you think you’re learning things, but impose some personal limits. Don’t kill yourself trying to meet some idiot’s impossible schedule. Work your contracted hours and no more. Be blunt and unashamed about how long tasks really take. Share your concerns when the month’s schedule looks unrealistic, referring back to previous tasks that overran. This is how you learn to one day become a lead who doesn’t run shitty projects like the one you’re on.

You have imposter syndrome so bad you don’t even think you’re a real imposter!

That sounds plausible. I’m sure having the lowest possible latency was their goal. There are multiple popular rust libraries aiming to provide zero cost abstractions over a common subset of the metal, vulcan and dx12 APIs, but I’ve never actually used one.

But why? I saw their section about rasterising everything on the GPU, and again I find it hard to understand why they need anything more than OpenGL 3.

Their UI looks like it would be an LRU glyph cache and a sprite batcher, and then you’d have 1000fps.

Thanks for clarifying. Do you know what the bug is? I gathering it’s something to do with enums and boxing to enable a “safe” transmute, but couldn’t make sense of the code.

Scary compiler edge cases with value-type enums aren’t surprising though. Trying to implement that feature with memory safety and high performance sounds like a nightmare.

I’m still confused by this not being cross-platform. It’s made in Rust; basically every graphics library is cross platform out of the box, and so is all the file IO stuff. There will be some specialist OS api stuff in places but surely it can’t be much.

For once this comment isn’t even snark. I acknowledge my ignorance and wonder if someone could explain why the cost is bigger than I think?

Perhaps it’s setting up CI and packaging for other platforms? Maybe they want human QA on every release? Maybe the APIs for slick OS integration are more complicated than I realise? (e.g. putting UI in the taskbar)

Counter-point: Atom is terrible. Its electron competitors are terrible. Big IDEs are terrible. Simple text editors are terrible.

If you are under 50 and chose to learn vim or emacs, there is a 100% chance that you were also forced to learn latin at school and honestly it’s not your fault that you turned out this way.

These are all the options. Sometimes all the options are terrible.

Here’s one I learned from a past manager:

Stress that everyone needs to pitch in and make themselves useful at all times, but do not share any information at all

Make sure the work is not broken down into clear tasks. Make sure nobody else has access to the stakeholders. Make people ask separately for every single account or access credential they need, and respond with incredulity that they don’t already have it.

Give the impression that there are no processes. When someone submits work, criticise them for not following the process.

Each day, schedule meetings so you are impossible to contact until the early afternoon. That way you can interrupt any request for information by asking the person what work they did in the morning. The goal is to close the loop by making people scared to talk to you, so they blame themselves for not knowing anything.