shikck200

Jane street was/is a top user of ocaml, they kind of flushed their reputation down the toilet with they massive fraud in the asian markets. IIRC the entire company got banned from trading inside India, hongkong etc.

After they got caught most of their online posts/videos either got deleted, or locked so you could not comment on them.

I had hoped their front guy for ocaml, Ron Minsky had atleast made some sort of statement. Currently no ones know how deep that fraud went, but what we know ocaml was used in the fraud, damagine ocaml ecosystem too.

Thats pretty sweet.

How does the repl work? Does it compile to Go, then execute? Or does it ship with a full vm? Most go repls are really slow because they need to compile/execute (they fake the "e" part in repl). Its a niche case, but could enable some fun projects.

Why is this not the default? I removed homebrew years ago, because it was just full of nasty surprises like this. Does homebrew still share dependencies? Previously you could not have package A with a transitive dependency of lib-X = v1.2 and B that requires lib-X = v.0.7.

Paywalled.

Ocaml is just an ML in the traditional sense. It keep scope without curlies. There is really not much else to it.

Lisette actually looks really nice! I huge improvement over Go (even i am really fond of the go runtime)

There is many "like react" things out there. I avoid full fledged frameworks like the pest, but something like solid.js is probably the one that matches how i think of webdev.

I have aliases for these kinds of general things (in vim) for most languages i use. Eg. if im inside a typescript file i have a mapping produces if ($obj) { $ } and i tab to enter the next "$" to insert the correct things.

The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block.

I dont understand why people dont use this kind of thing for the most common programming constructs.

Why is the only PHP defence i hear always the same "use a framework!". I did those for decades, and they always end up sucking. Either you need to hack around them, they have shitty defaults and finally they are abandoned and bitrot without any way of rewriting because of the huge size of the app.

How about just write the code, using the stdlib and picking highly focused libraries for things you dont want to write (crypto, drivers etc.) your self.

Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke. All the builtin functions still have no namespaces, and no forced types. PHP still coerces strings to ints and vice versa. PHP still has serious bugs with its (only) collection, the frankenstein ARRAY. IIRC doing a array_filter is still broken on PHP8 for key val arrays. PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.

Real numbers is hard to measure with PHP. This is because of the weird world of CMS systems (like wordpress). From all PHP code out there WordPress is most likely taking 80% of all the online deployments. So is it really PHP anymore? Its just a UI you click, drag and drop and customize. You dont even have to touch any code.

IF this is the measure, why not count PHP as C, as its written in C?

I stil argue that a single javascript library (jQuery) is MORE popular in 2025 than all PHP installations combined. Take that for scale. Now add all javascript (non compiled) and it trumps PHP by a factor of 100.

Indeed. Ocaml is GC'd, and that makes the implementation different. However, the question was about compile times, and i dare to say Ocaml is one if the fastest ones out there, even tho it has an rich and expressive typesystem. The conclusion then needs to be that the type system expressiveness (complexity?) does not alone make for slow compile times.

Ocaml

Some issues with pagination. I would recommend a non limit offset combo. Right now i get an error: "You tried to access /world/" when manually change the offset.

My first impression was the same. Mostly from the screenshots, each one had multiple places with an "emacs" text element. If this is not bound to emacs, what the hell is the emacs thing doing there?

The author clearly does not weigh in on the "whys" some things work in Go like they do.

So, adding an extra struct field results in the base value, and by design this should be used as a base default. The go proverb make base values useful goes hand in hand.

Obviously functions are not the same. And calling function with the wrong args is a compile time error. There is also CI check that check for this use case.

Overall this seems like a comparison to Rust, and its obvious they are not same same. Apples to Oranges.

That was a ballpark estimation, and while pure req/sec is usually irrelevant, it still comes in when the load starts to increase and you need to squeeze every last drop of perf.

PHP usually is doing poorly, even with its "cache", and when you realize that PHP devs actually are not PHP devs, but framework (like laravel/symfony) devs you need to account for the overhead of the framework too.

But you can have a look at the framework benchmarks game:

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

Its obvious that this has been possible before. It always was bad practice to do so, no matter of the language. I for see people starting returning `$this` and having these really complex chains of getters. Its going to turn into even more spaghetti, because now there is two syntaxes for basically doing the same thing. It seems simplicity is just something everyone wants to abandon.

I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core.

but you’ll never have to use them

But i do. I now cant tell if im accessing a property or a getter. With custom functions (like getFoo()) it was annoying, but still obvious, now its just magic and library authors will 100% start to abuse this feature allover.

Seems like that requires some sort of ad-hoc PHP extension. These are not in the standard PHP distribution? I would not want to rely on some random PHP extension that maintained by a single guy for anything production grade. Compare that to something like tensorflow thats backed by a HUGE community of maintainers.

Does anyone really FTP files like its 2003? Even in PHP you deploy with some sort of tool, like docker etc. The reload page thing is pretty much solved in all languages with a watcher. entr is a universal one, thats written in C and fast as anything.

The thing (most) other languages have is unicode support and concurrency. In PHP there is basically none of these.

Fast? You mean fast as in CPU bound tasks? 99.99% of PHP code is slow because of IO, and without any concurrency all the other languages beat PHP easily. If you need CPU bound work, you would not pick PHP (or any other scripting language) anyway.

In most benchmarks PHP (with Laravel/Symfony) is barely doing 500req/sec. Compare this to languages in the same space (like nodejs/python) and they run the same program and can serve 10K-30K req/sec.

Having said that python (a slow langauge) is still capable of doing heavy CPU bound tasks with libraries like numpy. Im not aware if PHP can install C dependencies with composer, like you can with pip.

Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.

See my above comment for a semi detailed version of how we do things.

We started small. And prototyped with just a single feature.

Basically we generate code in our src folder under a reserved namespace, and other PHP code can then use that code with imports. As we grow, we might want to split this into separate compilation units (we are not there yet, as the Haxe compiler is really fast!)

At the moment the generated PHP code is checked in source control, again we might want to have this done in CI, but it works kind of nicely at the moment.

The tricky bits are how to "speak" to PHP. Haxe is a really nice functional language (even its syntax is traditionally class based, but you can have module level fields in Haxe since 2020), so its pretty annoying to handle option types etc from the PHP side. We are still not decided on this part, and many APIs expose duplicate functions for some general task, like foo and foo_exn, and the one that ends with _exn throws instead of returning a variant (like option/maybe etc)

Also, its tricky to design where data is fetched from. We tend to keep the Haxe code as pure as possible, and only taking input and returning output (not doing any IO). We also write our own typings for externals, this has actually been really good for us, as we can observe easily what we actually use, and if we can remove some dependency that has some one feature we only use.

Overall, im amazed not more PHP devs look into Haxe as its basically a better version of what is TypeScript > JavaScript. Also there is no other compile to PHP language im aware of that ha the same robustness and features Haxe has.

We actually target a HUGE legacy PHP codebase (its over 16 years old, with over 1M LOC) with Haxe. I would not EVER write vanilla PHP for anything else than a toy website, because there is no amount of testing that makes it stable enough.

We still have a lots of legacy PHP, but its slowly being refactored to Haxe. With Haxe we get a really nice typesystem, and a "faster than Go" compiler. It has pushed our productivity thru the roof.

We still need to use external dependencies tho, as PHP lacks any concurrency in the core language, so we also have a Go API for fetching data concurrently, and also use it as a BI directional socket for the frontend and as a queue server.

Otherwise, the stack is pretty much PHP7 from top to bottom.