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.
I would suppose they do and are free to do it - however, liberally having to spread it all over the code hurts readability. I'm sure people can say in response to that after a while you stop noticing or that their favorite IDE can collapse it and so on. It can be excuses all the way down instead of admitting that it is a shortcoming of the language.
You say it hurts readability but most of the time I want the unhappy paths to be visible.
Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly.
All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors that don’t mean much to anyone bar the core maintainer. But I seldom see 3rd party Go software bomb out in quite the same way. And I think that’s in large part because Go doesn’t try to hide errors away as an inconvenience that we shouldn’t be looking at.
So I’ll agree Gos approach is ugly. But sometimes good software does just look ugly. And the way I see it, it’s the quality of the compiled software that matters more than the beauty of the combination of characters that built it.
I am not questioning it's effectiveness. I have written Go code that is chugging along without issues in Production. My point is ergonomics and effectiveness are not mutually exclusive - hence the example of Rust's ? operator - effective and ergonomic (Rust also has issues with difficult to read lifetime+trait annotations).
The sad part is that people have been talking about this for years but Go team stubbornly refuses to make error handling more ergonomic.
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.
Because using the particular framework in my experience once you have a basic grasp of it's concepts, makes development time of applications extremely fast. Delivering is what pays the bills.
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.
> Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke.
So is Python's yet the language is enjoying great success.
> All the builtin functions still have no namespaces, and no forced types.
And no PHP developer cares, because neither does C and yet it's doing just fine.
> PHP still coerces strings to ints and vice versa.
Which is great for beginners, because they don't need to worry about it, unlike me when I program in Rust and have to deal with 8+ number types.
> PHP still has serious bugs with its (only) collection, the frankenstein ARRAY.
So does JavaScript, yet it's not enough to stop the language.
> IIRC doing a array_filter is still broken on PHP8 for key val arrays.
There is some odd behavior if you try to do certain things in a functional style that is actually true.
> 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.
That can get annoying in some use cases, I have developed many international web apps in PHP, it rarely got in my way, but I do acknowledge that it's not great to not have Unicode by default, I suspect they are afraid to resolve this after seeing what happened with Python 3.
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.
OCaml doesn't monomorphize functions. Instead references to every type are the same size (either a tagged int or a pointer). This is a sweet spot for OCaml, but doesn't really work for a language that doesn't allocate everything on the heap.
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.
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?
(which can be written in other editors: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... vim, VSCode with LSP support, Jetbrains, Atom/Pulsar, Sublime, Jupyter notebook…) (just saying to not scare people. Emacs is still the best for CL IMO)
Please, netizen, educate yourself. Common Lisp is written in many places outside of Emacs.
If you want to wear your underwear as a hat, that's your own business. Don't blame Common Lisp, or the array of editors which have nice support for it.
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.
Rust is also not the same as C, and therefore shall not be compared to it. Crabs to Cats.
Of course they are not same; that's why we want to compare them in the first place: were they the same, there'd be no need to compare them at all. Since, you know, they would be same and have no differences.
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.
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.
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:
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.
Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo->bar. There really have been both more invasive and more Java-style features in the past than this one.
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.
> I now cant tell if im accessing a property or a getter.
But you never could have been sure for the last 20-ish years either? What if my library you're using (and you can be certain at least one of them does) includes a class like this:
class Foo
{
public function __get($prop) {
return match ($prop) {
'bar' => $this->doSomeHeaveIoOp(),
'baz' => query_db()
default => throw new RuntimeError('Invalid property ' . $prop)
};
}
}
The difference to a proper getter is that you never knew Foo supported the virtual properties "bar" and "baz"; the only chance you'd have was if I added doc comments, or a note in the documentation; otherwise, good luck finding it in the source code. Compare to:
class Foo
{
public string $bar
{
get => $this->doSomeHeaveIoOp();
}
public string $baz
{
get => query_db();
}
}
This is definitely better. It is discoverable by both you and your IDE; it allows proper documentation; it is not magic, but code; it won't go out of sync with the __call handler; it allows static analysis and typing.
> 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.
Without any kind of property overloading, you're missing out on a lot of API simplification that other languages have long taken for granted. You may not like it, by stuff like pandas in Python wouldn't be possible at all without heavy overloading, and I prefer a world with pandas over one without it. Ergonomics are important; not writing tons of useless boilerplate code is, too.
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.
> It seems simplicity is just something everyone wants to abandon.
I think this very much depends on your perspective. "Simplicity" isn't a single dimension, you'll always face trade-offs at some point.
While the language did get slightly more complicated with the introduction of property hooks, they also simplify a lot of real-world code. Instead of handling all getter/setter logic inside two big functions, there's now a direct relation between each property and its getter/setter logic. There's a lot of value in that!
Of course you can say that's not good practice and therefore shouldn't be made simpler, but then you're still offloading complexity onto the individual program and developer. They are using these features in production code, and keeping the language simpler means that every class using getters/setters has its own custom logic. That's not simple at all!
To give a real-world example, Typescript supports many things that probably wouldn't be necessary if the language were designed from the ground up. But it's meant to add type safety to Javascript, so it has to support adding types to patterns that aren't best practice. But this also simplifies adding types to the existing ecosystem by a large margin, which is arguably the reason it has become the de-facto best practice for writing frontend apps.
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.