I support the idea but is it really that important? It’s just a name. Call it ECMAScript if you’re worried. JavaScript if you aren’t.

No. Closest is probably Zed but it’s still way way off from being a serious VSCode competitor. For example it has no settings GUI at all; just a JSON file. It can’t edit large files. Font rendering is still hit and miss.

Ask again in 5 years…

How “production” are we talking? Pretty bad idea if it’s an important work server. “Sorry boss, nobody could connect today because VSCode’s mojam.service hit one of its many many 100% CPU bugs”.

I think in theory there’s no reason it isn’t technically possible, but I doubt it’s set up to allow it because that’s a pretty odd thing to want to do.

Edit: oh you want to access it via Android. That makes vaguely more sense.

Bad code will be unreadable in any language of course.

Yeah I’m talking about good code, or at least not bad code. Let’s not “no true Scotsman” this.

Even for good code you don’t need syntax highlighting to easily see which identifiers are function names and which are their parameters in Rust.

Rust. It has all the good bits of functional programming but basically none of the bad bits.

Good bits:

• Strong type system (though not quite as sophisticated as Haskell or OCaml).
• Map, filter, etc.
• First class functions (though lifetimes can make this a bit awkward)
• Everything is an expression (well most things anyway).

Bad bits:

• “Point free style” and currying. IMO this is really elegant, but also makes code difficult to read very quickly. Not worth the trade-off IMO.
• No brackets/commas on function calls. Again this feels really elegant but in practice it really hurts readability.
• Global type inference. Rust requires explicit types on globals which is much much nicer.
• Custom operators. Again this is clever but unreadable.
• Small communities.
• Poor windows support (not a fundamental thing but it does seem to be an issue in practice for lots of functional languages).

They’re probably pretty good for CRUD apps, which do tend to be like 50% boilerplate, but also I also wouldn’t characterise them as “bullshit”. Boring maybe.

I think it’s both true that you can’t really write an entire app with just AI… At least not easily.

But also I don’t buy that AI doesn’t make me more productive. I’m not allowed to use it on my actual code but I have used it several times to generate one-off scripts and visualisations and for those it can easily save hours. They aren’t software I need to edit myself though.

Sure but you don’t normally run GCC or Clang directly; you make, and that normally does optimise. I think a closer example is CMake which doesn’t enable release mode by default.

MSVC is usually run from Visual Studio which makes it obvious which mode is being used so the default doesn’t matter so much.

As for “all the other compilers”, Go optimises by default. It does seem to be the exception though…

It’s slower for two very good reasons (better static analysis and better feedback).

Apparently that’s not really the reason. cargo check is usually quite fast.

I also wouldn’t say Rust code is slower than C. It wins in some places (e.g. strict aliasing) and loses in others (e.g. bounds checks) but in practice it’s usually much faster because it’s so much easier to use fast containers (not just linked lists everywhere), fast libraries, and multithreading.

Tbf this mistake comes up so often I do wonder if cargo should have defaulted to release builds. It seems to be what beginners expect.

Definitely a promising language, and I tried to write something with it a year or so ago. It’s clearly still in the “research language” phase though; “hello world” took about 2 minutes to compile.

Headache isn’t a word I’d associate with Rust. More with Ruby or Python (at least until uv mostly saved us).

Yeah I agree. Presumably they don’t do that though because you’d end up with pages of nothing but ).

I never understood why they don’t add just a little syntactic sugar. You don’t need much to take it from a mess of brackets to something comprehensible.

Rust is fairly well known for not having footguns (except async Rust at least) and for not being a headache.

I guess it can be more complex than something like Python or Typescript though. I would say that extra complexity is not a big deal compared to the pain you’ll have to deal with working with a language as niche as Nim though.

I just use Rust for this. You can make the binaries fairly small if you put a bit of effort in. Plus it’s not a niche language, and you get the benefit of a huge community. And your code is pretty much fast by default.

The only real downside is the compilation time, which is a lot better than it used to be but still isn’t great.

I dunno I would say Lisp syntax is probably the worst option. Or APL style.

Seems like they allow () code blocks too, so it’s kind of the worst of both worlds…

That’s… not how hashes work. 🤦‍♂️

This goes against what we know about good design. Where possible you shouldn’t need to use a manual. Telling people to always read the manual is a cop out.

Also he apparently read his furnace’s manual and months/years later remembered what a flashing light meant, despite never having had to refer to it again? Either this guy has freakishly good memory (possible but unlikely) or he’s bullshitting. Given the overall tone I’d go with the latter.

And what is even the advantage of knowing in advance? Does he think people would not read the manual after seeing a flashing error light? You can look up most issues when they happen you don’t have to memorise error codes in advance.

This is just a dumb “I’m so great” post.

This is an unbelievably good explanation of some very difficult concepts. I think the Lean documentation should start with an enormous link to this post.

Highly recommended to anyone interested in Lean who isn’t already an expert.