18 ms·

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a hu

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features. After all, it is their job. They are incentivized to keep making it more complex. The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me. One of the reasons I have so much fun working in node/Javascript these days is because it is simple and not much has changed in express/node/etc for a long time. If I need an iterable that I can simply move through, I just do `let items = [];`. It is so easy and hasn't changed for so many years. I worry that we eventually come out with a dozen ways to do an array and modern code becomes much more challenging to read. When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! This is probably just old man ranting, but I think there's something there. The old version I used to debate about was C vs C++. Now look at modern C++, it's crazy powerful but so jam packed that many people have just gone back to C.

pjmlp 2y ago
C23 has just been ratified, and C2y has already quite a few proposals. Programming languages are like any other software product, evolution or stagnation. Eventually they might implode, however whatever comes after will follow the same cycle yet again.
- seanw444 2y ago
  And branches [1] of C are still spawning and gaining traction, because C++ is perceived as overkill. [1]: https://github.com/c3lang/c3c https://github.com/c3lang/c3c
  - pjmlp 2y ago
    Spawning, yes. Gaining traction beyond a couple of blog posts in sites like HN, not really.
throw49sjwo1 2y ago
> And nobody uses most of it! Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.
- nosefurhairdo 2y ago
  Yeah I was confused by this point as well. Especially because many of the recent Typescript releases are just improving performance or handling more cases (without needing to learn new syntax).
- tannhaeuser 2y ago
  React and Expressjs predate typescript, Expressjs considerably so.
  - throw49sjwo1 2y ago
    Doesn't matter, I'm talking about the type definitions - @types/react, @types/react-dom and @types/express.
    - authorfly 2y ago
      No, those are optional for the enduser to ever encounter.
      - throw49sjwo1 2y ago
        I never said it's required. The typings are really useful if you want to use these libraries "with TypeScript" as I said in my first comment... The typings are the whole point - that's where the advanced type features are used, and every user benefits - their own code can be much simpler and safer thanks to it.
        authorfly 2y ago
adamc 2y ago
Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/ https://chrisdone.com/posts/tamagotchi-tooling/
- intothemild 2y ago
  The java tooling is the number one thing I hate about using the language. It's all just bad. Then. You get forced into using intelij because it seems to smooth over a lot of the toolings problems with "magic". It's horrible.
  - pjmlp 2y ago
    I use Eclipse and Netbeans of free will.
  - millipede 2y ago
    Saying this as probably the biggest Java fanboy I know: they are pretty bad. Gradle is pretty much the worst build system Ive used. IntelliJ might as well be folded into the JDK, because I don't think it's possible to be productive in Java without it.
  - rudy6912 2y ago
    Everything you said applies to Kotlin as well. Outside of IntelliJ, it is horrible to use. (Ditto Swift outside of Xcode.)
afavour 2y ago
I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple... in most scenarios you'll probably be better off using records rather than objects, and maybe that's what folks will end up doing. But boy does it all get confusing. > Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! I'm not so sure about that. I think we end up consuming a lot of these features in the TS types that get published alongside libraries. We just don't know it, we just get surprisingly intuitive type interfaces.
- thot_experiment 2y ago
  > but there's absolutely no reason to use var any more Naw, var has function scope and hoisting, both of which are useful.
  - afavour 2y ago
    Not in a sensible codebase
  - hinkley 2y ago
    My job isn't to be infatuated with your code. It's to get through your code and get stories done. People don't really get better at handling the complexity of large code bases. We are fundamentally the same organic matter that existed prior to the first computer coming into existence. So as code bases and library bases grow larger and larger, they need to be proportionately easier to read or even ignore. Your code needs to be dead boring 90% of the time, otherwise you're imposing on your coworkers. And using variables before they're declared is just shitty behavior.
    - thot_experiment 2y ago
      Sure and I'd accept the weaker claim that "there's no reason to use var in a production codebase touched by many people"
dartos 2y ago
At least typescript tooling hasn’t changed. It was a pain to set up when it came out and it still is. At least we moved past webpack mostly.
eddd-ddde 2y ago
This is why always say the true beginner programming language is C. Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).
- n_plus_1_acc 2y ago
  How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.
  - bobthepanda 2y ago
    Plenty of universities teach C every day even if that means specifying a compiler, and usually it’s a very boring compiler that gets chosen
    - n_plus_1_acc 2y ago
      Right, but all C courses I've done had UB in examples without mebtioning it. There teachers just didn't know what they are teaching.
      - bobthepanda 2y ago
        Unless you are writing a compiler and code specifically tailored to take advantage of UB, there’s not much to say about it other than “be careful about UB cause it can make your program buggy from your POV.”
  - lelanthran 2y ago
    > How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers. Right. Becuase no one ever learned C as a first language ever, and those that paradoxically did were worse programmers for it!
pier25 2y ago
> or more performant Obviously then can't make TS more performant (since it doesn't execute) but C# is very performant and even surpasses Go in the TechEmpower benchmarks.
- leetharris 2y ago
  Absolutely. I love C# and .NET, they are incredible and very fast. I just meant to say that they aren't only focused on performance, but also focused on new features. One of the best things .NET did was adding minimal APIs in .NET 6 (I think) that are more like Express. They removed a lot of boilerplate and unnecessary stuff, making it easier to start building an API.
- o11c 2y ago
  TS is pretty impressive in that its compiler is slower than C++ compilers though.
