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.
https://www.mediaan.com/mediaan-blog/kotlin-vs-java Things like state of the art type inference, data classes and lambda syntax, no semi colon and ton of other things allow for reduced syntactic noise.
But I'd argue that, if you need to lean on compiler plugins to do it, it's sort of a rhetorical Pyrrhic victory.
As long as the platform exists, its main language is the one holding the keys.
On the JVM its novelty will fade out while Java adopts whatever features might be relevant to the millions of Java developers out there, just like it happened with all other that came before.
And I remember the days back when Groovy was supposed to be the scripting language for JEE, and Spring was going full speed with it as Java alternative, and we even got strongly typed variant.
The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language brings its own maintenance challenges. I can't speak to Ruby specifically, but, in practice, I haven't found that I'm all that much more afraid to change things in a large Python codebase than a large Java one.
I'm now coming to think that the real challenge is dynamicism in general, regardless of whether it's built into the language or implemented as a library solution. So, if Java has an advantage here, it's simply that it tends to discourage people from overdoing it by making it awkward to do.
Sure, but if you don't reach market fast enough you'll have no reason to slog through anything, period. Can you imagine writing something like Facebook using Rust? It's an almost ludicrous proposition.
Static typing requires that you know what you're building at a relatively fine-grained level--how the pieces will fit together at the source code level, at least roughly. No amount of automated refactoring could ever match the flexibility of dynamic typing when you're just trying to bang out features, let alone explore the feature space, which almost by definition is what any novel solution is doing--exploring. That's why I love using embedded scripting, particularly Lua. You can gradually move components outside the dynamic environment as their place in the architecture becomes fixed and well understood.[1] So-called gradual typing doesn't really permit the same kind of flexibility because it's not the static typing, per se, that burdens development, but rather that static typing has the effect of forcing a more rigid hierarchy of higher-order abstractions and interface boundaries. What you want is the ability to slowly solidify the architecture from the outside to the inside, not the inside to the outside.
Microservices is another way to address the problem, at least in theory, but in practice doesn't actually directly resolve the real dilemmas. At best it just multiplies the number of environments in which you're faced with the problem, which can both help and hurt.
[1] Statically typed scripting languages seem rather pointless to me, and more a reflection of a fleeting fascination with REPL.
Building some or all of those backend APIs in Rust from day 1 would not be crazy, or less productive than any other language.
I think differences in proficiency drive bigger differences in productivity than inherent language differences.
So if you were starting today to build Facebook, using a language you are already effective with would matter more than which language you use (there are plenty of people out there for whom that could be Rust, or Haskell, or Ruby, or PHP, etc).
Rust lets me make sure my code still works through refactors and code changes. With PHP I could easily break something that would only cause an error when that code actually runs. That's right, there is no sanity check at all until the parser reads that code.
I was involved in developing large PHP and Rubby codebases and its so hard to maintain.
These days I just use SpringBoot. It strikes a good balance between providing speed to market (PHP/Ruby), maintainability and performance (the next version should support GraalVM). Cant complaint so far.
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
C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.
It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.
It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task
What I mean to say is that with a monorepo, you leave the door open to essentially passion-driven contributions made by the other half of that 2%. In non-monorepo environments, the barrier to uniform adoption is too high for someone that isn't full-time assigned to the task to justify.
Some people are genuinely passionate about this stuff, and want to take on the task of migrating the entire code base, because it's a fun challenge and it'll improve their day-to-day work every day for the remainder of their employment. They're very rare, but they do exist, and with a monorepo those people are better-equipped to drag the company forward.
I have some news - passion is not enough, and there are more than 2% of people working on things they are passionate about - it only 2% get lucky.
I can think of a few instances in my recent career at large monorepo company where I have built something on the scale of "passionate, could improve our working lives"
One died because ... well I gave up, two are used locally by my team and those I could persuade, whilst other solutions built by others for the same fix have gone on to be blessed officially, (ie replaced by grassroots competition) and one was replaced by a fully mandated and funded project that spotted the need and just steamrollered over all the local fixes.
One is still outstanding and I think well worth pushing still.
But I don't dream of the big win where suddenly the Board says "why, without your glasses Miss Moneypenny you look ravishing".
I get paid, I work, and I try and make the world a bit better where I can. I am passionate about it. But i don't write blog posts about how passionate I am.
Maybe I should :-)
As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)
It's been used at every workplace I've been at, sometimes well, sometimes not so well, just like any language. No idea what the point of blanket statements like this is.
https://w3techs.com/technologies/details/pl-php claims ~79% of websites whose backend is known use PHP.
https://w3techs.com/technologies/details/pl-ruby shows Ruby has grown from 2.5-3.5% over the last year.
Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.
But now that I'm older, I appreciate things being more descriptive and orderly, including strict use of semicolons, functions that say what they are doing (e.g. to_string), or being explicit about converting (e.g. static_cast<type>)
I think it's because I find trying to make everything as succinct as possible ends up trying to be too clever.
Long-term memory is similar, while it's not bounded in the same way it takes time and effort to develop. I'd rather type `git new-branch` than have to remember `git checkout -b` and I certainly don't alias it to `git nb` or something: I can type `git n<TAB>` and let that complete it.
I find myself more annoyed by dynamic languages, because the tooling just isn't at the same level. All sorts of 'hints' that I rely on in java simply aren't there in other languages, and the ide throws up it's hands and is like '...? I guess this is right? Godspeed sir', and I wind up having to go lookup documentation rather than ctrl clicking into underlying functions and code. It's really annoying, and it's made me be more appreciative of staticly typed languages.
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.
However... software development has become a mess of slow technologies and abstractions one on top of the other.
Some people are working routinely in a text editor that is behind three operating systems: the VM/hypervisor, the usual operating system (Windows/macOS/Linux) and then a browser instance (which is like a operating system now). Then add all the drivers, libraries, frameworks etc. that go in-between.
While I don't like that WebAssembly is yet another abstraction, at least it is a chance for a resurgence of system programming languages and to proper software engineering...
I have been playing with Rust, but not sure about how good an idea it is for the front end yet though.
The problem here is the concept of SPA itself - it's a complete hack which is plastered over with various tricks to make it halfway usable. This has been going on for years now.
Websites on the other hand are slow because of the tracking and the ads which load tons of JS. Remove that and the web will be blazing fast.
With sufficient ad blocking and JS white listing, I can attest to this.
After removing ads and analytics, sites that rely on JavaScript to render significant amounts of content are the slowest.
Many of the things you say are true - Rust libraries in general need some love and polish before they can be beginner-friendly, but some are getting there. The difference between Diesel and Rocket, for example, is quite stark. The former has only the barest minimum 'examples' and 'guide', if they may be called that, and I feel like I'm expected to read and understand its source code to become really proficient with it. It takes a lot of experimenting and trial+error to do anything beyond the basics. Rocket, on the other hand, has a very comprehensive guide with useful examples and, so far, has been enjoyable to work.
That said, there are still a lot of "convenience" features missing. My current notable example is forms. As I'm doing it (I haven't looked into any addons to Rocket for this), I have to write out the HTML for the form myself, along with any Javascript I might require for validation, etc, then write the server-side methods for GET/POST, making sure to maintain the state myself. In this regard, something like Django's effortless ease to get a form on screen and store its data into a database really showcases where Rust (Rocket) still has a long way to go.
Hopefully, with more people using it, the tools and libraries will improve and mature, particularly the documentation.
When all is said and done, I enjoy "slogging" through Rust a lot more than I did working with Django, even with the slower progress. Something about this language really speaks to me.
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.
(1) Is "batteries included"
(2) Has the gem/engine ecosystem where basically every problem is already solved.
(3) Expressive code like has_many :things
If we could get those things + static typing + performance everyone would switch. But that doesn't exist.
Python is very "batteries included," and there is a large set of exisitng packages for most things. One can monkey-patch things and invent cute syntax, but most python is rarely hard to reason about what's actually going on.
It's easy to bag on parts of python (eg some syntax and terrible distribution story), but I feel much less crazy (and suspicious of every punctuation mark) when working on a modern python app than when working on a modern ruby app, especially in the presence of rails.
Java is fine as a programming language. Java as a web app more or less means Spring. And Spring means XML files and annotations which come with their own problems. Kind of an out of the pan and into the fire thing.
(alternatives like Vert.x, the less-annotation-heavy quarkus, etc).
For Java web dev I actually like Kotlin better - ktor is pretty nice.
First of all there is more to Java Web development than JEE and Spring, which in any case, other eco-systems don't have a mature answer for many of their deployment scenarios and cross system integrations.
XML is beautiful, there is yet a format that supports machine manipulation, IDE graphical tooling, comments, schema validation as XML.
Anyone that praises Rails will be right at home with XML and annotations magic.
And Pascal, Ada, Haskell, Eiffel, Standard ML, ...
None of the language you mention had any sort of wide-spread visibility at that time, meaning they were not representative of the (overwhelming) majority experience with statically typed languages.
That is not the timeline we're talking about here. Dynamically typed languages started taking off at the turn of the millenium and really exploded in the second half of the aughts. Java didn't even exist in the early 90s.
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.
I work on a large C# platform that interops with a ton of vendor API's, the majority of which are also written in typed languages. The disjointed, loosely coupled nature of web systems is what causes problems. In particular, knowing what a "correct input" is to web systems is very difficult, where correct means:
1) Passes the API's immediate validation
2) Passes validation inside API's longer running processes
3) Passes business rules (it might be correct types, lengths etc, but fails anyway because of an incorrect combination of API calls)
Some of our vendors use Elixir, some use PHP, many use C# or Java. I really don't notice any significant difference between them on that account. The issues are all down to the complexity of the software and business requirements and that the whole thing is a giant distributed system.
I cut my teeth programming an XML web service using soap and while I can't say that it was as drop-dead simple as a restful HTTP web api these days, between the wsdl and the uddi, it sure was convenient to be able to know as a client what methods were being exposed and what inputs they expected.
Sometimes I wish the w3c had not required XML for those web services ,so that we could do that with json plus whatever add-ons can make it have an enforceable schema like XML. WSDLs were underrated.
Attaching text in form of a script anywhere in the DOM can be abused, but it is also insanely practical. I don't think Javascript is too horrible. I think the whole toolchain to get minimized and bundled JS is. That is why I am wary of TypeScript. Yes, I see its benefits, but I don't like cross-compiling if I can just not do it.
Given, I am no web developer and my "projects" on the web are tiny. I completely understand someone who likes to take the increased effort to use TypeScript, especially if your project isn't just making a text blink. If it reaches a certain size, I would probaly look into it too.
Webassembly looks interesting, but will take some time to establish itself. There are also disadvantages to that, since it could reduce the openness of the web. All the tracking we are subjected to could only be inspected by network traffic instead of looking into the source.
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/
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;
}
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.
cmon... "it doesn't guard you against every logic error under the sun" isn't a great argument
Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.
There's no evidence proving the opposite either. We can't say anything beyond that the existing studies don't really show anything. I think it's pretty obvious that the limit of static typing reduces logic bugs (since it can actually be used to prove statements about the logic), but beyond that everything is kind of up in the air.
>Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.
There's nothing to support that that this is 'pretty likely'. As far as we know, it could very well be that statically typed languages push you in the direction of handling it the right way. Or hell, it could be that a team using a dynamic language is more cautious and conscious of edge cases.
>Also, what stops something like
having a more precise specification. E.g. adding a commutativity requirement would eliminate your example.
A contract system like clojure's spec sounds close to what you're describing.
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.
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.
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).
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.
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.
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.
The web was always meant to be a platform anyone could easily build on, whether they were experts or someone's little old grandma who barely knew what a keyboard was.
Not only is it gatekeeping, it's historically wrong and betrays a flawed understanding of the platform. The web has always been about ease of use and there have always been people who went out of their way to teach others how to make good use of it.
Yes, the web is broken, but the web is broken because it's no longer about everyone running a little shoebox of a server and instead now we depend on giants who see us as cattle.
And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.
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.
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.
Why?
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
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
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"
-- 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
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.