Very cool. To be honest most of these languages (except maybe Lisp and BASIC) are pretty awful. I can't imagine writing anything in them. Especially K. That's got to result from some form of brain damage...

It’s only 7 bytes of code. !10 returns a list of numbers 0 to 9. 1+!10 adds 1 to each of them resulting in a list [1, 2, …, 10]. Finally /1+!10 applies * verb with scan adverb and returns 123...*10 which is a factorial of 10.

But it processes arrays of numbers in such an elegant way what no other language can compete with it (well, maybe numpy).

Uhm yeah or maybe MATLAB? I mean I mainly like MATLAB because of its unbeatable plotting abilities, but even MATLAB can do prod(1:10). I am very happy to spend 3 extra bytes on that readability improvement!

Only a Linux user's answer to "how do I install software that's not packaged for my distro" would be "don't".

The only Git GUIs that I've ever liked:

• GitX, and its many forks. Mac only though.
• Git Extensions. Terrible name, but this is actually a standalone Git GUI and is surprisingly decent. I think it started Windows only but maybe there's a Linux port now.
• VSCode's "Git Graph" extension. It's not quite as fully featured but it integrates well into VSCode and is pretty nicely designed.

I've tried almost all the others (SmartGit, Sublime Merge, GitKraken, etc.), and didn't really like how they worked.

It's sooo sloooow though.

Ooo I've not seen this before. Looks interesting.

Impressive persuasion! I can't imagine that ever working at any company I've worked at.

Swift users... how is it? I hear compile times are bad. Worse than C++/Rust?

It's not just that. Debugging segfaults and UB can be an absolute nightmare.

The C++ committee still haven't learnt their lesson. I recently learnt about C++20 coroutines, which are pretty neat, if complex (there are pretty much no good learning resources about them). However they are still putting unnecessary UB footguns in it.

It's not moot. The Safe C++ is opt-in to safety. It has to be because otherwise it wouldn't be compatible with existing C++.

Yeah but I have written a lot of Rust and I have yet to use a single unsafe block.

Saying "but.. unsafe!" is like saying Python isn't memory safe because it has ctypes, or Go isn't memory safe because of its unsafe package.

No it doesn't, that's bullshit.

I haven't actually used this site (found it after I already learnt Git), but it gets posted a lot, and one issue I feel like it has is it shows you the Git graph using a tool that you have to immediately throw away after you've finished this tutorial.

I think it would be better if it had an actual real Git tool shown. I would say VSCode's Git Graph extension would be ideal but unfortunately it has a stupid license.

That's... kind of extreme! I don't know of any alternatives that allow migrating issues from Github and generating these graphs anyway.

The tool on the page. If you try a large repo it will indeed hit that limit, offer a button to authenticate yourself, but if you click that button it never loads the target URL.

Unfortunately it's not my organisation so I can't create a project.

Gives "rate limit exceeded" and the authorisation link doesn't work unfortunately.

He never said it was an Internet Draft. Try actually reading. It might help you in the future when you are discussing things.

I think I disagree with everything here.

Exceptions Are Much Easier to Work With

Well, they're "easier" in the same way that dynamic typing is easier. It's obviously less work initially just to say "screw it; any error gets caught in main()". But that's short term easiness. In the long term its much more painful because:

1. You don't know which functions might produce errors, and therefore you don't know where you should be even trying to handle errors. (Checked exceptions are the answer here but they are relatively rarely used in practice.)
2. Actually handling errors properly often involves responding to errors from individual function calls - at least adding human readable context to them. That is stupidly tedious with exceptions. Every line turns into 5. Sometime it makes the code extremely awkward:

try {
   int& foo = bar();
} catch (...) {
   std::cout << "bar failed, try ...\n";
   return nullopt;
}
foo = 5;