egnehots 2y ago
Try Go. Go is really stable as a language and have a very small core feature set.
- leetharris 2y ago
  This is easily the most appealing thing to me about Go. I learned Go through the "Learn Go with Tests" way and I had a ton of fun. It is hard for me to recommend using Go internally since .NET/Java are just as performant and have such a mature ecosystem, but I crave simplicity in the core libraries. Here's the link for anyone considering learning Go: https://quii.gitbook.io/learn-go-with-tests https://quii.gitbook.io/learn-go-with-tests
  - totallykvothe 2y ago
    .NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.
    - pjmlp 2y ago
      Specially if one is ignorant on how to write proper .NET and Java code.
    - BoppreH 2y ago
      And startup time. JIT languages are a bad match for command line applications, for example.
      - GOATS- 2y ago
        .NET can do ahead-of-time compilation now, there are a few gotcha's but it's usable. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8 https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
    - metaltyphoon 2y ago
      This is almost as bad as saying .NET is windows only.
dgellow 2y ago
Do you have examples of unreadable C#? The language didn’t change much IMHO. You have new features, like records, but C# code looks pretty much like what I started with in 2009
- leetharris 2y ago
  Now that I'm thinking about it, most of it is probably .NET bloat instead of C# bloat, but a few examples would be global usings, file scoped namespaces, records, target-typed new expressions, null coalesce assignments, etc. It's nothing huge, but combined with .NET bloat it can be overwhelming when you haven't worked in .NET for a while.
  - jenscow 2y ago
    and pattern matches, primary constructors, range operator, switch expressions, etc. it does add up
    - eknkc 2y ago
      I came to love pattern matching so much that now when I write TypeScript I get frustrated. It is a weird balance.
    - dgellow 2y ago
      All of this looks and feels like C#. That doesn’t look unreadable or a completely different language. In fact they end up making C# more readable by removing boilerplate
  - wvenable 2y ago
    All the things you describe make C# more readable and easier to understand! Are you really confused by file scoped namespaces or target-typed new or even null coalesce assignments? You don't have to use them -- although Visual Studio will helpfully suggest places you can use them. If I had never seen a pattern match switch statement before (and there was a point where I didn't) it's sort of immediately obvious what it does.
- 2y ago
BiteCode_dev 2y ago
Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets... It also has complex rules for: - scoping (plus global variables by default and hoisting) - "this" values (and manual binding) - type coercion (destroying commutativity!) - semi-column automatic insertion - "typeof" resolution On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM. There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway. There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.
- nwienert 2y ago
  This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons. That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.
  - BiteCode_dev 2y ago
    I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.
carlosrg 2y ago
Every programming language attempts to expand until it becomes C++. Those languages which cannot so expand are replaced by ones which can.
- goatlover 2y ago
  Go will resist this as long as possible.
  - rudy6912 2y ago
    Lua too. 30 years and counting!
munificent 2y ago
I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not too much for you to absorb. Likewise C# 3.0, 4.0, etc. As long as you stay on the C# train, the rate of new features does not exceed the rate that you can learn them. Years later, another person comes along and is new to C#, which is now at version 5.0. They are presented with a huge sprawling language and they have to learn nearly all of it at once to deal with codebases they are contributing to. It's a nightmare. They long for a language that's actually, you know simple. So maybe they find some other newer language, Foo, which is at 1.0. It's small and they learn the whole thing. After a couple of years of happy productive use, they realize they would be a little more happy and productive if Foo had just one or two extra little features. They put in a request. The language team wants happy users so they are happy to oblige. The user is easily able to learn those new features. And maybe some other Foo users want other new things. 2.0 comes out, and they can keep up. They can stay on the train with 3.0, 4.0, etc. They never explicitly asked for a complex language, but they have one and they're happy, because they've mastered the whole thing over a period of years. They've become part of the problem that bothered them so much years ago. Fundamentally, the problem is that existing users experience a programming language as the delta between the latest version and the previous one. New users experience a programming language as the total sum of all of its features (perhaps minus features it has in common with other languages you already know). If you assume users can absorb information at a certain fixed rate, it means those two cohorts have very different needs and different experiences. I don't think there's a silver bullet. The best you can hope for is that a language at 1.0 has as few bad ideas as possible. But no one seems to have perfect skill at that.
- spease 2y ago
  I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago. I think the only way to address what you're alluding to is to continually deprecate small parts of the language, so that upgrading is manageable for active codebases. And you probably have to be really aggressive about pushing this forward, because there will always be excuses about why you should hold back just this one time and this one feature is an exception that needs to be held back just a little bit longer. But in the long run, if you don't force people to change a little bit continuously, it will become a big enough issue to split the ecosystem. See python2 to python3. Or you end up forced into supporting bad practices for all eternity, like C++. And having to take them into account for every. Single. New. Feature. Further raising the barrier to entry to participation in developing the language to people who are completely focused on its development and have unusual mastery of it, who can't identify with the people struggling with its complexity. If not at the technical level, then at the business level, where people definitely don't have the time to understand why it'd be safer for the go-to heap allocation method should return a scoped pointer instead of a raw pointer. Unfortunately, this probably is only viable for strongly-typed languages like C#; for loosely-typed languages like Python, the risk of iterative changes is that if someone moves a codebase several generations ahead at once, it'll introduce lots of subtle changes that'll only become obvious once certain codepaths are exercised...and given how bad testing coverage is for a lot of software, that probably risks breakages only occurring once it's deployed, that are nontrivial to discern via reviews or even static analysis.
