13 ms·

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive coll

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together.

swyx 6y ago
this was historically true, but I suspect in the age of the evergreen browser this argument has been seriously dented (but not invalidated)
pjmlp 6y ago
Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.
- quickthrower2 6y ago
  What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.
  - pjmlp 6y ago
    Performance yes, there is always more power as long as the bank account is full, and even then it isn't enough when working at scale. The amount of histories of porting code prove otherwise. Note I am not pushing away dynamic languages, only those that don't have a JIT/AOT as part of their canonical implementation. Common Lisp, Julia, JavaScript, PHP (7 and later) are all invited to the party. Meanwhile maybe JRuby or PyPy will eventually get more community love, instead of being the black swans.
    - PetahNZ 6y ago
      But php doesnt have jit...
      - chaz6 6y ago
        JIT is coming to PHP in version 8.
        DonHopkins 6y ago
        Just In Time for 2020!
- AbuAssar 6y ago
  I’m interested in knowing more about your story. Would you please take the time to tell us more about it?
  - pjmlp 6y ago
    Not much to publicly tell. Portuguese startup based on our own version of AOLserver, based on the same principles of Apache plugins + Tcl + C, basically Rails before it was even an idea. We got acquired, by another bigger Portuguese company (Easyphone), which alongside another acquisitions became Altitude Software. Our stack was used to some of their products serving multiple top tier companies in Portugal, we created an IDE for our tools, written in VB. Supported all major UNIX flavours and Windows NT/2000. Eventually scale problems happened and we were looking how to tackle them while avoiding rewriting everything in C, as MSFT partner we got invited to try out .NET pre-public announcement, so we decided it was a good opportunity to rewrite our product in this new .NET thing. Some of the team members eventually took all these lessons and founded OutSystems.
blub 6y ago
They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating around the bush, but what they're getting at is that Rust + webdev = mismatch.
- cageface 6y ago
  Exactly. The frameworks aren't there yet but I think Typescript is pretty much ideal for web dev. We're still using dynamic languages for web dev for mostly legacy reasons now.
  - cies 6y ago
    Not sure if "ideal" is a good choice of word here. We dont know what's still coming. It surely has some flaws (many inherited from JS). There is stuff like ReasonML/Elm/PureScript that seems more ideal to me from a pure language (not eco sys, job/talent market, etc) perspective.
    - cageface 6y ago
      Yeah sure there are many better languages than TS in an absolute sense but TS is the only one I see with the momentum to displace the current incumbents.
  - te_chris 6y ago
    It's still a single threaded run time. There's one platform that's ideal for web, BEAM, but unfortunately it doesn't have a strongly typed language. Elixir and Erlang are both great languages though.
    - Multicomp 6y ago
      I can't speak to whether or not the BEAM is ideal for the web, but I will say I've been watching the Gleam project very closely because having static typing with the BEAM is a dream of mine.
quickthrower2 6y ago
This is probably true .... but watch out for Node with Typescript. You get that quite iteration, but with a decent amount of type safety most of the time, but with a drop down to the 'any' type for libraries that haven't written type definitions. I also use the existence of type definitions as a guide to how mature the library is :-), so that's a win win.
friendzis 6y ago
I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all costs. It may do something nonsensical, but it will try to chug along to completion without aborting. It creates a system where it is easy to write and deploy something that usually works.
- irjustin 6y ago
  I agree with both of you in that I don't think the direction of the origin really matters. The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings. If you have a highly federated space, you control everything and thusly can do cool things like Rust, Lua, what have you. But, most engineers don't get such a luxury. Languages that can be rapidly morphed to accommodate all those situations achieve shipped solutions to business problems faster. In the end, that makes money and that turns our world. Regardless, here's the loosely related XKCD's Standards: https://xkcd.com/927/ https://xkcd.com/927/
  - deleted 6y ago
    [deleted]