(It actually gets worse than that but I can't think of a good example.)

Over 100× less code! [fewer exception catching in their C++ database than error handling in a Go database]

Well... I'm guessing your codebase is a lot smaller than the other one for a start, and you're comparing with Go which is kind of worst case... But anyway this kind of proves my point! You only actually have proper error handling in 140 places - apparently mostly in tests. In other words you just throw all exceptions to main().

System errors [he's mainly talking about OOM, stack overflow & arithmetic errors like integer overflow]

Kind of a fair point I guess. I dunno how you can reasonably stack overflows without exceptions. But guess what - Rust does have panic!() for that, and you can catch panics. I'd say that's one of the few reasonable cases to use catch_unwind.

Exceptions Lead to Better Error Messages

Hahahahahaha. I dunno if a bare stack trace with NullPointerException counts as a "better error message". Ridiculous.

Exceptions Are More Performant

Sure maybe in error handling microbenchmarks, or particularly extreme examples. In real world code it clearly makes little difference. Certainly not enough to choose an inferior error handling system.

I would say one real reason to prefer exceptions over Result<>s is they are a fair bit easier to debug because you can just break on throw. That's tricky with Result<> because creating a Err is not necessarily an error. At least I have not found a way to "break on Err". You can break on unwrap() but that is usually after the stack has been unwound quite a bit and you lose all context.

I'd like to know which specific projects they funded. It's there a list anywhere?

I think embedded Rust is simply really really new, and requires interacting with crusty C tools which is going to reduce reliability.

It's also a little fragmented with people trying different things out (e.g. Embassy vs RTIC), and different chips getting different levels of support.

Totally different experience to desktop development.

1. If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn't have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.

2. It has a very strong (and nicely designed) type system which gives an "if it compiles it works" kind of feel, similar to FP languages like Haskell (so they say anyway; I've not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.

3. The libraries and APIs are generally very well designed and nice to use. If you've ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get string::starts_with but Rust started with it (and much more!).

4. Fast by default.

5. Modern tooling. No project setup hassle.

6. It's a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript's answer for ages was "serialise to JSON and back" which is crazy.

Downsides:

1. Slow compilation sometimes. I'd say it's on par with C++ these days.

2. Async Rust is kind of a mess. They shipped an MVP and it's still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can't.

3. Interop with C++ is somewhat painful because Rust doesn't have move constructors.

Great language overall. Probably the best at the moment.

I don't think so. At this point Linux isn't really held back by software availability - 90% of things are web based now and games apparently work pretty well (certainly better than on Mac).

The main issue is hardware support and driver quality. Especially on laptops, if you install Linux you're really rolling the dice on whether or not you'll get something that works.

Someone always replies to comments like these with "it works for me!" which is not really relevant when it has to work for everyone.

For a while at work I was in the Linux slack channel even when I was using a Mac, just to follow the amusing problems people had (and they had a lot!).

Then I moved jobs and have a Linux laptop... I get to experience it first hand. Hard reboot when it runs out of RAM, or 20% or the time when you undock it. Doesn't work at 60Hz/4K on some work monitors but only if you are using HDMI. The exact same laptop model & OS works for other people. Battery life is hilarious. I don't think I've ever got over 2 hours.

No because it doesn't remotely take that long.

Sure, but it's very similar. The point is that those people didn't get to choose the language they're using and now someone is forcing them to use a specific language. They've always been forced to use a specific language.

I guess it just think "I don't want to learn" is a lame excuse.

That's a lot easily than learning the C to the same level and they "force" everyone to learn C.

Right but presumably you can let the AI do that hunting.

Gemini has a 1 million token limit. Also instead of just giving it the entire source you can give it a list of files and the ability to query them (e.g. to read an entire file, or search for usages/definitions of terms etc.).

No but I think this is probably a great use case for AI. Haven't tried it though.

you can write perfectly safe software in it.

In the same way that you can safely walk through a minefield.

I dunno what you mean about it being an expressive language either. I would say it is relatively low on the expressiveness scale compared to something like Python or OCaml. It's basically as expensive as Go which is renowned for being unexpressive. Maybe you didn't mean "expressive".

Make sense. Firmware is also extra difficult to debug so it's nice to use a language that significantly reduces the amount of debugging you need to do.

Looks interesting. Linux ABI compatibility is a herculean task though. Probably on the order of writing a web browser or a MS Word compatible word processor.

I think either is probably fine. Apparently the French stress the syllables equally, not just the second so it's a minor difference.

Actually I just listened to the French pronunciation and it sounds more like they do stress the first syllable to me:

https://youtu.be/fN1VwDpxbXQ?si=1VcffgqbwRelS8zY

They're being diplomatic. From Wikipedia:

The name "Godot" was chosen due to its relation to Samuel Beckett's play Waiting for Godot, as it represents the never-ending wish of adding new features in the engine, which would get it closer to an exhaustive product, but never will.

Yeah except it's named after the play so it's definitely pronounced God-oh. I think people just mispronounce it Go-dot if they haven't heard of the play. Looking at you Mr Linus Tips.

Think of it from the company's point of view. If you're hiring a new employee then the options for a good candidate are a) move jobs and work for you, b) move jobs and work for someone else. You're competing with other companies.

If you're reviewing an existing salary for a good employee their options are a) do nothing and accept the shitty raise, b) move jobs and work for someone else.

Moving jobs has significant cost for most people - it's time consuming, stressful, might involve moving house, etc.

That downside gives employees who haven't proven they are looking for a new job a significant negotiating disadvantage.

If you really want you can tell your boss you are actively looking for new jobs. That will increase your chances of getting a bigger raise, but of course it has other downsides so most people don't do that.

Rust is the obvious answer, though I dunno how suitable it really is for games - the most popular game engine is Bevy and I'm not sure I like it too much. Also there seems to be much more focus on game technology than making actual games.

Don't worry about it being "functional" though. It did support lots of FP features but the typical style is much more like imperative C++ than Haskell.

I would also look into Zig though.

Languages that make use of references rather than pointers don’t have this Dualism.

It's not about references vs pointers. You could easily have a language that allowed "null references" (edit: too much C++; of course many languages allow null references, e.g. Javascript) or one that properly separated null pointers out in the type system.

I agree with your point though, using a special Null value is usually worse than using Option or similar. And nullptr_t doesn't help with this at all.

In VSCode the best answer by far is Pylance, which uses Pyright under the hood for type analysis.

Unfortunately while Pyright is open source, Pylance isn't (part of Microsoft's strategy to maintain control over VSCode), so you can't use it in Emacs.

Still, I would give the Pyright LSP server a try. I haven't used it but I would guess it will give you type error squiggles but maybe not code completion / go-to-definition.

Ruff is really a different thing - it is a linter like Pylint, so it only gives you some hints and fixits. You can maybe install it in addition to Pyright if you can be bothered.

Btw Pyright is far superior to Mypy - even with --strict. I would ditch Mypy asap.

Lazy cliché title. Try harder.

Ah yeah no call recording is so stupid. It's not even illegal in most of the world. There are plenty of phones that unofficially support it too and they have never got in legal trouble.