lelandfe 2y ago
It doesn't help how arcane the TS documentation is. Important docs live as frozen-in-amber changelog entries; huge tracts of pages "deprecated" yet still #1 on Google. Google "typescript interfaces." #1 is a page that has been deprecated for years. How did this happen?
- hsbauauvhabzb 2y ago
  AWS has that issue too - v1 documentation takes precedence over v2, the same with bootstrap, too. I suspect google algorithms don’t quite understand deprecation / latest version prioritisation.
- imbnwa 2y ago
  Can tell you right now a lot of important information about mapped types live in Github issues on the TS repo
- vundercind 2y ago
  Documentation where, somehow, every single thing you can find for some particular need is “deprecated” and it’s weirdly-difficult to find a complete set of docs not full of deprecated landmines mixed in with the current stuff, is kinda a Microsoftism.
lolinder 2y ago
> When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! TypeScript today can be written the same way that TypeScript was when it first started to become popular. Yes there are additions all the time, but most of them are, as you observe, irrelevant to you. They're there to make it possible to type patterns that would otherwise be untypeable. That matters for library developers, not so much for application developers. To the extent there's a barrier to entry, it seems largely one that can be solved with decent tutorials pointing to the simple parts that you're expected to use in your applications (and a culture of not overcomplicating things in application code).
- d13 2y ago
  As a very experienced TS developer myself - this is absolutely correct, the best reply in this thread, and I hope the OP reads it.
- tgv 2y ago
  TS is pretty good. In the beginning, I had to resort to 'any' frequently, but nowadays it's often possible to avoid that by writing some auxiliary types. It's not easy, but you can get quite far. JS without TS' safety net is a nightmare...
Waterluvian 2y ago
I also don’t know how to refine my thought but it’s something along the lines of: The people who are in a position to decide what features get added to a language are usually top experts and are unlikely to have any reasonable perspective on how complicated is too complicated for the rest of us. If you live and breathe a language, just one more feature can seem like a small deal. I think it becomes much more reasonable when that one more feature enables an entire set of capabilities and isn’t just something a library or an existing feature could cover.
- int_19h 2y ago
  For many languages these days, evolution happens in public, and you can look at those discussions and see how this sausage is made. If you do it for C#, if anything, the pattern is that relatively inexperienced users are the ones who propose features (to make some specific pet peeve of theirs easier), while the more experienced folk and especially the language designers who make the final call aggressively push back, point out corner cases, backwards compatibility, maintenance burden etc.
MathMonkeyMan 2y ago
What did Bjarne Stroustrup supposedly say? There are two kinds of programming languages: the ones everybody complains about, and the ones nobody uses. I'll put on my Scheme hat and say "with hygienic macros, people can add whichever language features they want." Maybe Rust is a good experiment along those lines: C++ with hygienic macros. Everything that people keep using grows into a monster of complexity: programming languages, software, operating systems, law. You must maintain backward compatibility, and the urge to add a new feature is too great. There's a cost with moving to the new thing -- let's just put the new thing in the old thing.
azangru 2y ago
> it has a huge barrier to entry You don't have to use every feature of the language. Especially not when you are just learning. > Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! Exactly. But no-one seems to be arguing that typescript has a huge barrier to entry.
breadwinner 2y ago
Couldn't agree more. More features in a programming language makes it easier and more fun to write code, but makes it harder to read and maintain someone else's code. Considering more time is spent maintaining code as opposed to writing it (assuming the product is successful), readability is more important than writability.
neonsunset 2y ago
> sometimes modern C# code from experts looks unreadable to me This is a culture issue and has always existed in C#, Java and C++ communities sadly (and I'm seeing this now with TS just as much, some Go examples are not beacons of readability either, I assume other languages suffer from this similarly). In the past, people abused BinaryFormatter, XML-based DSLs, occasionally dynamic, Java-style factories of factories of factories, abuse of AOP, etc. Nowadays, this is supplanted by completely misplaced use of DDD, Mediatr, occasional AutoMapper use (oh god, at least use Mapperly or Mapster) and continuous spam of 3 projects and 57 file-sized back-ends for something that can be written under ~300 LOC split into two files using minimal API, records and pattern matching (with EF Core even!). Neither is an example of good code, and the slow but steady realization that simplicity is the key makes me hopeful, but the slow pace of this, and new ways to make the job of a developer and a computer more difficult that are sometimes introduced by community and libraries surrounding .NET by MS themselves sour the impression.
Shiny_Gyrodos 2y ago
I'm an absolute beginner when it comes to programming, and I chose C# as my first language to learn. I've been learning steadily for 8 or so months now and at no point have I felt the language was unapproachable due to excessive features. Looking back on what each new version added, I don't think any of the additions were damaging to the simplicity of C#. I do likely have a biased perspective though, as I use newer C# features every day.
- ygra 2y ago
  > I do likely have a biased perspective though, as I use newer C# features every day I think that is kind of the point, though. Many of those newer features help with simplifying code and making it less boilerplate-y. To old programmers it is a simple code fix in the IDE to move from 30 lines of variable assignments in a switch to a 5 lines switch expression and they can learn that way. People new to the language typically won't even consider going the complicated route because they learned an easier way first. I do concede that having people with less C# experience on a team where modern C# is used, there will be constructs that are not immediately obvious. SharpLab has an “Explain” mode which would be helpful in such cases, but I haven't seen anything like that in IDEs: https://sharplab.io/#v2:C4LgpgHgDgNghgSwHYBoAmIDUAfAAgBgAJcBGAbgFgAoXAZmICZCBhQgb0M8Oq+PtwAshALIAKZIWTBCcFIXFJgc0vgCUhAEbq2PXl0GEAMqO269hAL5m913lMIRCAXkJowAMzgBXGMEpVzTgR3eQ1JAGdCADc4ACdo1VsuAEhSAE5RKNUyQNzuAK4rAs5rOklFQgAFZwA+Qlp/CyA== https://sharplab.io/#v2:C4LgpgHgDgNghgSwHYBoAmIDUAfAAgBgAJcB... However, as a personal anecdote, we've had a number of developers who have written mostly Java 1.4 (technical reasons) before switching to C# about a year ago. They took up the newer features and syntax almost without problems. Most questions I got from them were along the lines of “Can we also use this feature?” and not “What does this do?”.
