Hacker News Reader

Comment by m712 | Hacker News Reader

I have been waiting for a strongly typed mainstream high level language for a long time (TypeScript doesn't count because all type information is stripped during runtime). PHP still has a lot of cruft that prevents me from using it in my projects, but the recent updates seem like a step in the right direction. Hope that by PHP 8 the language will have deprecated more of the bad stuff.

View on HN

> TypeScript doesn't count because all type information is stripped during runtime

What's the point of keeping this information around at runtime if you do all your type checks at compile time?

Based on this categorisation, Haskell for example isn't a strongly typed language, and yet Haskell's type checking is one of its biggest selling points, so this doesn't seem quite right.

In practice, you don’t do all your type juggling at compile-time in even moderately complex libraries or applications. So TypeScript could certainly use better RTTI, I think. design:type metadata is insufficient.

Reflection is really useful. Right now the only way to differentiate types at runtime is testing for the existence of a key, which is kinda hacky.

> What's the point of keeping this information around at runtime if you do all your type checks at compile time?

It forces you to write input validation code that stays in sync with your types. Otherwise bad input can invalidate all your type guarantees.

You really don’t get most of the benefits “Strongly typed” languages here. A program that fails with type errors at runtime instead of compile time is the worst of all worlds.

Continuing to run with unexpected type coercion bugs could be worse than bailing out. So, worse than compile time checking, yes. But not the worst.

It just seems to imply that you need input validation code regardless of how your language is typed.

This will help you find type errors if you have good test coverage without explicitly testing for types. Makes tests shorter.

You can use third-party tools to check ahead of time, and you can fall back on the PHP runtime to catch what can't be caught in advance.

> A program that fails with type errors at runtime instead of compile time is the worst of all worlds

Better than silently failing! + if code fails early as these type checks can enable, then bugs are often (not always) picked up just by running the code once.

Typescript counts. Write well typed runtime code, get type safety and runtime safety. See io-ts as an example: https://github.com/gcanti/io-ts

why not Go/Java/....? Honest question.

Maybe they prefer optional OO over mandatory or no OO?

maybe? I wouldn't know.

"strongly typed mainstream high level language" does not say anything about that, hence my question.

At least for Java, PHP has the massive advantage of "change the code, save it and hit cmd+r" while Java, JavaScript and .net require recompiling, repackaging and deployment.

At work I develop for both PHP and Java projects and... it's cumbersome to develop for Java projects, to say it nicely. Ever tried developing for Jira, Jenkins or enterprise CMSes?

> while Java, JavaScript and .net require recompiling, repackaging and deployment.

Not to be a pedantic curmudgeon... actually, precisely to be a pedantic curmudegon... javascript does not require any of that.

The byzantine and asinine ecosystem that has sprouted like a cancer around javascript when SV and Node noticed the language and its profit potential, fueled by hype and unnecessary complexity? Yes. But the ecosystem is not the language.

Javascript itself is exactly like PHP in this regard - you edit a file, upload to the server, refresh the browser.

Everything else is unnecessary. Useful? Maybe. Bullshit? Probably. But not necessary.

I was recently surprised with this. I liked ThoughtWorks' tech radar. It's all client side JS, but uses node for some reason. Took longer than I expected to figure out the ecosystem (hadn't used node before), and it didn't appear to add much value for this use case. It also downloaded a boatload of node modules, and something called Cypress that takes forever to run. In the end it produces a fairly pedestrian client only SPA.

It's like the tale of the boiling frog. I don't like how with old school Javascript you have to add script tags to your html for each library you want to use, at some point you start using a bundler, then a package manager so you don't need to download them manually, then a compiler so you can use newer Javascript syntax, and so on and so on. Each step is better than the last one, but when you look back to the start things do seem simpler back then.

Since when does native/plain nodejs reload the source file(s) it’s running when they’re changed on disk?

I'm not talking about the limitations of Node.js, I'm talking about javascript as it's deployed to the web, from a server, running in the browser.

That use case, the one for which the language was intended, does indeed work as described, and has for decades.

Right, I didn’t get that at all from your original post.

sure, there are pros/cons in all languages. My question was specificly to the sentence about "strongly typed mainstream high level language" - as there are many languages who fit that definition.

C#?

C# + .NET Core 3.x + Blazor server-side. This is modern PHP.

I've gone all-in on the Microsoft stack and have not regretted a single moment of this decision. If one can put aside the "big evil company ecosystem bad" argument for just a moment, I think it would be very difficult to say another ecosystem is superior in terms of actual time-to-market for your product.

I tried C# + .NET Core recently, and while the core language was excellent, I found the library ecosystem severely lacking compared to the PHP and JavaScript ecosystems.

And some of the best libraries which did exist were under commercial licenses! Which generally isn't an issue in other ecosystems.

Reply on news.ycombinator.com