- CraigJPerry 6y ago
  Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TLS/HTTP/Ajax/Dom/JS engine/Server side graphql/rpc/rest / database... doesnt by you anything but slower iteration speed and an unwieldy schema. These components don’t have the same impedance, the same flavour to their design. Necessarily their schema would be a mess. Also, what stops something like function add(int a, int b) -> int { return a-b; } Typing is overrated. It has productive use cases for sure, but only in specific scenarios. It is no panacea. What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). Same argument for optional typing outside the main source code - odds on you’re going to misunderstand or misuse types, I’d like to use them where they make sense and ignore your steaming pile of types. Impossible in a language like haskell where types are inline rather than annotations attached to code.
entha_saava 6y ago
> This really nails why languages like PHP and Ruby have won out over static typed ... Real reason is lowering the bar of entry, and that explains why web is horribly broken. The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.
- afarrell 6y ago
  A lot of it is affordances. Every function signature is a user interface for your fellow programmer. And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.
  - entha_saava 6y ago
    Less testing, Documentation, Guarding against typos, better IDE support, better performance; But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier". The world would be nice if management people understood not all programmers are equal, the 10x programmer is not a myth. But here on HN or reddit you see most people arguing that all programmers are similarly productive. And what we get for this is more electron apps.
    - afarrell 6y ago
      > the 10x programmer is not a myth You are right that quality of programmer skill and productivity has high variance, but the way people talked about the "10x programmer" was a vague vision that people pasted their ideas and personal bugaboos onto. So people got into increasingly-heated arguments and talked past each other. When we create social concepts, we need to strive for something like falsifiability -- something that lets you look at an example and say "Well actually no, thats not 'high-performing programmer' behavior -- for {{describable reason}}" Categories matter. We should shape our categories for human happiness and human effectiveness, but categories matter.
jes5199 6y ago
I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me
- tluyben2 6y ago
  Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone some time ago'; I go check it and it's almost always something php/RoR/(and lately node) built by someone that left years ago and no-one touched it since because it works. When you actually do touch it, ofcourse, it is completely out of date, nothing current works and because of the flexibility of these languages and systems things change way too fast (really unneeded API breaks in packages is something crazy to me; coming from Java, I expect people to keep things backward compatible, but nope; just toss it out!) (especially node npm and least of all PHP which is actually a joy to work with in this kind of spelonking as it is remarkably stable including it's (older) libraries) (and no, not everyone uses a framework with php 'nowadays'; I run into many PHP projects a few years old that are just plain php, more so than frameworks used and that actually does make it easier to jump as plain php still works from a decade ago after update). And then when you have it running on your laptop, it usually is full of these 'corner cases' (lazy programmer input/output handling I would call it) which don't age well (and often hides bugs). On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.
  - 6y ago
ThePhysicist 6y ago
They are also evolving though. I don't know about Ruby and PHP but in Python gradual typing via type annotations really makes projects much easier to maintain and develop these days. While "mypy" (the semi-official type checker tool) still has a long way to go in terms of library support it works really well and helped me to find many issues by analyzing the code, as opposed to running it and finding the issues via tests (or in production). So I think typing has its merits and languages like Typescript really make development safer and code easier to understand, while still making it possible to write and interface with untyped code if necessary.
- Lio 6y ago
  > I don't know about Ruby Ruby is moving in the direction with the addition of Sorbet[1] for gradual typing. I have heard some discussion that this typing could become a formal part of Ruby 3.0. 1. https://sorbet.org/ https://sorbet.org/
rubber_duck 6y ago
Won ? Ruby fell off a cliff once it got to a point where people had to maintain that shit in production - I'm currently working on a large mature RoR codebase and I'm switching jobs ASAP because it's incredibly painful to work with and feels like a dead end career wise - and I like the gig otherwise - good product and a decent team - but the technology is draining so much of my life energy on nonsense it's ridiculous. And the language is built for unmaintainability - standard functions being abbreviated to a single letter, 2 or 3 aliases for a single standard function (map/collect and such), Rails overriding the conventions of the language (! postfix). And then there's the architectural retardation of fat models, fat controllers and using mixins ("concerns") completely break encapsulation - all actively killing code reuse- PHP has long been a meme and is mostly legacy stuff or bottom tier work. Dynamic languages are adding static optional static typing because the value provided by tooling as the projects scales is undeniable. It took ES6/TypeScript to drag JS out of the dump that it was with every library adding its own take on a class system - the maintainability jump from ES5 to TS is incomparable for anything larger than 1k LOC
- wwright 6y ago
  I say this a lot, but if you are this irritated by Rails, then you ought to see the 20+ year old legacy C/C++ some of us get to work with ;)
  - angrygoat 6y ago
    I'll see your legacy C/C++ and raise you legacy Fortran 77 :)
    - wwright 6y ago
      We needn't fill the young Rubyist's head with nightmares that deep, friend :)
  - cmrdporcupine 6y ago
    This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.