wvenable 2y ago
> The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me. That's funny given many of the changes were made to make C# look more like JavaScript! C# 6 introduced expression-bodied members for simplified syntax (like JavaScript), null-conditional operators, and string interpolation. C# 7 brought pattern matching, tuples, deconstruction, and local functions. C# 8 introduced nullable reference types for better null safety, async streams, and a more concise switch expression syntax. C# 9 to C# 12 added records, init-only properties, with expressions, and raw string literals, global using directives, top-level statements, list patterns, and primary constructors. In C#, if you need a string list you can do: List<string> items = []; // Not as concise as JS but type safe. As for TypeScript, nobody is supposed to use most of it -- unless you're authoring a library. You benefit from it's features because somebody else is using them. Languages draw inspiration from each other -- taking the good parts and incorporating them in. C# is a vastly better, easier, and safer language than it used to be and so is JavaScript.
paulddraper 2y ago
> Now look at modern C++, it's crazy powerful but so jam packed that many people have just gone back to C. Geez I'd sure hope not. If you liked C++11, you can use C++11. Every compiler, platform, and library will support it. No one erased it and made you go back to C99.
bakkoting 2y ago
> instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features I appreciate that this is mostly just a generic rant, but it's not really suitable here, because this is a feature which is being added with the sole goal of improved performance. There's only so much you can to optimize the extremely dynamic regular objects in JS, and there's no hope of using them for shared-memory multithreading. The purpose of this proposal is to have a less dynamic kind of object which can be made more performant and which can be made suitable for shared-memory multithreading.
branko_d 2y ago
And here is the obligatory quote from Bjarne Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
- deleted 2y ago
  [deleted]
devjab 2y ago
I think part of the reason C# has changed so much as far as the language goes, not the CLR is actually because they took so many good things from Typescript and mixed them into the language. I think part of the reason Typescript has become so cumbersome to work with is because it has similarly added a lot of the good things from C#. Which may sound like a contradiction, but I actually agree with you that plain JavaScript is often great. That being said, you don’t actually have to use all the features of Typescript and it’s still much better for larger project in my opinion. Mostly because it protects developers from ourselves in a less “config on organisational level” way. We already use regular JS for some of our internal libraries, because keeping up with how TS transpires things into JS is just too annoying. Don’t get me wrong, it gets it right 98% of the time, but because it’s not every time we have to check. The disadvantage is that we actually need/want some form of types. We get them via JSDoc which can frankly do almost everything Typescript does for us, but with much poorer IDE support (for the most part). Also more cumbersome than simply having something like structs.
edem 2y ago
just use haxe
drclau 2y ago
> Microsoft has a large team dedicated towards improving these languages constantly … and the people working on these projects need to deliver, else their performance review won’t be good, and their financial rewards (merit increase, bonus, refresher) will be low. And here we are. Edit: I realize I’m repeating what you said too, but I wanted to make it more clear what’s going on.
- neonsunset 2y ago
  From what I've been told, all the nice bonuses and career opportunities are in Azure and other, more business-centric areas. You go to DevDiv to work on Roslyn (C#) or .NET itself because you can do so and care about either or both first and foremost.
rezonant 2y ago
> One of the reasons I have so much fun working in node/Javascript these days is because it is simple and not much has changed in express/node/etc for a long time. If I need an iterable that I can simply move through, I just do `let items = [];`. It is so easy and hasn't changed for so many years. I worry that we eventually come out with a dozen ways to do an array and modern code becomes much more challenging to read. The let keyword didn't exist in JS when Node was first released, nor did for/of, which while unstated in your post, is probably what you are thinking of when you posted this. The language has not stayed the same, at all.
root_axis 2y ago
You don't have to use features you don't understand. "Complex" features exist for a reason. To the uninitiated something like generic types are quite inscrutable, but when you encounter the type of problem that they solve, their use becomes much more intuitive, and eventually familiarity yields an understanding and generics reveal themselves to be quite conceptually simple, they're just variables for types.
celdon25 2y ago
C# since version 2 here, so I’m probably older. You said a lot of words, but gave no concrete examples of what’s bad about these languages. Linters will let you turn off different syntax usages based on your preference on what is readable or not, and C# is the only language I’m aware of where you can build them into the compilation chain and literally cause the compilation to halt instead of merely giving a style warning.
carlmr 2y ago
>The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me. The funny thing is if you used F# over a decade ago almost all the C# improvements seem familiar. They were lifted from F#, some of them badly. And I know F# borrows a lot from OCaml. But it's hard to fathom why we need to use the badly adopted F# features in C# instead of just getting F# as a main Microsoft adopted language.
sureglymop 2y ago
I recently tried out a very simple language called Gleam. It's a functional programming language running on the BEAM vm, it may appeal to you.

