1. 8

    TL:DR: A bunch of features deemed as extravagant or downright dangerous by Java since 20 years, until suddenly Kotlin came around.

    Now Java is desperately trying to comb over its balding scalp.

    1. 4

      Could not agree more with that statement. Until the Google/Oracle debacle didn’t happen and Kotlin delivered on features that made Java IDE vomit (generators for getter/setters) look bad, nobody took Kotlin seriously. Each feature that you see is catching up (other than GC improvements) in one form or another.

      1. 3

        Don’t forget that most of the features of Kotlin are borrowed from Scala.

      2. 3

        Long-term success and adding every possible feature ASAP are two different things…

      1. 2

        I still think the biggest mistake was implicit fallthrough.

        1. 5

          I think in many cases people hate Java, and by extension, hate OOP. Java being the first mainstream OO language, and still the poster child for OO in many minds, gives object-orientation a worse reputation than it would have if there were other OO languages (apart from C#) one could actually earn a living with.

          1. 17

            Most people hate the working environments in which Java is used, with their power structure, deskilling of the worker, fordist approach to software development. Wait for Go to become the new Java and they will start projecting the same hate on Go, regardless of the merit of the language design or lack thereof.

            You don’t hate OOP, you hate capitalism.

              1. 9

                I know, that’s why I mentioned Go specifically. Give it 10-15 years and all the fanboying will die out.

                1. 4

                  Huh? I vehemently disagree with this. A language which deskills development enables novice programmers or non-progranmers to build software and systems for themselves with less time investment required. And given that personal software will never see the scale of usage or the sheer variety of deployment conditions that corporate SaaS often sees, personal software doesn’t need to be as correct as corporate SaaS either, so trading performance and correctness for functionality is a very realistic trade-off for personal-use software.

                  I find these language identity wars to be odious. You don’t like Go, that’s fine. Please don’t extrapolate systemic failures from your own personal likes and dislikes.

                2. 5

                  That is true, but both Java and Go are made to solve the capitalist’s problem, not yours or mine.

                  1. 4

                    are they? this to me is up for debate. The deskilling that comes with these languages is a problem only under a specific mode of production. Being able to split the workload across a bigger group of people, having “protocols” to standardize development, enable less skilled people to write reliable software are not bad things in themselves. They are bad things in our specific economic system.

                3. 2

                  I agree with this. Most of the programmers I know associate OOP with Java, C++, and C#. Also, using those languages, in the typical fashion results in code that is very OOP-like. It’s unfortunate though, because since about 2015 there have been alot of advances in all three of these languages. Lambda functions give an enormous amount of freedom when used instead of the typical constructs seen in older variations of Java, C++ and C#. The OOP languages have added some elements of functional programming in order to become more of a mixed language. This is a big deal. Mixed languages are becoming more popular now. Not all of OOP was a bad idea, an example of this is that Javascript, a mostly functional programming language has gotten a formal declaration for classes in recent years. In other words, they added class constructors INTO a mostly FP language. Personally I like OOP with first class functions. I’m happy with C# exactly how it is. I’ve used plenty of functional languages(haskell and clojure mostly), but I just prefer a blend of OOP and FP more than one or the other.

                  1. 2

                    It’s funny you mention 2015, since around that time, a as new batch of languages appear that aren’t as heavily invested in strict OOP appear. Java and C# only accepted multi-paradigmatic programming once it was proven to be non-threatening by newer languages.

                    Before that, it was regarded as superfluous and academic.

                1. 2

                  I have two three problems with this.

                  1. Namespaces in XML/HTML are not “voodoo”. The MDN docs specify exactly what the resolver function does. Just because you don’t understand something, doesn’t make it “voodoo”.

                  2. Really, you’re still extending native prototypes? I guess the JavaScript community really hasn’t learn it’s lesson from the “smoosh”-pocalypse a few years ago?

                  3. The third attempt, where the author attempts to access the text node directly, could have easily been adapted to simply iterate over text nodes checking for existence of the string to be replaced. I think XPath actually is a good tool to use here, but the author is clearly out of his/her depth if namespaces are “voodoo”, so iterating over nodes using the DOM is probably a safer alternative.

                  1. 5

                    but the author is clearly out of his/her depth if namespaces are “voodoo”, so iterating over nodes using the DOM is probably a safer alternative.

                    This is needlessly exclusionary, and is exactly the sort of attitude that gives XML-related technologies a bad rap. You absolutely do not need to have a thorough understanding of namespaces to use XPath effectively.

                    1. 1

                      I didn’t say you need a thorough understanding.

                      Calling something “voodoo” is a long way from “I don’t understand this thing in depth”

                    2. 2

                      Really, you’re still extending native prototypes? I guess the JavaScript community really hasn’t learn it’s lesson from the “smoosh”-pocalypse a few years ago?

                      What event was this?

                      1. 5

                        There’s a whole writeup about it here: https://developers.google.com/web/updates/2018/03/smooshgate

                        TL;DR: There was a proposal to add Array.prototype.flatten to JavaScript, but it turns out that would have been incompatible with MooTools’s Array.prototype.flatten, so some websites which used MooTools would have been broken. The proposal’s author jokingly suggested renaming the new function to “smoosh,” which is where the name comes from.

                        1. 2

                          I would have expected a more local implementation of the method to override the default implementation. Isn’t this the case for JS?

                          1. 1

                            No. The impact is page-global. If you’re doing webdev, you absolutely should not extend native prototypes (polyfills excepted).

                            (That said, the “javascript community” extends beyond webdev. In certain (mostly non-webdev) contexts, extending native prototypes can be completely harmless.)

                            1. 1

                              Well it depends how the JS implementation is written. Some will only add the method if it doesn’t already exist (imagine a polyfill). Why you would do that for a method that isn’t a polyfill I have no idea..

                        1. 4

                          I am sorry, but if you still do not know about multi-byte characters in 2020, you should really not be writing software. The 1990ies have long passed in which you could assume 1 byte == 1 char.

                          1. 28

                            https://jvns.ca/blog/2017/04/27/no-feigning-surprise/

                            Nobody was born knowing about multi-byte characters. There’s always new people just learning about it, and probably lots of programmers that never got the memo.

                            1. 5

                              The famous joel article on unicode is almost old enough to vote in most countries (17 years). There is really no excuse to be oblivious to this: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

                              This is esp. problematic if you read the last paragraph where the author gives encryption/decryption as an example. If somebody really is messing with low level crypto apis, they have to know this. There is no excuse. Really.

                              1. 10

                                Junior Programmers aren’t born having read a Joel Spolsky blog post. There are, forever, people just being exposed to the idea of multibyte characters for the first time. Particularly if, like a lot of juniors are, they’re steered towards something like the K&R C book as a “good” learning resource.

                                Whether or not this blog post in particular is a good introduction to the topic is kind of a side-point. What was being pointed out to you was that everyone in 2020 is supposed to have learned this topic at some point in the past is beyond silly. There are always new learners.

                                1. 4

                                  You are aware that there are new programmers born every day, right?

                                2. 4

                                  Right, but this author is purporting to be able to guide others through this stuff. If they haven’t worked with it enough to see the low-hanging edge cases, they should qualify their article with “I just started working on this stuff, I’m not an expert and you shouldn’t take this as a definitive guide.” That’s a standard I apply to myself as well.

                                  1. 2

                                    We should perhaps not expect newcomers to know about encoding issues, but we should expect the tools they (and the rest of us) use to handle it with a minimum of bad surprises.

                                  2. 8

                                    That’s a little harsh, everyone has to learn sometime. I didn’t learn about character encoding on my first day of writing code, it took getting bitten in the ass by multibyte encoding a few times before I got the hang of it.

                                    Here is another good intro to multibyte encoding for anyone who wants to learn more: https://betterexplained.com/articles/unicode/

                                    1. 2

                                      I didn’t learn about character encoding on my first day of writing code, it took getting bitten in the ass by multibyte encoding a few times before I got the hang of it.

                                      Right, but you’re not the one writing and publishing an article that you intend for people to use as a reference for this type of stuff. People are responsible for what they publish, and I hold this author responsible to supply their writing with the caveat that their advice is incomplete, out-of-date, or hobby-level—based, I presume, on limited reading & experience with this stuff in the field.

                                    2. 8

                                      I’m sure that if I knew you well enough, I could find three things you didn’t know that respected developers would say means “you should really not be writing software”.

                                      1. 3

                                        Yes it’s 2020, but also, yes, people still get this wrong. 90% of packages addressed to me mangle my city (Zürich) visibly on the delivery slip, so do many local(!) food delivery services.

                                        Every time I make a payment with Apple Pay, the local(!) App messes up my city name in a notification (the wallet app gets it right).

                                        Every week I’m handling support issues with vendors delivering data to our platform with encoding issues.

                                        Every week somebody in my team comes to me with questions about encoding issues (even though by now they should know better)

                                        This is a hard problem. This is also a surprising problem (after all „it’s just strings“).

                                        It’s good when people learn about this. It’s good when they communicate about this. The more people write about this, the more will get it right in the future.

                                        We are SO far removed from these issues being consistently solved all throughout

                                        1. 2

                                          I know all that. My first name has an accented character in it. I get broken emails all the time. That still does NOT make it okay. People that write software have to know some fundamental things and character encodings is one of them. I consider it as fundamental as understanding how floats work in a computer and that they are not precise and what problems that causes.

                                          The article being discussed is not good and factually wrong in a few places. It is also not written in a style that makes it sound like somebody is documenting their learnings. It is written as stating facts. The tone makes a big difference.

                                        2. 2

                                          There’s a difference between knowing there’s a difference, which I suspect is reasonably common knowledge, and knowing what the difference is.

                                          1. 2

                                            There are very few things that every software developer needs to know–fewer than most lists suggest, at least. Multi-byte encodings and unicode have are about as good a candidate as exists for being included in that list.

                                            However, people come to software through all different paths. There’s no credential or exam you have to pass. Some people just start scripting, or writing mathematical/statistical code, and wander into doing things. Many of them will be capable of doing useful and interesting things, but are missing this very important piece of knowledge.

                                            What does getting cranky in the comments do to improve that situation? Absolutely nothing.

                                            1. 3

                                              There’s no credential or exam you have to pass.

                                              I think that this is one of the problems with our industry. People with zero proof of knowledge are fuzzing around with things they do not understand. I am not talking about hobbyists here, but about people writing software that is being used by people to run critical infrastructure. There is no other technical profession where that is okay.

                                              1. 2

                                                I think our field is big and fast enough that dealing with things we don’t understand don’t yet understand has just become part of the job description.

                                          1. 3

                                            Swift collection types are also value types, with copy-on-write to ensure performance as long as they aren’t shared.

                                            1. 2

                                              Rust’s Non-Copy types don’t have a direct equivalent in other languages like Swift or C++.

                                              They’re not quite like value types, because passing them by value doesn’t create a copy. The source is discarded/inaccessible to guarantee there’s logically only one copy, which eliminates need for copy-on-write or thread synchronization.

                                              But they aren’t reference types either, because despite this guarantee of a single instance, there’s no heap allocation or indirection involved, and they don’t have a stable address (for the struct itself. Vec’s backing store is still on the heap).

                                            1. 6

                                              What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more

                                              Agree.

                                              If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. … Instead, use an automated tool to reformat the code.

                                              I understand this point of view, but it is also important to mention that this destroys the history in your version control system (mercurial, subversion, git, fossil etc.). The annotate/blame tool will become useless and will point to a single person (often the junior developer who was assigned this boring task), you will lose the information why particular lines were written, by whom and when (of course, the information is still stored somewhere in the history, but is is practically inaccessible now). It will be difficult to distinguish important changes from formatting. And if you develop in multiple branches and merge or cherry-pick across them, the automatic process that usually runs smoothly will fail now and will require expensive human work… just because the older branches/versions have different formatting.

                                              The correct solution would require a complete history rewrite. Literally rewrite every single commit, reformat its code while keeping the author, date and message metadata unmodified. But: this is so many commits, so many years… in a distributed version control system, it changes the hashes, so if someone from outside references to them, this references will become invalid (e.g. links from external websites)… or there might be a bug in the formatting tool that makes some significant/logical changes in the code – then if a customer asks you for a „v3.0.0 with just a small fix“, he might get completely different version with many other changes… I am afraid that the risks are higher than benefits.

                                              Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple.

                                              I recommend talking rather about free software than open source and avoid promoting evil corporations.

                                              1. 3

                                                “The good thing about standards is that there are so many to choose from”.

                                                Anecdotally, GNU C formatting is one of the less popular styles.

                                                I’m neutral towards Go but I do appreciate that the language designers shortcircuited a lot of debate and saved countless wasted hours arguing by including a formatter in the language.

                                                1. 1

                                                  of course, the information is still stored somewhere in the history, but is is practically inaccessible now

                                                  Do that many people know enough git to use blame but not enough to know git blame <revision>^ -- path/to/check?

                                                  I don’t expect many people to know how to use blame but I’d (perhaps wrongly) assumed that those who do could navigate more than one layer of history with relative ease.

                                                  1. 2

                                                    You can also

                                                    git config blame.ignoreRevsFile .git-blame-ignore-revs
                                                    

                                                    so that revisions listed in .git-blame-ignore-revs are automatically ignored by git-blame in the future.

                                                    1. 2

                                                      I didn’t know that command line invocation! Looking at github, the blame page looks something like:

                                                      commit header (with link), date, link to blame at that commit, line number, code

                                                      The commit header link, and the previous blame version, are useful in navigating changes.

                                                      1. 1

                                                        I don’t use git blame; my editor always shows the latest change for every line.

                                                    1. 2

                                                      Adding features does not improve a language.

                                                      1. 6

                                                        And “having a small feature set” does not improve a language inherently (perhaps it makes implementors lives easier).

                                                        There are things that are useful. Things that are less useful. And you should judge things based on those costs instead of establishing strong red lines. Especially when lots of these features are responses to people writing Python code in the wild requesting these kinds of changes to improve real experiences.

                                                        1. 2

                                                          And you should judge things based on those costs instead of establishing strong red lines.

                                                          99.9% of languages cross all red lines and give a damn all about doing some cost analysis before doing things¹, so I think tit would be nice to have at least one language that upholds some quality standards.

                                                          Especially when lots of these features are responses to people writing Python code in the wild requesting these kinds of changes to improve real experiences.

                                                          If you do language-design-by-popularity-contest, don’t be surprised if the language looks like it. :-)

                                                          ¹ Just have a look at the replies (including yours) having an aneurysm simply for mentioning that adding features doesn’t improve a language. If a feature improves a language, then it’s the job of the people who want to add it to prove this², not for others to argue against.

                                                          ² Oh and also: People who want to add a feature should also be responsible to remove an existing feature first.

                                                          1. 4

                                                            99.9% of languages cross all red lines and give a damn all about doing some cost analysis before doing things¹, so I think tit would be nice to have at least one language that upholds some quality standards.

                                                            See the PEPs.

                                                            Just have a look at the replies (including yours) having an aneurysm simply for mentioning that adding features doesn’t improve a language. If a feature improves a language, then it’s the job of the people who want to add it to prove this², not for others to argue against.

                                                            Again, see the PEPs for the feature inclusion. Also, there’s no need to talk down on others because they have a different opinion than you.

                                                            Oh and also: People who want to add a feature should also be responsible to remove an existing feature first.

                                                            Why do you have to remove another feature? Do you not have enough space? If so, a larger storage device is probably a better solution than arbitrarily restricting feature addition because a “feature” has to be removed first. Also, what is a “feature”? How do you define what is considered a “feature”? A method? An object? A function? A property of an object? A modification to the behaviour of an object?

                                                            1. -4

                                                              Why do you have to remove another feature? Do you not have enough space? If so, a larger storage device is probably a better solution than arbitrarily restricting feature addition because a “feature” has to be removed first. Also, what is a “feature”? How do you define what is considered a “feature”? A method? An object? A function? A property of an object? A modification to the behaviour of an object?

                                                              These strawmen are exactly the reason why I didn’t bother with nuance in “adding features does not improve a language” anymore.

                                                              People who seem to lack even the most basic understanding about these things, tend to have big opinions about which features the language needs next.

                                                              1. 7

                                                                I have occasionally jokingly suggested that when someone breaks out the Saint-Exupery quote about perfection, we should further perfect that person by taking something away – perhaps their keyboard! Which is a fun way to point out that such assertions absolutely depend on context and nuance.

                                                                Your assertions not only lacked nuance, they verged on straw-man arguments: for example, as another reply pointed out, the Python team do require discussion and debate including pro/con analysis prior to adding new language features, as evidenced by the PEP process and by the lengthy email discussions around many PEPs. So when you asserted your distaste for people who don’t do that, the only possible conclusions to draw are that it’s a red herring because you know Python does do this, or that it’s a misrepresentation because Python does it but you’re not acknowledging it.

                                                                On a deeper level, there are at least two common views about features in languages/libraries/products/etc., and those views appear to be fundamentally incommensurable. But neither view is objectively and universally correct, yet many people argue as if their view is, which is not useful.

                                                                1. 1

                                                                  require discussion and debate including pro/con analysis prior to adding new language features

                                                                  Even by your own wording, it’s not even remotely an equal fight.

                                                                  One side is “pro”, the other side “against” – which is far removed from a process that says “we want to improve the language, let’s examine whether this can be done by removing something, keeping things the same, or adding something”.

                                                                  Let’s not even pretend that the pro/con analysis is unbiased or factual, as long as your process treats people who don’t want to add things/remove things as “the bad guys”.

                                                                  at least two common views

                                                                  That explains the complete meltdown of one side as seen in this thread, I guess?

                                                                2. 3

                                                                  So you’re deliberately trolling.

                                                                  1. -4

                                                                    No, but these hysterical reactions are exactly what I had in mind when I talked about replies with little value earlier.

                                                              2. 2

                                                                Here’s a comment where I argue against adding a new feature to Python.

                                                                I believe in thinking about costs and benefits when adding language features. I will admit I like shiny stuff, but I also want features that fit in with the rest of the language.

                                                                I also write Python on a daily basis, and I know of places where the walrus operator would have made things cleaner, without getting in the way later. I don’t think it is that important (like do: while or just a case statement would be much more helpful) and I would rather not have the walrus operator if it meant we could have kept Guido and not started a big acromonious fight about it.

                                                                I just fundamentally dislike the concept of “too many features are bad”. Good features are good, that’s why they’re good!

                                                                Now, lots of languages add features that interact badly with each other…. that’s where you’re really getting into actual messes that affect users.

                                                                1. 1

                                                                  My first comment was a direct dismissal of the approach to language design you describe.

                                                                  There is no misunderstanding or need for further explanation here.

                                                            2. 5

                                                              I might accept “adding features is not the same as improving a language”.

                                                              But features which allow for better code reuse (e.g. function decorators), improve expressivity (e.g. list comprehensions), or provide useful control structures (e.g. iterators and generators) can absolutely improve a language. All of my example features were added to Python after it was released, and they all improve that language.

                                                              1. 1

                                                                I think we’ll have to agree to disagree on that.

                                                                All of the things you have mentioned have costs associated with them, and only very rarely do the improvements rise above that.

                                                              2. 4

                                                                Lack of features leads to books of programming patterns — they’re called so because they require each reader of the code to actively pattern match blocks of code to identify them as what would just be features in another language.

                                                                1. 1

                                                                  I think we can do way better, we shouldn’t let the misdeeds of 70ies’ languages cloud our judgement.

                                                                2. 2

                                                                  What’s the background on this statement? Are you suggesting that if your language is composed of maximally orthogonal and flexible features then additional features are unnecessary?

                                                                  1. 1

                                                                    Yes.

                                                                    Additionally, adding more features after-the-fact will always result in lower quality than if the feature was designed into the language from the start.

                                                                    I think C#’ properties are a good example of this, Java Generics, …

                                                                1. 3

                                                                  Have there been any notable attempts to create a new language-agnostic ABI? I’m guessing most people reach for a message-passing or RPC library when C gets too limiting but it would be an interesting project.

                                                                  1. 5

                                                                    WebAssembly WASI is kinda that if you squint a bit: https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/

                                                                    1. 2

                                                                      VMS has always had a language-agnostic ABI.

                                                                    1. 15

                                                                      I think Git is an excellent candidate for a rust rewrite. There’s nothing about it that really needs to be in C or benfits from being in C, it’s just one of the many userspace command-line tools that were written in C out of tradition. Rust is a better language that C that results in more maintainable and less bug prone code. There’s no reason not to use Rust for this kind of program (or at least avoid C).

                                                                      1. 17

                                                                        There’s no reason not to use Rust for this kind of program (or at least avoid C).

                                                                        Portability? Also bootstraping rust is kind of hard :| . Both issues are important for this kind of foundational software.

                                                                        But I agree that there are many reasons to use rust for this kind of program.

                                                                        1. 1

                                                                          How portable is Git? How many C compilers can compile it and for how many systems?

                                                                          1. 1

                                                                            A quick search shows Git is available on AIX and Sparc systems, you can probably find more with better searches

                                                                        2. 15

                                                                          Git was created in 2005, Rust in 2010…

                                                                          That said, it’s a good idea to have multiple implementations of the same functionality. It wouldn’t surprise if GitHub was exploring alternatives.

                                                                          I’d like to expand on my point in the first sentence - what would have been a viable language for Linus to use to implement Git in 2005 (other than C/C++?). Git was designed as a replacement for BitKeeper to handle the Linux source tree. Using C in that case was an easy choice.

                                                                          1. 4

                                                                            what would have been a viable language for Linus to use to implement Git in 2005

                                                                            Python was used to created Mercurial in 2005.

                                                                            1. 1

                                                                              And haskell was used to create darcs in 2003.

                                                                          2. 14

                                                                            Rust is a better language that C

                                                                            That’s a subjective opinion. Rust has some mechanisms that protect against certain classes of programming errors, but it has many many other problems.

                                                                            1. 1

                                                                              Even without those mechanisms, it would still be a better language.

                                                                              1. 1

                                                                                By what metric?

                                                                                1. 1

                                                                                  By everyone of them. Being better than C is hardly rocket science.

                                                                            2. 4

                                                                              Rust is a better language that C

                                                                              Isn’t git written in Perl? </joke> … sorta

                                                                              1. 3

                                                                                I would suggest it was written in C as per the opinions of its author rather than out of tradition.

                                                                                1. 6

                                                                                  Rust did not exist at the time.

                                                                                  1. 1

                                                                                    Sure, but C++ did.

                                                                                    1. 1

                                                                                      And we already know how Linus feels about C++:

                                                                                      YOU are full of bullshit.

                                                                                      C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

                                                                                      In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said “to piss you off”, but it’s actually true. I’ve come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn’t come and screw up any project I’m involved with.

                                                                                      C++ leads to really really bad design choices. You invariably start using the “nice” library features of the language like STL and Boost and other total and utter crap, that may “help” you program, but causes:

                                                                                      • infinite amounts of pain when they don’t work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it’s not even funny)

                                                                                      • inefficient abstracted programming models where two years down the road you notice that some abstraction wasn’t very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

                                                                                      In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don’t screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic “object model” crap.

                                                                                      So I’m sorry, but for something like git, where efficiency was a primary objective, the “advantages” of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

                                                                                      If you want a VCS that is written in C++, go play with Monotone. Really. They use a “real database”. They use “nice object-oriented libraries”. They use “nice C++ abstractions”. And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

                                                                                      But I’m sure you’d like it more than git.

                                                                                      and

                                                                                      It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

                                                                                      The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven’t changed:

                                                                                      • the whole C++ exception handling thing is fundamentally broken. It’s especially broken for kernels.
                                                                                      • any compiler or language that likes to hide things like memory allocations behind your back just isn’t a good choice for a kernel.
                                                                                      • you can write object-oriented code (useful for filesystems etc) in C, without the crap that is C++.

                                                                                      In general, I’d say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can’t see what he is writing is really just C anyway (c) was given an assignment in CS class to do so.

                                                                                      Feel free to make up (d).

                                                                                          Linus
                                                                                      
                                                                              1. 1

                                                                                Isn’t this project pretty much dead?

                                                                                1. 2

                                                                                  I don’t know; I starred it two or three years ago and just stumbled upon it again while searching for something unrelated. :)

                                                                                  1. 1

                                                                                    with https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html and the repo activities it doesn’t look good :(

                                                                                    I wish this project would have succeeded. It was fascinating.

                                                                                1. 2

                                                                                  FWIW, this isn’t out of the ordinary; Inferno was also another Plan 9 descendent and used a register instead of stack VM, which was a bit unusual for a high level system at the time.

                                                                                  1. 1

                                                                                    Lua is also stack-based afaik.

                                                                                  1. 5

                                                                                    Been waiting for this release, very nice! Hope binary sizes keep shrinking.

                                                                                    1. 2

                                                                                      Provided they don’t become absurd, why do you care about binary sizes?

                                                                                      1. 3

                                                                                        I’ve got some pretty slow internet - this morning I was downloading terraform 0.13 at ~70kb/s, haha. Granted, it’s a particularly large example.

                                                                                        Go hello world is ~10 MB. I understand there’s a lot of runtime packed in there (or something else? Go binaries compress particularly well, so there’s not a lot of entropy somewhere), but for some perspective I’ll beat the dead horse and say statically including musl libc weighs ~1 MB at most. So, it would be pretty cool to have like, 5 MB go hello world. I’d guess the go linker could be more smart, I never actually bothered to look at what’s taking up space.

                                                                                        In the end, it’s not really an issue for me personally. Definitely being idealistic here. I’d guess the engineering effort involved would just not be worth it, at least not to Google.

                                                                                        1. 1

                                                                                          10MB seemed outrageous to me, so I checked. Using

                                                                                          package main
                                                                                          import "fmt"
                                                                                          func main() { fmt.Println("Hello, world!") }
                                                                                          

                                                                                          the binary output is 2MB for both 1.14 and 1.15. So I guess it’s pretty cool?

                                                                                          Also, since this release does shrink binary sizes, it shows that people are spending the engineering effort involved to shrink them.

                                                                                          1. 2

                                                                                            Ah sorry, I didn’t actually bother to verify my poor memory there. Thanks.

                                                                                      2. 1

                                                                                        Yes. I wish there was something like Go that could produce relly tiny ELF files.

                                                                                        1. 3

                                                                                          Does tinygo help?

                                                                                          1. 2

                                                                                            Have you looked at upx? Shrinks my Go binary by 50%.

                                                                                            -rwxr-xr-x   1 mikeperham  staff   5910544 Aug 12 12:32 faktory
                                                                                            -rwxr-xr-x   1 mikeperham  staff  11506756 Aug 12 12:32 faktory-big
                                                                                            

                                                                                            https://upx.github.io

                                                                                            1. 3

                                                                                              It helps, but I’m thinking that an “hello world” ELF file making one system call to print the message and one to exit the program should take less than two kilobytes, not close to two megabytes (or more).

                                                                                              What is the Go compiler storing in a “hello world” executable to make it that large, and more importantly: why are unused bytes not automatically removed?

                                                                                              1. 3

                                                                                                Compared to C, there’s the addition of a garbage collector and a unicode database, at minimum.

                                                                                                1. 1

                                                                                                  But there already is a Unicode database in your system?

                                                                                                  1. 2

                                                                                                    Can you provide a list of all of the locations for all of the unicode databases on every one of these systems: https://github.com/golang/go/blob/master/src/go/build/syslist.go#L10

                                                                                                    Additionally, provide the methods of interfacing with them, what their differences are, and what their commonalities are? Please be sure to do that for every version of Go for the last 10 years.

                                                                                                    Too much work? I agree.

                                                                                                    1. 1

                                                                                                      Not one designed for fast in-memory access using, say, a paged array data structure. You really don’t want to parse and convert the UnicodeData.txt files provided by the unicode consortium into a reasonable query structure every time you start a binary that does text processing.

                                                                                                  2. 1

                                                                                                    You want Rust? Go always includes a managed runtime for GC, et al.

                                                                                                    1. 1

                                                                                                      No, I get that Go and Rust aims for different things, but I don’t understand why the runtime is included if it’s not being used.

                                                                                                      1. 2

                                                                                                        Because for any non-trivial program, the runtime will be included. Why care about optimizing binary size of a program that is useless?

                                                                                                        1. 1

                                                                                                          Embedded platforms often require small sizes. And I would love to use Go for writing a 4k demoscene demo, if it had been possible.

                                                                                                          Regardless of the above, why include unused bytes in the first place?

                                                                                                          1. 2

                                                                                                            Because there’s engineering effort involved both in initial implementation and long term maintenance. Approximately zero programs would benefit from that engineering effort.

                                                                                                            1. 1

                                                                                                              I agree that there is effort required to implement it in the first place, but fewer bytes emitted usually results in a lower maintenance cost. That’s my intuition, at least.

                                                                                                              All it takes is one dedicated developer that decides to send a pull request.

                                                                                                              1. 2

                                                                                                                I think you are misestimating multiple things.

                                                                                                                1. The set of useful programs that do not use the runtime. You cannot allocate, use goroutines, use channels, use maps, use interfaces, or large portions of the reflect library, just to get started.
                                                                                                                2. The effort involved to make the runtime removed from the small programs that don’t use it. The dead code elimination required is a non-trivial problem due to things like package initialization, generating tracebacks on crashes, etc.
                                                                                                                3. The ongoing effort involved in maintaining that code. It would have to remain under test, work on all of the environments that support it, etc. That the compiler outputs less bytes in some specialized programs that can basically only add numbers does not imply that there would be less things to maintain going forward.

                                                                                                                There is no calculus that makes this a useful optimization. The developers consistently have been putting in large efforts (like rewriting the linker, for example) to get even marginal (1-5%) reductions in binary size. Not every idea is a good one.

                                                                                                    2. 1

                                                                                                      should take less than two kilobytes

                                                                                                      Compiled a simple “hello world” in both C and Go to static binaries and stripped them.

                                                                                                      -rwxr-xr-x 1 rjp rjp 715912 Aug 14 08:42 hw-c
                                                                                                      -rw-r--r-- 1 rjp rjp     97 Aug 14 08:41 hw.c
                                                                                                      -rwxr-xr-x 1 rjp rjp 849976 Aug 14 08:42 hw-go
                                                                                                      -rw-r--r-- 1 rjp rjp     52 Aug 14 08:41 hw.go
                                                                                                      

                                                                                                      This is GCC 10.1.0, Go 1.14.6 on Linux 5.7.5-arch1-1, x86_64.

                                                                                                      If I upx them, I get

                                                                                                      -rwxr-xr-x 1 rjp rjp 283608 Aug 14 08:42 hw-c
                                                                                                      -rwxr-xr-x 1 rjp rjp 346748 Aug 14 08:42 hw-go
                                                                                                      
                                                                                                      1. 1

                                                                                                        Yes, I dont get why those has to be that large either. Very few assembly instructions are needed.

                                                                                              1. 7

                                                                                                In short, I think it’s become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet.

                                                                                                YES. People complain about distro packaging being too slow-moving, and while that can indeed be problematic, it also provides curation, and there is value in that.


                                                                                                I’ve started toying with rust recently. On the whole I like the language, and there’s a lot of useful stuff available in the crates ecosystem. But I really wish the stdlib were more batteries-included (no rand()? seriously?) so I didn’t have to wade into the murky territory of trying to judge the relative quality/stability/maturity levels of third-party crates so often.

                                                                                                1. 8

                                                                                                  Entertainingly, C/POSIX’s rand() is a pretty good example of something, from a stdlib author’s perspective, why you really might not want somethinv in the standard library. Or at least, you don’t want its algorithm standardized… but different algorithms may have different seeding requirements, and different properties, so you end up with the possibility of needing to break standard API’s, or add new ones and deprecating old broken ones as you go. Or you end up with prolific nonstandard variants anyway, at which point, why is it in the stdlib? It just becomes a land-mine for new users to step on.

                                                                                                  None of this takes away from your point, which is very valid, I was just entertained you chose such a perfect counter-example. :D

                                                                                                  1. 2

                                                                                                    Or, since these problems are well-known by now, you do like Swift’s random(in:using:), which can be fed with any RandomNumberGenerator you can come up with.

                                                                                                    Avoiding doing anything because prior art is not good enough is easy for the implementor, but not for anyone else.

                                                                                                    https://developer.apple.com/documentation/swift/int/3020586-random

                                                                                                    1. 2

                                                                                                      Yeah, I know rand() has some nontrivial aspects of its design & implementation (and I certainly didn’t mean that as advocating emulating the C API), but I think there’s enough other prior PRNG API art out there to look at and learn from that it still strikes me as a pretty glaring omission. Date/time handling is in a very similar space – yes, there’s a high ratio of intrinsic complexity to superficial simplicity, but to not even try and just punt it completely to third-party libs is…pretty disappointing.

                                                                                                    2. 3

                                                                                                      That’s one of my greatest complains with Rust as well. Unfortunately, it’s even worse than rand(). Asynchronous I/O, which is needed by most non-trivial projects is also not standardized. Instead we have hundreds of reinventions of the same wheel, which leads to a lot of incompatibilities when you start to use heaver libraries.

                                                                                                      1. 3

                                                                                                        … so I didn’t have to wade into the murky territory of trying to judge the relative quality/stability/maturity levels of third-party crates so often.

                                                                                                        After a while you know which crates you trust for various tasks, or even which crate authors you like. But that’s an obstacle in getting into knowing a new language for sure.

                                                                                                        There’s also the cargo crev effort https://web.crev.dev/rust-reviews/ – i’m in two minds about it. Once you get a “review” there, it might be negative and talk about problems that are not present anymore. It also focuses a bit too much on “unsafe”.

                                                                                                      1. 4

                                                                                                        It’s a cheap polemic but I basically agree. Most newer languages do allow non-ASCII characters in identifiers, and I’ve seen Swift code that uses this in useful ways (using π or θ) and silly ones (emoji variable names!) But they still seem to restrict custom operators to a limited set of ASCII punctuation, and I don’t know any that have built-in non-ASCII syntax.

                                                                                                        I suspect part of it is that Windows makes it too hard to type such characters. I know it used to be that you’d have to hold down Alt and type a memorized three-digit number. I don’t know if that’s improved, and I don’t know how Linux/BSD handle it.

                                                                                                        But Mac OS always had really simple keystrokes for common characters, like Option-P for π, and Option-(Shift-)-[ for « and ». As a result, in 1991 when I invented a DSL for assembling AppleEvents (kind of Stone-Age protobufs) I used those angle-quotes as delimiters for hex/binary strings, no biggie.

                                                                                                        1. 3

                                                                                                          Swift actually allows certain non-ASCII Unicode ranges for operators, though still excluding other ranges (for example, is not a valid operator). I have used a ° postfix operator for converting degrees to radians, for instance.

                                                                                                          https://docs.swift.org/swift-book/ReferenceManual/LexicalStructure.html#ID418

                                                                                                          1. 1

                                                                                                            It’s a weird criticism of Go, given that Go mandates that the input file format is UTF-8 and allows any identifier that starts with a character that unicode considers to be a letter to be a valid variable name.

                                                                                                          1. 2

                                                                                                            It should be noted that even though C++ has officially deprecated trigraphs, the language is still dependent upon digraphs. Some notable cases are != for and >= for . The same applies to almost all C-styled languages to this day, with no alternatives on offer.

                                                                                                            1. 1

                                                                                                              I live this quote from Coders at work:

                                                                                                              C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine.

                                                                                                              1. 1

                                                                                                                Daniel Berlin’s response to this line is worth reading.
                                                                                                                The TLDR is that research on autoparallelization for C advanced the state of the art.

                                                                                                              1. 19

                                                                                                                Great points about editing, but the use case shouldn’t be glossed over: “You might need to edit files via SSH.”

                                                                                                                It’s wonderful to have the powerful edit commands, but this use case shouldn’t be understated. Every time I’ve needed to edit or examine a file on a remote linux server, VIM’s always been there.

                                                                                                                I’ve spent thousands of hours writing code in VIM, but it’s not a true IDE. However, it doesn’t require X running, uses few resources itself (plugins are another matter), has regex search/replace built in, and you can run it inside screen or tmux in case your connection drops or to resume editing sessions. Knowing VIM in 2020 is like showing up to a job site and your toolbox is already there.

                                                                                                                1. 16

                                                                                                                  The other side of editing over SSH is Emacs and TRAMP mode: Use your local Emacs to transparently edit files over SSH. The remote system doesn’t need to have any editors at all installed, necessarily.

                                                                                                                  https://www.emacswiki.org/emacs/TrampMode

                                                                                                                  1. 7

                                                                                                                    TRAMP also allows you to use your local emacs setup and doesn’t incur network latency when editing, neither of which apply to vim through ssh.

                                                                                                                    1. 5

                                                                                                                      And it allows you to have different buffers in the same Emacs instance connected to different remotes. This means, among other things, that you can use dual-pane (orthodox) file manager Sunrise in Emacs with each pane pointing to a different remote, and copying and editing files between them as if they were both local.

                                                                                                                      1. 1

                                                                                                                        Can it keep a single buffer for multiple remotes? To push all changes in the buffer to all of the remotes.

                                                                                                                        1. 2

                                                                                                                          That’s not something I’ve explored. My best guess would be “no, not out of the box, but probably combined with some other mode that keeps multiple buffers synchronised.”

                                                                                                                          1. 1

                                                                                                                            Isn’t some sort of source control a better tool for this task?

                                                                                                                    2. 7

                                                                                                                      People always bring up this point, but - and I say this being proficient with both vim and emacs - for those who aren’t doing sysadmin/devops/sre work, is this a good reason to spend time learning more than insert mode, arrow keys, esc, and :wq? And for those who are in the business of regularly editing files remotely: don’t they already know? For those of us who don’t spend a lot of time connecting to remote machines:

                                                                                                                      • How often should we be editing files on remote hosts? Don’t we have “better” tools for configuring remote machines, e.g. ansible?
                                                                                                                      • I’m only ever connecting to remotes that I’m in control of. If I need a program to be available, it’s easy to make it happen.
                                                                                                                      • The few times I do have to edit a file on a remote host, I typically only have to make small edits to unbreak something. What degree of competency with an editor is really required to change a few lines?
                                                                                                                      • If I weren’t comfortable with vim, but needed to do some heavy lifting on a remote, many editors have features for making this happen.
                                                                                                                      1. 2

                                                                                                                        You might edit files on remote servers rarely but I do it all day every day. For the reasons mentioned in sibling posts, tramp on emacs makes it both a transparent and rich editing experience.

                                                                                                                        1. 1

                                                                                                                          is this a good reason to spend time learning more than insert mode, arrow keys, esc, and :wq?

                                                                                                                          On my terminal setup, arrow keys aren’t interpreted correctly so I have to use hjkl ;)

                                                                                                                          Also :q! is great for when you’ve messed everything up and need to start over…

                                                                                                                        2. 2

                                                                                                                          If I wrote a post on vim I would deliberately skip this point because I get so little value out of it that it feels almost derogatory to how great modal editing is to make a big deal about just being there.

                                                                                                                          I seem to be alone in how small a percentage of my time is spent doing serious editing on remote servers though.

                                                                                                                          1. 2

                                                                                                                            Not necessarily, considering that part of Vi’s history is that it was developed in high-latency environments, where you wanted to compress as much “editing information” into as few keystrokes. This fact still turns out to be helpful over slow connections today. Holding backspace for a few seconds and then undo because (due to the lag) it went a few characters too far, is more annoying that pressing dd to remove a line.

                                                                                                                            1. 3

                                                                                                                              Holding backspace for a few seconds and then undo because (due to the lag) it went a few characters too far, is more annoying that pressing dd to remove a line.

                                                                                                                              I can’t tell if this example is representative of how Vi users use non-Vi text editors (holding backspace for a few seconds to delete a line) or if this is representative of how Vi users think users of other text editors delete a line.

                                                                                                                        1. 3

                                                                                                                          My first thought is: People still use Rails?

                                                                                                                          Of course when I think about it, there is that famous curve where you have a huge uptick in a lot of coverage of a thing, with relatively few users in the grand scheme of things (but it appears like everyone is using it depending on what news bubble you are in). That been quite a few years ago now, so it is probably fair to say that Rails is quite mature at this point.

                                                                                                                          The only thing I don’t know: this the mature phase where usage increases slowly, or where usage decreases such that it eventually disappears?

                                                                                                                          As an aside, with the link to the Rails Doctrine I find it interesting to note when it talks about “Rails Migration of 2.x to 3” being painful, leaving a lot of people behind, and souring of others - it has a version number inline with python…

                                                                                                                          This article should be written for every framework or library :-).

                                                                                                                          1. 9

                                                                                                                            Notably, this site is written in Rails.

                                                                                                                            1. 1

                                                                                                                              That is interesting actually. I wouldn’t have excepted that.

                                                                                                                            2. 5

                                                                                                                              I’m still finding rails astonishingly productive if your team can handle the (significant!) ops overhead.

                                                                                                                              So many little details that work well.

                                                                                                                              1. 1

                                                                                                                                That is probably one of the things that kept me from ever bothering with it TBH. I find stuff like asp.net more straightforward.

                                                                                                                                1. 1

                                                                                                                                  It really depends on how much programming work is going to be required. If you’re planning to spend 6 weeks building and 6 years operating a site, rails doesn’t really make sense. If you expect to continually have multiple programmers work on the site, the operational overhead is negligible compared to the productivity advantages.

                                                                                                                                  1. 1

                                                                                                                                    That’s a very strong claim to make.

                                                                                                                                    Maybe in 2005 when RoR was considered cutting edge. But today?

                                                                                                                                    1. 1

                                                                                                                                      I’m honestly unclear which direction you think it’s strong in (I have heard much stronger opinions in both directions).

                                                                                                                                      For context, I have used rails for paid work during every calendar year since 2008, though some years only had a little bit of it. In that time, I’ve held various roles including the primary on-call, lead developer, devops setup person, and also run several sites using various tech stacks.

                                                                                                                                      Rails sites require a very different level of devops work to, say, golang. It’s typical for a rails app to require:

                                                                                                                                      • Multiple server roles (web, worker, periodic task trigger)
                                                                                                                                      • Multiple key/value stores (redis for sidekiq, memcached for caching)
                                                                                                                                      • A full webpack configuration
                                                                                                                                      • A relational database
                                                                                                                                      • Multiple third party APIs which don’t come with backoff configured (eg mailer, captcha)
                                                                                                                            1. 8

                                                                                                                              There are some really specious assertions in here.

                                                                                                                              I don’t use any of the extensions the author cites as the “best” parts of Visual Studio Code.

                                                                                                                              I also use vscodium instead of the Microsoft release because it’s been blessed by my employer’s security team and is 100% open source.

                                                                                                                              Sure, emacs and vim are amazing tools. I’ve used them productively for many years and will continue to do so, but I also use and love VSCodium as my editor of choice when I’m not on a remote server, and I don’t use any of the extensions the author cites.

                                                                                                                              I’m not suggesting anyone else use VSCode, I just want to be clear about the fact that the authors “Best parts” are at best highly subjective.

                                                                                                                              1. 6

                                                                                                                                I really want to use the Remote extension. The fact that it’s proprietary is not a problem, the fact that it is not very portable is. It basically runs a full VS Code headless on the remote end and so only supports the platforms where there are supported binary releases. I can’t run it on FreeBSD, for example, which is what my dev VMs typically run.

                                                                                                                                1. 3

                                                                                                                                  I found the Remote extension to be problematic in a number of ways.

                                                                                                                                  First, they didn’t market it very well :) It wasn’t at all clear to me when I first tried to use it that what’s really happening is I’m spinning up a headless VSCode on the remote system.

                                                                                                                                  That’s a log of Javascript and a lot of complexity. That kind of complexity makes security teams crazy, and I don’t blame them.

                                                                                                                                  It’s an incredibly powerful extension, but its massive scope and complexity makes it not make sense for the security conscious environments I tend to work in.

                                                                                                                                  1. 4

                                                                                                                                    Yes, I was quite surprised when I learned how it worked. I expected it to basically need to be able to launch a terminal to run build commands and to read / write files. Running other extensions on the remote side, rather than proxying read/write-file and run-command makes me really nervous.

                                                                                                                                2. 3

                                                                                                                                  As a (mostly) non-user of VSCode, looking in from the outside Remote and LiveShare (along with solid first-class LSP integration) absolutely look like a couple things that I can’t do as well in other editors at the moment. So while there are clearly other use cases and many people may not need them, I do think they are among the few things that actually clearly differentiate VSCode from other options.

                                                                                                                                  1. 3

                                                                                                                                    They’re only differentiators IMO if you can actually use them.

                                                                                                                                    As I mentioned in another response, the Remote extension is great but basically amounts to installing a headless VSCode on your remote host. That’s gonna be a total deal breaker in any environment where security is even remotely a factor.

                                                                                                                                    1. 4

                                                                                                                                      In the same way as installing Emacs or a compiler is?

                                                                                                                                      1. 2

                                                                                                                                        In the same way as installing Emacs or a compiler is?

                                                                                                                                        The reason that VS Code’s remote extension runs a headless VS Code is extensions. Any extension that you use may come with arbitrary binaries that it wants to run to provide some of the functionality. In theory, it’s no less secure than running it locally but it can make people nervous if the remote machine is a production machine - generally, crashing the developer’s desktop or running it out of memory is less of a problem than doing the same thing on production hardware.

                                                                                                                                        The big problem for me with this approach is that it limits the targets to machines with official VS Code binary releases. I think ARM Linux is now supported but if you want to develop on a remote *BSD / Solaris / whatever VM or PowerPC / MIPS / RISC-V / whatever system, it’s a problem.

                                                                                                                                        1. 1

                                                                                                                                          Actually potentially much worse.

                                                                                                                                          emacs and most mainstream compilers have been fairly well vetted by any number of different security teams.

                                                                                                                                          The problem IMO with the VSCode Remote extension is that it represents an arbitrarily large body of Javascript that can’t easily be audited.

                                                                                                                                        2. 2

                                                                                                                                          Fair enough. It still seems like it might be useful for development environments at least, but that is a pretty big concern.

                                                                                                                                          1. 1

                                                                                                                                            basically amounts to installing a headless VSCode on your remote host

                                                                                                                                            Well there’s no need for any proprietary extensions to do just that: https://github.com/cdr/code-server

                                                                                                                                            1. 1

                                                                                                                                              Have you actually tried / deployed this thing? I have, and it doesn’t do what you’re asserting here :)

                                                                                                                                              The Remote extension lets you run your VSCode front end Electron-esque GUI on your local workstation but act on files on a remote Linux server.

                                                                                                                                              The thing you’re pointing at here presents a web UI where you do everything, and it’s got some rather sincere limitations.