masklinn 6y ago
> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously useful pieces (type-safe enums to say nothing of full-blown sum types), nulls galore, … As a result, the gain in expressiveness and terseness (even without trying to code-golf) of dynamically typed languages was huge, the loss in type-safety was very limited given the choice was "avoid leveraging the type system" or "write reams of code because the language is shit", and the fast increase in compute performances more than compensated for the language's loss in efficiency. And that's before talking about the horror show that Java's web frameworks ecosystem was circa 2006. > Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together. That's really complete hogwash outside of the client, which isn't what we're talking about here since neither php nor ruby run there. On the server you have clear interfaces between "inside" and "outside", and there's no inflexibility to properly taking care of cleaning up your crap at the edges. Quite the opposite, really.
- cygx 6y ago
  because the representatives of statically typed languages at the time were Java and C++ And Pascal, Ada, Haskell, Eiffel, Standard ML, ...
  - zurn 6y ago
    Yep and on the dynamic side there were also Erlang, Python, Lua, Lisp, etc.
  - mathw 6y ago
    None of which really had mainstream visibility with the kind of people who actually made the decisions about what language your company would be using.
  - masklinn 6y ago
giantDinosaur 6y ago
I'm not sure this is really true - the subtleties of HTTP are not best handled with dynamic languages, and the actual HTTP API is fairly simple for most web app development. The areas with the most complexity related to the web, itself, are usually do with servers, concurrency, etc - precisely where these languages tend to fall apart.
vbezhenar 6y ago
Java, .NET, Golang are actively used for web development. PHP is popular, especially for small projects, but it definitely did not win, web development is a contested area.
- arcturus17 6y ago
  > PHP is popular, especially for small projects Not especially for small projects, for projects of all sizes - huge swathes of the internet still run on PHP, and it's not limited to blogs built on Wordpress. More than a few gigantic sites (Wikipedia and PornHub come to mind) are built with PHP. This is highly anecdotal but I still see the .php extension all over the place, sometimes in sites that perform really well BTW (again, Wikipedia is a good example here).