pjmlp 2y ago

C23 has just been ratified, and C2y has already quite a few proposals. Programming languages are like any other software product, evolution or stagnation. Eventually they might implode, however whatever comes after will follow the same cycle yet again.

seanw444 2y ago
And branches [1] of C are still spawning and gaining traction, because C++ is perceived as overkill. [1]: https://github.com/c3lang/c3c https://github.com/c3lang/c3c
- pjmlp 2y ago
  Spawning, yes. Gaining traction beyond a couple of blog posts in sites like HN, not really.

throw49sjwo1 2y ago

> And nobody uses most of it! Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.

nosefurhairdo 2y ago
Yeah I was confused by this point as well. Especially because many of the recent Typescript releases are just improving performance or handling more cases (without needing to learn new syntax).
tannhaeuser 2y ago
React and Expressjs predate typescript, Expressjs considerably so.
- throw49sjwo1 2y ago
  Doesn't matter, I'm talking about the type definitions - @types/react, @types/react-dom and @types/express.
  - authorfly 2y ago
    No, those are optional for the enduser to ever encounter.
    - throw49sjwo1 2y ago
      I never said it's required. The typings are really useful if you want to use these libraries "with TypeScript" as I said in my first comment... The typings are the whole point - that's where the advanced type features are used, and every user benefits - their own code can be much simpler and safer thanks to it.
      - authorfly 2y ago

adamc 2y ago

Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/ https://chrisdone.com/posts/tamagotchi-tooling/

intothemild 2y ago
The java tooling is the number one thing I hate about using the language. It's all just bad. Then. You get forced into using intelij because it seems to smooth over a lot of the toolings problems with "magic". It's horrible.
- pjmlp 2y ago
  I use Eclipse and Netbeans of free will.
- millipede 2y ago
  Saying this as probably the biggest Java fanboy I know: they are pretty bad. Gradle is pretty much the worst build system Ive used. IntelliJ might as well be folded into the JDK, because I don't think it's possible to be productive in Java without it.
- rudy6912 2y ago
  Everything you said applies to Kotlin as well. Outside of IntelliJ, it is horrible to use. (Ditto Swift outside of Xcode.)

afavour 2y ago

I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple... in most scenarios you'll probably be better off using records rather than objects, and maybe that's what folks will end up doing. But boy does it all get confusing. > Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! I'm not so sure about that. I think we end up consuming a lot of these features in the TS types that get published alongside libraries. We just don't know it, we just get surprisingly intuitive type interfaces.

thot_experiment 2y ago
> but there's absolutely no reason to use var any more Naw, var has function scope and hoisting, both of which are useful.
- afavour 2y ago
  Not in a sensible codebase
- hinkley 2y ago
  My job isn't to be infatuated with your code. It's to get through your code and get stories done. People don't really get better at handling the complexity of large code bases. We are fundamentally the same organic matter that existed prior to the first computer coming into existence. So as code bases and library bases grow larger and larger, they need to be proportionately easier to read or even ignore. Your code needs to be dead boring 90% of the time, otherwise you're imposing on your coworkers. And using variables before they're declared is just shitty behavior.
  - thot_experiment 2y ago
    Sure and I'd accept the weaker claim that "there's no reason to use var in a production codebase touched by many people"

dartos 2y ago

At least typescript tooling hasn’t changed. It was a pain to set up when it came out and it still is. At least we moved past webpack mostly.

eddd-ddde 2y ago

This is why always say the true beginner programming language is C. Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).

n_plus_1_acc 2y ago
How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.
- bobthepanda 2y ago
  Plenty of universities teach C every day even if that means specifying a compiler, and usually it’s a very boring compiler that gets chosen
  - n_plus_1_acc 2y ago
    Right, but all C courses I've done had UB in examples without mebtioning it. There teachers just didn't know what they are teaching.
    - bobthepanda 2y ago
      Unless you are writing a compiler and code specifically tailored to take advantage of UB, there’s not much to say about it other than “be careful about UB cause it can make your program buggy from your POV.”
- lelanthran 2y ago
  > How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers. Right. Becuase no one ever learned C as a first language ever, and those that paradoxically did were worse programmers for it!

pier25 2y ago

> or more performant Obviously then can't make TS more performant (since it doesn't execute) but C# is very performant and even surpasses Go in the TechEmpower benchmarks.

leetharris 2y ago
Absolutely. I love C# and .NET, they are incredible and very fast. I just meant to say that they aren't only focused on performance, but also focused on new features. One of the best things .NET did was adding minimal APIs in .NET 6 (I think) that are more like Express. They removed a lot of boilerplate and unnecessary stuff, making it easier to start building an API.
o11c 2y ago
TS is pretty impressive in that its compiler is slower than C++ compilers though.

egnehots 2y ago

Try Go. Go is really stable as a language and have a very small core feature set.

leetharris 2y ago
This is easily the most appealing thing to me about Go. I learned Go through the "Learn Go with Tests" way and I had a ton of fun. It is hard for me to recommend using Go internally since .NET/Java are just as performant and have such a mature ecosystem, but I crave simplicity in the core libraries. Here's the link for anyone considering learning Go: https://quii.gitbook.io/learn-go-with-tests https://quii.gitbook.io/learn-go-with-tests
- totallykvothe 2y ago
  .NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.
  - pjmlp 2y ago
    Specially if one is ignorant on how to write proper .NET and Java code.
  - BoppreH 2y ago
    And startup time. JIT languages are a bad match for command line applications, for example.
    - GOATS- 2y ago
      .NET can do ahead-of-time compilation now, there are a few gotcha's but it's usable. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8 https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
  - metaltyphoon 2y ago
    This is almost as bad as saying .NET is windows only.

dgellow 2y ago

Do you have examples of unreadable C#? The language didn’t change much IMHO. You have new features, like records, but C# code looks pretty much like what I started with in 2009

leetharris 2y ago
Now that I'm thinking about it, most of it is probably .NET bloat instead of C# bloat, but a few examples would be global usings, file scoped namespaces, records, target-typed new expressions, null coalesce assignments, etc. It's nothing huge, but combined with .NET bloat it can be overwhelming when you haven't worked in .NET for a while.
- jenscow 2y ago
  and pattern matches, primary constructors, range operator, switch expressions, etc. it does add up
  - eknkc 2y ago
    I came to love pattern matching so much that now when I write TypeScript I get frustrated. It is a weird balance.
  - dgellow 2y ago
    All of this looks and feels like C#. That doesn’t look unreadable or a completely different language. In fact they end up making C# more readable by removing boilerplate
- wvenable 2y ago
  All the things you describe make C# more readable and easier to understand! Are you really confused by file scoped namespaces or target-typed new or even null coalesce assignments? You don't have to use them -- although Visual Studio will helpfully suggest places you can use them. If I had never seen a pattern match switch statement before (and there was a point where I didn't) it's sort of immediately obvious what it does.
2y ago

BiteCode_dev 2y ago

Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets... It also has complex rules for: - scoping (plus global variables by default and hoisting) - "this" values (and manual binding) - type coercion (destroying commutativity!) - semi-column automatic insertion - "typeof" resolution On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM. There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway. There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.

nwienert 2y ago
This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons. That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.
- BiteCode_dev 2y ago
  I think what saves JS, like Python, is that despite the modern complexity, you can start to be productive in a few days with just the essentials and learn the rest with a smooth curve, slowly as you progress.

carlosrg 2y ago

Every programming language attempts to expand until it becomes C++. Those languages which cannot so expand are replaced by ones which can.

goatlover 2y ago
Go will resist this as long as possible.
- rudy6912 2y ago
  Lua too. 30 years and counting!

munificent 2y ago

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not too much for you to absorb. Likewise C# 3.0, 4.0, etc. As long as you stay on the C# train, the rate of new features does not exceed the rate that you can learn them. Years later, another person comes along and is new to C#, which is now at version 5.0. They are presented with a huge sprawling language and they have to learn nearly all of it at once to deal with codebases they are contributing to. It's a nightmare. They long for a language that's actually, you know simple. So maybe they find some other newer language, Foo, which is at 1.0. It's small and they learn the whole thing. After a couple of years of happy productive use, they realize they would be a little more happy and productive if Foo had just one or two extra little features. They put in a request. The language team wants happy users so they are happy to oblige. The user is easily able to learn those new features. And maybe some other Foo users want other new things. 2.0 comes out, and they can keep up. They can stay on the train with 3.0, 4.0, etc. They never explicitly asked for a complex language, but they have one and they're happy, because they've mastered the whole thing over a period of years. They've become part of the problem that bothered them so much years ago. Fundamentally, the problem is that existing users experience a programming language as the delta between the latest version and the previous one. New users experience a programming language as the total sum of all of its features (perhaps minus features it has in common with other languages you already know). If you assume users can absorb information at a certain fixed rate, it means those two cohorts have very different needs and different experiences. I don't think there's a silver bullet. The best you can hope for is that a language at 1.0 has as few bad ideas as possible. But no one seems to have perfect skill at that.

spease 2y ago
I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago. I think the only way to address what you're alluding to is to continually deprecate small parts of the language, so that upgrading is manageable for active codebases. And you probably have to be really aggressive about pushing this forward, because there will always be excuses about why you should hold back just this one time and this one feature is an exception that needs to be held back just a little bit longer. But in the long run, if you don't force people to change a little bit continuously, it will become a big enough issue to split the ecosystem. See python2 to python3. Or you end up forced into supporting bad practices for all eternity, like C++. And having to take them into account for every. Single. New. Feature. Further raising the barrier to entry to participation in developing the language to people who are completely focused on its development and have unusual mastery of it, who can't identify with the people struggling with its complexity. If not at the technical level, then at the business level, where people definitely don't have the time to understand why it'd be safer for the go-to heap allocation method should return a scoped pointer instead of a raw pointer. Unfortunately, this probably is only viable for strongly-typed languages like C#; for loosely-typed languages like Python, the risk of iterative changes is that if someone moves a codebase several generations ahead at once, it'll introduce lots of subtle changes that'll only become obvious once certain codepaths are exercised...and given how bad testing coverage is for a lot of software, that probably risks breakages only occurring once it's deployed, that are nontrivial to discern via reviews or even static analysis.

lelandfe 2y ago

It doesn't help how arcane the TS documentation is. Important docs live as frozen-in-amber changelog entries; huge tracts of pages "deprecated" yet still #1 on Google. Google "typescript interfaces." #1 is a page that has been deprecated for years. How did this happen?