crimsonalucard9 6y ago
This is a mistaken view point. Every function you can ever write is bounded by a type, thus whether you use Ruby, PHP, or Rust can be described by a bounded type. Every time you write logic in your code, your brain is aware that the logic is dealing with a specific type. Writing a type signature on top of that is just additional instructions to the compiler about the type you have already specified in your logic. It is a minor inconvenience. There are many reasons why Ruby and PHP won out. One of the reasons is many people misunderstand the power and flexibility of types. Once they understand this, they will know there is really no trade off between statically typed and dynamically typed. Statically typed languages are infinitely better and the only downside is a minor inconvenience. First off, note that there is only one function in the universe that can really take every single type in existence and that function is shown below: -- haskell identity :: x -> x identity x = x # python def identity(x: Any) -> Any: return x This is the only untyped function in existence. Every other function in the universe must be typed whether it is typed dynamically or statically is irrelevant, either way your code will have to specify the type in logic or in the type signature. You can see this happening in the examples below... The above example have no logic to specify a type... The minute you start to add any logic to your function immediately your function becomes bounded by a type. Let's say I simply want to add one in my identity function. -- haskell identity :: Int -> Int identity x + 1 = x + 1 # python def identity(x: Int) -> Int: return x + 1 The very act of adding even the simplest logic binds your function to a type. In this case it binded my function parameter to an integer. Whether you use PHP or Ruby or Rust there is a type signature that describes all functions. Let's say I want to do garbage code like write a function that handles an Int or a String? That can be typed as well.... --haskell type IntOrString = Number Int | Characters String func :: IntOrString -> IntOrString func Number n = n + 1 func Characters n = n ++ "1" #python IntOrString = Union[str, int] def func(n: IntOrString) -> IntOrString: if isinstance(n, int): return n + 1 if isinstance(n, str): return n + "1" Let's say I want to handle every possible JSON api in existence? Well it can be typed as well. -- haskell type JSON = Number Float | Characters String | Array [JSON] | Map String JSON func :: JSON -> JSON func Array x = x ++ [1.0] func x = x -- python JSON = Union[float, str, List["JSON"], Dict[str, "JSON"]] def func(x: JSON) -> JSON: if isinstance(x, list): return x + [1.0] else: return x There really isn't any additional flexibility afforded to you by a dynamically typed language other than the slight overhead of translating the types you already specified dynamically into types that are specified statically. One caveat to note here (and this is specific to haskell) is lack of interfaces specific to record types. I cannot specify a type that represents every single record that contains at least a property named x with a type of int.
pjmlp 6y ago
Depends what one considers application level web development, over here it has been pretty much Java and .NET, with occasional C and C++ written libraries, during the last 20 years.

swyx 6y ago

this was historically true, but I suspect in the age of the evergreen browser this argument has been seriously dented (but not invalidated)

pjmlp 6y ago

Having ridden the 90's .com startup wave with an in-house application server written in a mix of Apache plugins and Tcl, I learned the hard way to never again rely on anything that doesn't bring a JIT or AOT compiler to the party.

quickthrower2 6y ago
What's the hard lesson? Performance? You have more power these days. The bottleneck won't be the interpreter.
- pjmlp 6y ago
  Performance yes, there is always more power as long as the bank account is full, and even then it isn't enough when working at scale. The amount of histories of porting code prove otherwise. Note I am not pushing away dynamic languages, only those that don't have a JIT/AOT as part of their canonical implementation. Common Lisp, Julia, JavaScript, PHP (7 and later) are all invited to the party. Meanwhile maybe JRuby or PyPy will eventually get more community love, instead of being the black swans.
  - PetahNZ 6y ago
    But php doesnt have jit...
    - chaz6 6y ago
      JIT is coming to PHP in version 8.
      - DonHopkins 6y ago
        Just In Time for 2020!
AbuAssar 6y ago
I’m interested in knowing more about your story. Would you please take the time to tell us more about it?
- pjmlp 6y ago
  Not much to publicly tell. Portuguese startup based on our own version of AOLserver, based on the same principles of Apache plugins + Tcl + C, basically Rails before it was even an idea. We got acquired, by another bigger Portuguese company (Easyphone), which alongside another acquisitions became Altitude Software. Our stack was used to some of their products serving multiple top tier companies in Portugal, we created an IDE for our tools, written in VB. Supported all major UNIX flavours and Windows NT/2000. Eventually scale problems happened and we were looking how to tackle them while avoiding rewriting everything in C, as MSFT partner we got invited to try out .NET pre-public announcement, so we decided it was a good opportunity to rewrite our product in this new .NET thing. Some of the team members eventually took all these lessons and founded OutSystems.

blub 6y ago

They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating around the bush, but what they're getting at is that Rust + webdev = mismatch.

cageface 6y ago
Exactly. The frameworks aren't there yet but I think Typescript is pretty much ideal for web dev. We're still using dynamic languages for web dev for mostly legacy reasons now.
- cies 6y ago
  Not sure if "ideal" is a good choice of word here. We dont know what's still coming. It surely has some flaws (many inherited from JS). There is stuff like ReasonML/Elm/PureScript that seems more ideal to me from a pure language (not eco sys, job/talent market, etc) perspective.
  - cageface 6y ago
    Yeah sure there are many better languages than TS in an absolute sense but TS is the only one I see with the momentum to displace the current incumbents.
- te_chris 6y ago
  It's still a single threaded run time. There's one platform that's ideal for web, BEAM, but unfortunately it doesn't have a strongly typed language. Elixir and Erlang are both great languages though.
  - Multicomp 6y ago
    I can't speak to whether or not the BEAM is ideal for the web, but I will say I've been watching the Gleam project very closely because having static typing with the BEAM is a dream of mine.

quickthrower2 6y ago

This is probably true .... but watch out for Node with Typescript. You get that quite iteration, but with a decent amount of type safety most of the time, but with a drop down to the 'any' type for libraries that haven't written type definitions. I also use the existence of type definitions as a guide to how mature the library is :-), so that's a win win.

friendzis 6y ago

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all costs. It may do something nonsensical, but it will try to chug along to completion without aborting. It creates a system where it is easy to write and deploy something that usually works.

irjustin 6y ago
I agree with both of you in that I don't think the direction of the origin really matters. The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings. If you have a highly federated space, you control everything and thusly can do cool things like Rust, Lua, what have you. But, most engineers don't get such a luxury. Languages that can be rapidly morphed to accommodate all those situations achieve shipped solutions to business problems faster. In the end, that makes money and that turns our world. Regardless, here's the loosely related XKCD's Standards: https://xkcd.com/927/ https://xkcd.com/927/
- deleted 6y ago
  [deleted]
CraigJPerry 6y ago
Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TLS/HTTP/Ajax/Dom/JS engine/Server side graphql/rpc/rest / database... doesnt by you anything but slower iteration speed and an unwieldy schema. These components don’t have the same impedance, the same flavour to their design. Necessarily their schema would be a mess. Also, what stops something like function add(int a, int b) -> int { return a-b; } Typing is overrated. It has productive use cases for sure, but only in specific scenarios. It is no panacea. What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). Same argument for optional typing outside the main source code - odds on you’re going to misunderstand or misuse types, I’d like to use them where they make sense and ignore your steaming pile of types. Impossible in a language like haskell where types are inline rather than annotations attached to code.

entha_saava 6y ago

> This really nails why languages like PHP and Ruby have won out over static typed ... Real reason is lowering the bar of entry, and that explains why web is horribly broken. The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.

afarrell 6y ago
A lot of it is affordances. Every function signature is a user interface for your fellow programmer. And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.
- entha_saava 6y ago
  Less testing, Documentation, Guarding against typos, better IDE support, better performance; But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier". The world would be nice if management people understood not all programmers are equal, the 10x programmer is not a myth. But here on HN or reddit you see most people arguing that all programmers are similarly productive. And what we get for this is more electron apps.
  - afarrell 6y ago
    > the 10x programmer is not a myth You are right that quality of programmer skill and productivity has high variance, but the way people talked about the "10x programmer" was a vague vision that people pasted their ideas and personal bugaboos onto. So people got into increasingly-heated arguments and talked past each other. When we create social concepts, we need to strive for something like falsifiability -- something that lets you look at an example and say "Well actually no, thats not 'high-performing programmer' behavior -- for {{describable reason}}" Categories matter. We should shape our categories for human happiness and human effectiveness, but categories matter.

jes5199 6y ago

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me