hsbauauvhabzb 2y ago
AWS has that issue too - v1 documentation takes precedence over v2, the same with bootstrap, too. I suspect google algorithms don’t quite understand deprecation / latest version prioritisation.
imbnwa 2y ago
Can tell you right now a lot of important information about mapped types live in Github issues on the TS repo
vundercind 2y ago
Documentation where, somehow, every single thing you can find for some particular need is “deprecated” and it’s weirdly-difficult to find a complete set of docs not full of deprecated landmines mixed in with the current stuff, is kinda a Microsoftism.

lolinder 2y ago

> When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! TypeScript today can be written the same way that TypeScript was when it first started to become popular. Yes there are additions all the time, but most of them are, as you observe, irrelevant to you. They're there to make it possible to type patterns that would otherwise be untypeable. That matters for library developers, not so much for application developers. To the extent there's a barrier to entry, it seems largely one that can be solved with decent tutorials pointing to the simple parts that you're expected to use in your applications (and a culture of not overcomplicating things in application code).

d13 2y ago
As a very experienced TS developer myself - this is absolutely correct, the best reply in this thread, and I hope the OP reads it.
tgv 2y ago
TS is pretty good. In the beginning, I had to resort to 'any' frequently, but nowadays it's often possible to avoid that by writing some auxiliary types. It's not easy, but you can get quite far. JS without TS' safety net is a nightmare...

Waterluvian 2y ago

I also don’t know how to refine my thought but it’s something along the lines of: The people who are in a position to decide what features get added to a language are usually top experts and are unlikely to have any reasonable perspective on how complicated is too complicated for the rest of us. If you live and breathe a language, just one more feature can seem like a small deal. I think it becomes much more reasonable when that one more feature enables an entire set of capabilities and isn’t just something a library or an existing feature could cover.

int_19h 2y ago
For many languages these days, evolution happens in public, and you can look at those discussions and see how this sausage is made. If you do it for C#, if anything, the pattern is that relatively inexperienced users are the ones who propose features (to make some specific pet peeve of theirs easier), while the more experienced folk and especially the language designers who make the final call aggressively push back, point out corner cases, backwards compatibility, maintenance burden etc.

MathMonkeyMan 2y ago

What did Bjarne Stroustrup supposedly say? There are two kinds of programming languages: the ones everybody complains about, and the ones nobody uses. I'll put on my Scheme hat and say "with hygienic macros, people can add whichever language features they want." Maybe Rust is a good experiment along those lines: C++ with hygienic macros. Everything that people keep using grows into a monster of complexity: programming languages, software, operating systems, law. You must maintain backward compatibility, and the urge to add a new feature is too great. There's a cost with moving to the new thing -- let's just put the new thing in the old thing.

azangru 2y ago

> it has a huge barrier to entry You don't have to use every feature of the language. Especially not when you are just learning. > Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it! Exactly. But no-one seems to be arguing that typescript has a huge barrier to entry.

breadwinner 2y ago

Couldn't agree more. More features in a programming language makes it easier and more fun to write code, but makes it harder to read and maintain someone else's code. Considering more time is spent maintaining code as opposed to writing it (assuming the product is successful), readability is more important than writability.

neonsunset 2y ago

> sometimes modern C# code from experts looks unreadable to me This is a culture issue and has always existed in C#, Java and C++ communities sadly (and I'm seeing this now with TS just as much, some Go examples are not beacons of readability either, I assume other languages suffer from this similarly). In the past, people abused BinaryFormatter, XML-based DSLs, occasionally dynamic, Java-style factories of factories of factories, abuse of AOP, etc. Nowadays, this is supplanted by completely misplaced use of DDD, Mediatr, occasional AutoMapper use (oh god, at least use Mapperly or Mapster) and continuous spam of 3 projects and 57 file-sized back-ends for something that can be written under ~300 LOC split into two files using minimal API, records and pattern matching (with EF Core even!). Neither is an example of good code, and the slow but steady realization that simplicity is the key makes me hopeful, but the slow pace of this, and new ways to make the job of a developer and a computer more difficult that are sometimes introduced by community and libraries surrounding .NET by MS themselves sour the impression.

Shiny_Gyrodos 2y ago

I'm an absolute beginner when it comes to programming, and I chose C# as my first language to learn. I've been learning steadily for 8 or so months now and at no point have I felt the language was unapproachable due to excessive features. Looking back on what each new version added, I don't think any of the additions were damaging to the simplicity of C#. I do likely have a biased perspective though, as I use newer C# features every day.

ygra 2y ago
> I do likely have a biased perspective though, as I use newer C# features every day I think that is kind of the point, though. Many of those newer features help with simplifying code and making it less boilerplate-y. To old programmers it is a simple code fix in the IDE to move from 30 lines of variable assignments in a switch to a 5 lines switch expression and they can learn that way. People new to the language typically won't even consider going the complicated route because they learned an easier way first. I do concede that having people with less C# experience on a team where modern C# is used, there will be constructs that are not immediately obvious. SharpLab has an “Explain” mode which would be helpful in such cases, but I haven't seen anything like that in IDEs: https://sharplab.io/#v2:C4LgpgHgDgNghgSwHYBoAmIDUAfAAgBgAJcBGAbgFgAoXAZmICZCBhQgb0M8Oq+PtwAshALIAKZIWTBCcFIXFJgc0vgCUhAEbq2PXl0GEAMqO269hAL5m913lMIRCAXkJowAMzgBXGMEpVzTgR3eQ1JAGdCADc4ACdo1VsuAEhSAE5RKNUyQNzuAK4rAs5rOklFQgAFZwA+Qlp/CyA== https://sharplab.io/#v2:C4LgpgHgDgNghgSwHYBoAmIDUAfAAgBgAJcB... However, as a personal anecdote, we've had a number of developers who have written mostly Java 1.4 (technical reasons) before switching to C# about a year ago. They took up the newer features and syntax almost without problems. Most questions I got from them were along the lines of “Can we also use this feature?” and not “What does this do?”.