tluyben2 6y ago
Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone some time ago'; I go check it and it's almost always something php/RoR/(and lately node) built by someone that left years ago and no-one touched it since because it works. When you actually do touch it, ofcourse, it is completely out of date, nothing current works and because of the flexibility of these languages and systems things change way too fast (really unneeded API breaks in packages is something crazy to me; coming from Java, I expect people to keep things backward compatible, but nope; just toss it out!) (especially node npm and least of all PHP which is actually a joy to work with in this kind of spelonking as it is remarkably stable including it's (older) libraries) (and no, not everyone uses a framework with php 'nowadays'; I run into many PHP projects a few years old that are just plain php, more so than frameworks used and that actually does make it easier to jump as plain php still works from a decade ago after update). And then when you have it running on your laptop, it usually is full of these 'corner cases' (lazy programmer input/output handling I would call it) which don't age well (and often hides bugs). On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.
- 6y ago

ThePhysicist 6y ago

They are also evolving though. I don't know about Ruby and PHP but in Python gradual typing via type annotations really makes projects much easier to maintain and develop these days. While "mypy" (the semi-official type checker tool) still has a long way to go in terms of library support it works really well and helped me to find many issues by analyzing the code, as opposed to running it and finding the issues via tests (or in production). So I think typing has its merits and languages like Typescript really make development safer and code easier to understand, while still making it possible to write and interface with untyped code if necessary.

Lio 6y ago
> I don't know about Ruby Ruby is moving in the direction with the addition of Sorbet[1] for gradual typing. I have heard some discussion that this typing could become a formal part of Ruby 3.0. 1. https://sorbet.org/ https://sorbet.org/

rubber_duck 6y ago

Won ? Ruby fell off a cliff once it got to a point where people had to maintain that shit in production - I'm currently working on a large mature RoR codebase and I'm switching jobs ASAP because it's incredibly painful to work with and feels like a dead end career wise - and I like the gig otherwise - good product and a decent team - but the technology is draining so much of my life energy on nonsense it's ridiculous. And the language is built for unmaintainability - standard functions being abbreviated to a single letter, 2 or 3 aliases for a single standard function (map/collect and such), Rails overriding the conventions of the language (! postfix). And then there's the architectural retardation of fat models, fat controllers and using mixins ("concerns") completely break encapsulation - all actively killing code reuse- PHP has long been a meme and is mostly legacy stuff or bottom tier work. Dynamic languages are adding static optional static typing because the value provided by tooling as the projects scales is undeniable. It took ES6/TypeScript to drag JS out of the dump that it was with every library adding its own take on a class system - the maintainability jump from ES5 to TS is incomparable for anything larger than 1k LOC

wwright 6y ago
I say this a lot, but if you are this irritated by Rails, then you ought to see the 20+ year old legacy C/C++ some of us get to work with ;)
- angrygoat 6y ago
  I'll see your legacy C/C++ and raise you legacy Fortran 77 :)
  - wwright 6y ago
    We needn't fill the young Rubyist's head with nightmares that deep, friend :)
- cmrdporcupine 6y ago
  This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.

masklinn 6y ago

> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously useful pieces (type-safe enums to say nothing of full-blown sum types), nulls galore, … As a result, the gain in expressiveness and terseness (even without trying to code-golf) of dynamically typed languages was huge, the loss in type-safety was very limited given the choice was "avoid leveraging the type system" or "write reams of code because the language is shit", and the fast increase in compute performances more than compensated for the language's loss in efficiency. And that's before talking about the horror show that Java's web frameworks ecosystem was circa 2006. > Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you to quickly iterate through the process of gluing them together. That's really complete hogwash outside of the client, which isn't what we're talking about here since neither php nor ruby run there. On the server you have clear interfaces between "inside" and "outside", and there's no inflexibility to properly taking care of cleaning up your crap at the edges. Quite the opposite, really.

cygx 6y ago
because the representatives of statically typed languages at the time were Java and C++ And Pascal, Ada, Haskell, Eiffel, Standard ML, ...
- zurn 6y ago
  Yep and on the dynamic side there were also Erlang, Python, Lua, Lisp, etc.
- mathw 6y ago
  None of which really had mainstream visibility with the kind of people who actually made the decisions about what language your company would be using.
- masklinn 6y ago

giantDinosaur 6y ago

I'm not sure this is really true - the subtleties of HTTP are not best handled with dynamic languages, and the actual HTTP API is fairly simple for most web app development. The areas with the most complexity related to the web, itself, are usually do with servers, concurrency, etc - precisely where these languages tend to fall apart.

vbezhenar 6y ago

Java, .NET, Golang are actively used for web development. PHP is popular, especially for small projects, but it definitely did not win, web development is a contested area.

arcturus17 6y ago
> PHP is popular, especially for small projects Not especially for small projects, for projects of all sizes - huge swathes of the internet still run on PHP, and it's not limited to blogs built on Wordpress. More than a few gigantic sites (Wikipedia and PornHub come to mind) are built with PHP. This is highly anecdotal but I still see the .php extension all over the place, sometimes in sites that perform really well BTW (again, Wikipedia is a good example here).

crimsonalucard9 6y ago

This is a mistaken view point. Every function you can ever write is bounded by a type, thus whether you use Ruby, PHP, or Rust can be described by a bounded type. Every time you write logic in your code, your brain is aware that the logic is dealing with a specific type. Writing a type signature on top of that is just additional instructions to the compiler about the type you have already specified in your logic. It is a minor inconvenience. There are many reasons why Ruby and PHP won out. One of the reasons is many people misunderstand the power and flexibility of types. Once they understand this, they will know there is really no trade off between statically typed and dynamically typed. Statically typed languages are infinitely better and the only downside is a minor inconvenience. First off, note that there is only one function in the universe that can really take every single type in existence and that function is shown below: -- haskell identity :: x -> x identity x = x # python def identity(x: Any) -> Any: return x This is the only untyped function in existence. Every other function in the universe must be typed whether it is typed dynamically or statically is irrelevant, either way your code will have to specify the type in logic or in the type signature. You can see this happening in the examples below... The above example have no logic to specify a type... The minute you start to add any logic to your function immediately your function becomes bounded by a type. Let's say I simply want to add one in my identity function. -- haskell identity :: Int -> Int identity x + 1 = x + 1 # python def identity(x: Int) -> Int: return x + 1 The very act of adding even the simplest logic binds your function to a type. In this case it binded my function parameter to an integer. Whether you use PHP or Ruby or Rust there is a type signature that describes all functions. Let's say I want to do garbage code like write a function that handles an Int or a String? That can be typed as well.... --haskell type IntOrString = Number Int | Characters String func :: IntOrString -> IntOrString func Number n = n + 1 func Characters n = n ++ "1" #python IntOrString = Union[str, int] def func(n: IntOrString) -> IntOrString: if isinstance(n, int): return n + 1 if isinstance(n, str): return n + "1" Let's say I want to handle every possible JSON api in existence? Well it can be typed as well. -- haskell type JSON = Number Float | Characters String | Array [JSON] | Map String JSON func :: JSON -> JSON func Array x = x ++ [1.0] func x = x -- python JSON = Union[float, str, List["JSON"], Dict[str, "JSON"]] def func(x: JSON) -> JSON: if isinstance(x, list): return x + [1.0] else: return x There really isn't any additional flexibility afforded to you by a dynamically typed language other than the slight overhead of translating the types you already specified dynamically into types that are specified statically. One caveat to note here (and this is specific to haskell) is lack of interfaces specific to record types. I cannot specify a type that represents every single record that contains at least a property named x with a type of int.

pjmlp 6y ago

Depends what one considers application level web development, over here it has been pretty much Java and .NET, with occasional C and C++ written libraries, during the last 20 years.