wvenable 2y ago

> The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me. That's funny given many of the changes were made to make C# look more like JavaScript! C# 6 introduced expression-bodied members for simplified syntax (like JavaScript), null-conditional operators, and string interpolation. C# 7 brought pattern matching, tuples, deconstruction, and local functions. C# 8 introduced nullable reference types for better null safety, async streams, and a more concise switch expression syntax. C# 9 to C# 12 added records, init-only properties, with expressions, and raw string literals, global using directives, top-level statements, list patterns, and primary constructors. In C#, if you need a string list you can do: List<string> items = []; // Not as concise as JS but type safe. As for TypeScript, nobody is supposed to use most of it -- unless you're authoring a library. You benefit from it's features because somebody else is using them. Languages draw inspiration from each other -- taking the good parts and incorporating them in. C# is a vastly better, easier, and safer language than it used to be and so is JavaScript.

paulddraper 2y ago

> Now look at modern C++, it's crazy powerful but so jam packed that many people have just gone back to C. Geez I'd sure hope not. If you liked C++11, you can use C++11. Every compiler, platform, and library will support it. No one erased it and made you go back to C99.

bakkoting 2y ago

> instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features I appreciate that this is mostly just a generic rant, but it's not really suitable here, because this is a feature which is being added with the sole goal of improved performance. There's only so much you can to optimize the extremely dynamic regular objects in JS, and there's no hope of using them for shared-memory multithreading. The purpose of this proposal is to have a less dynamic kind of object which can be made more performant and which can be made suitable for shared-memory multithreading.

branko_d 2y ago

And here is the obligatory quote from Bjarne Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

deleted 2y ago
[deleted]

devjab 2y ago

I think part of the reason C# has changed so much as far as the language goes, not the CLR is actually because they took so many good things from Typescript and mixed them into the language. I think part of the reason Typescript has become so cumbersome to work with is because it has similarly added a lot of the good things from C#. Which may sound like a contradiction, but I actually agree with you that plain JavaScript is often great. That being said, you don’t actually have to use all the features of Typescript and it’s still much better for larger project in my opinion. Mostly because it protects developers from ourselves in a less “config on organisational level” way. We already use regular JS for some of our internal libraries, because keeping up with how TS transpires things into JS is just too annoying. Don’t get me wrong, it gets it right 98% of the time, but because it’s not every time we have to check. The disadvantage is that we actually need/want some form of types. We get them via JSDoc which can frankly do almost everything Typescript does for us, but with much poorer IDE support (for the most part). Also more cumbersome than simply having something like structs.

edem 2y ago

just use haxe

drclau 2y ago

> Microsoft has a large team dedicated towards improving these languages constantly … and the people working on these projects need to deliver, else their performance review won’t be good, and their financial rewards (merit increase, bonus, refresher) will be low. And here we are. Edit: I realize I’m repeating what you said too, but I wanted to make it more clear what’s going on.

neonsunset 2y ago
From what I've been told, all the nice bonuses and career opportunities are in Azure and other, more business-centric areas. You go to DevDiv to work on Roslyn (C#) or .NET itself because you can do so and care about either or both first and foremost.

rezonant 2y ago

> One of the reasons I have so much fun working in node/Javascript these days is because it is simple and not much has changed in express/node/etc for a long time. If I need an iterable that I can simply move through, I just do `let items = [];`. It is so easy and hasn't changed for so many years. I worry that we eventually come out with a dozen ways to do an array and modern code becomes much more challenging to read. The let keyword didn't exist in JS when Node was first released, nor did for/of, which while unstated in your post, is probably what you are thinking of when you posted this. The language has not stayed the same, at all.

root_axis 2y ago

You don't have to use features you don't understand. "Complex" features exist for a reason. To the uninitiated something like generic types are quite inscrutable, but when you encounter the type of problem that they solve, their use becomes much more intuitive, and eventually familiarity yields an understanding and generics reveal themselves to be quite conceptually simple, they're just variables for types.

celdon25 2y ago

C# since version 2 here, so I’m probably older. You said a lot of words, but gave no concrete examples of what’s bad about these languages. Linters will let you turn off different syntax usages based on your preference on what is readable or not, and C# is the only language I’m aware of where you can build them into the compilation chain and literally cause the compilation to halt instead of merely giving a style warning.

carlmr 2y ago

>The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me. The funny thing is if you used F# over a decade ago almost all the C# improvements seem familiar. They were lifted from F#, some of them badly. And I know F# borrows a lot from OCaml. But it's hard to fathom why we need to use the badly adopted F# features in C# instead of just getting F# as a main Microsoft adopted language.

sureglymop 2y ago

I recently tried out a very simple language called Gleam. It's a functional programming language running on the BEAM vm, it may appeal to you.