1. 4

    https://raw.githubusercontent.com/ForthHub/ForthFreak/master/4os

    Unsurprising that it was developed by Chuck Moore. Disappointing that it didn’t actually get to production.

    1. 3

      Disappointing that stuff like that doesn’t get open sourced. Just makes you wonder what interesting stuff is out there on an old floppy.

      1. 2

        Chuck likes to release his Forths as public domain (when he does release them…).

        1. 1

          In Chuck We Trust

      1. 2

        Forgot about this one, good to read again. What I don’t remember realizing was:

        Its not really a small company, dev team is around 40+ people

        That’s some wow. If you’re a 2-person startup hiring your first junior developer, it’s still bad practice, but kind of understandable to have full-permission creds to the production DB on an onboarding document that instructs the user to run a test script that wipes the database. But then, my personal toy projects that I don’t expect to ever get a significant number of real users on have better practices than that.

        If you’re at the 40 devs stage, it’s way, way past time to tighten things up. I’d bet like 80% of the devs knew perfectly well their practices were way too cowboy for their size, so management must have been firm on not improving them. Which makes the disaster 100% on their heads.

      1. 14

        The worst was starting at Nickelodeon in early 2008. To begin with, the hiring process was really weird and took months. I mean months after I did my final interview. I ended up accepting another job, but they called during my 2-week wind down at my previous gig, so I just switched to going there instead.

        I showed up for work and they had no desk. Then they found a spot I could use, but had no computer. Eventually they found an old one no one was using and let me have it. It was a terrible machine, probably one of those bulk discount machines you see at places like Best Buy. Then they had no monitor. I had to wait the majority of the day for them to find me an old CRT that flickered like crazy.

        After that whole mess, I spent a full week with nothing to do. Someone printed out the docs for JBoss and put them on my desk to read. I kept asking for work, but they weren’t sure what to give me.

        It was, by far, the worst onboarding experience I’ve ever had. But it was also the place I worked at the longest. Funny how that works out.

        1. 9

          It was, by far, the worst onboarding experience I’ve ever had. But it was also the place I worked at the longest. Funny how that works out.

          Why did you stick around? What was worthwhile about the job?

          1. 4

            I really liked the people I worked with there. I still have friends who have also moved on, and I worked at a startup with a few of them about a year after I left (which lasted about 2.5 years before crumbling).

            It wasn’t groundbreaking work, but we had fun for the most part.

        1. 2

          Going to Spain for the next two weeks. My cousin is getting married next Saturday. First time I’ll have seen a lot people since 2011.

          1. 10

            Probably because wasm adds incremental benefit that’s only really worth it in special and relatively-unique circumstances, e.g. web-based 3d game engines. Otherwise the incremental benefit doesn’t really outweigh the costs.

            Web developers are happy with javascript, backend developers are happy with their existing runtimes.

            1. 3

              I was thinking about another potentially good fit for WASM, which is not front or back end. Web-based “native”-like apps. Web-based native apps are often RAM-hungry and unresponsive if too heavy on JavaScript. WASM can be a pretty good solution here. Having snappy desktop apps without sacrificing dev productivity nor performance.

              1. 5

                If it’s a desktop app, why wouldn’t you just use native code with an existing desktop app platform to directly address those performance issues? What advantage does wasm give you in that case?

                1. 5

                  I can see it becoming a decent JVM competitor.

                  1. 5

                    What advantage does wasm give you in that case?

                    It would be a web app, biggest advantage is instant update to latest version for everyone.

                  2. 4

                    Presumably cross-platform utility. Like Electron, but faster.

                    1. 4

                      The problem with Electron is mostly not the speed of JavaScript, though. It’s mostly the RAM usage of bundling in most of a web browser as runtime for every app. Just switching to WASM doesn’t do anything to solve that part; you also need a lighter cross-platform GUI framework.

                      1. 3

                        Thanks for the clarification - I’m not intimately familiar with how Electron works “under the hood”.

                        1. 1

                          Would the inefficiency of Atom with larger files (not big in terms of storage space but big enough to make Atom crawl)—not as big of an issue with VS Code, in my experience—be at all helped by using WASM? That seems like it should be a case for needing a faster language, but I’m not sure.

                      2. 1

                        From a corporate IT perspective:

                        With a web app you have a better upgrade story. You don’t have a bunch of different versions floating around in the world that you have to support. When you upgrade the site, everyone gets that site. Similarly, when you need to rollback, you just rollback. Nobody needs to know or care.

                        edit Well, should have kept reading. Marius said what I said, but more concisely.

                  1. 6

                    It’s been a while since the 70s. I wonder if there have been any chemistry advances–within hobbyist reach–for making a larger, slower, less energy-efficient processor using a less precise and less hygienic process?

                    1. 2

                      Man, that reminds me of an idle thought I once had: I wonder how many hobbyist genetic engineers there are out there just mucking around with whatever is available to them. Apparently it’s a thing:

                      https://www.nytimes.com/2018/05/14/science/biohackers-gene-editing-virus.html

                      So to keep the thread on topic are we going to get a Fallout future or a Bioshock future?

                    1. 7

                      Aside from the main point, am I alone in wincing at

                      This project would have 75% test coverage as reported by CI

                      especially if that means “line coverage”, you’ll end up with tons and tons of untested error-handling paths, in a product that was apparently Rather Important…

                      (But I’m working in a very different domain and have mostly been doing non-coding work for a while, so I may be out of touch?)

                      1. 4

                        Yeah, they ain’t like us. It’s more Move Fast and Break Things or Keep Legacy Systems Running and Growing Forever out there with minimal QA. It’s why I switched focus to automated methods for QA that get results quickly and with minimal effort by developers. Until regulation or liability hits, most won’t adopt anything that requires much effort.

                        1. 1

                          What would be your greatest hits version of “automated methods for QA that get results quickly and with minimal effort by developers”?

                      1. 43

                        I would guess that a very substantial proportion of the people who read Lobsters have heard of Timsort.

                        1. 22

                          That, and TimSort really only makes sense in certain situations:

                          • Comparisons have to be extremely expensive. Think dynamic dispatch. This is because TimSort itself performs a bunch of branches and integer comparisons to keep track of galloping scores and the stack invariant.

                          • You need a stable sort. If you don’t need a stable sort, pattern defeating quicksort will probably do better.

                          1. 11

                            Quicksort is the Achilles of sorting algorithms: unbeatably fast, easy to implement, in-place; but with the vulnerable heel of bad worst-case performance (the worst case being pre-sorted data in the naïve implementation) and instability.

                            1. 5

                              There’s a fairly easy fix to that, called introsort: start with quicksort, but bail out to a guaranteed O(n log n) sort like heapsort if it takes too long. In the bail-out case, you lose constant-factor performance compared to if you had used heapsort in the first place, but you avoid quicksort’s O(n^2) worst case, while still getting its good performance in non-pathological cases. It’s used in practice in .NET and some C++ STL implementations.

                              1. 3

                                Quicksort -> Heapsort is method I used. It worked fine in practice. I love solutions like that. Another, unrelated one was sklogic’s trick of using a fast, dumb parser first to see if it’s correct. If it wasn’t, he switched to one that made error messages easier.

                                I bet there’s more of this stuff waiting to be found for situations where people are shoving every case into one algorithm.

                            2. 4

                              Comparisons have to be extremely expensive. Think dynamic dispatch.

                              That explains why Python uses it as it’s standard sort.

                              1. 9

                                Yeah. That’s exactly why Python uses TimSort.

                                More tellingly, where Rust uses an algorithm that’s related to TimSort for its stable sorting algorithm, they didn’t implement “galloping” because it’s not worth it. https://github.com/rust-lang/rust/blob/7130fc54e05e247f93c7ecc2d10f56b314c97831/src/liballoc/slice.rs#L917

                            3. 10

                              I consider myself relatively knowledgeable about many different topics of CS and had not heard of Timsort until this article. What’s the point of your comment? That the article is not worth posting as you presume that it is widely known?

                              1. 4

                                The point is that the title of the article, and of this submission, is inaccurate. I would call the title clickbait because for most readers, the article doesn’t deliver what it promises – a sorting algorithm “you’ve” never heard of. I think the article itself is fine; it’s just the title that is a lie.

                                1. 5

                                  That seems to be a really low-value comment. For whom is the remark actually intended? For other crustaceans to look at, nod and agree, thinking, “yes, I too possess the superior knowledge”? Does every submission with a title that invokes “you” need to be correct and ‘deliver on its promise’ for all possible “you”s? C’mon.

                                  1. 4

                                    Yes, I suppose jgb could have been more explicit in why they brought up their guess. (I wrote an explanation of my interpretation of the comment, not the original comment.)

                                    Does every submission with a title that invokes “you” need to be correct and ‘deliver on its promise’ for all possible “you”s?

                                    I think every article with a title that invokes “you” needs to be correct and ‘deliver on its promise’ for the majority of possible “you”s in its audience. If a title says “you’ll love this” and most readers don’t love it, the title was wrong, and it wasted people’s time by getting them to open the article on false pretenses. It is up to article authors to adhere to that principle or not.

                                    As for titles of submissions of articles with clickbait titles, there can be a conflict between submission titles that reflect the author’s intent and titles that accurately describe the article. I don’t have a simple answer as to when submission titles should differ from the article title.

                                    1. 3

                                      I think every article with a title that invokes “you” needs to be correct and ‘deliver on its promise’ for the majority of possible “you”s in its audience.

                                      I think I agree with this, and I think my concern comes down to disagreeing instead with the notion that the majority(/“a very substantial proportion”) of Lobsters readers have heard of Timsort. Short of a poll there’s not an actual answer to that; I just felt particularly rankled because I hadn’t, and presumably if I had I wouldn’t have bothered or thought to comment myself.

                                      I err on the side of preserving the article title in the submission, which I think is pretty common. Accordingly, I think most Lobsters are primed to see submission titles that aren’t necessarily addressing them as Lobsters readers, but in some context that might be quite removed.

                              2. 2

                                I thought it played a pretty big role in the Oracle vs. Google lawsuit too, making it one of the more famous algorihtms.

                                However see “rangeCheck” mentioned a lot, which is a trivial part of TimSort.

                                https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.

                                Here it seems to cite TimSort. But for some reason I can’t find a lot of sources that talk about TimSort and the lawsuit, even though at the time I remember it being a prominent thing.

                                https://forums.appleinsider.com/discussion/149435/google-engineers-defend-source-code-email-in-oracle-lawsuit-over-java/p4


                                edit: here’s another one mentioning TimSort and the lawsuit.

                                https://majadhondt.wordpress.com/2012/05/16/googles-9-lines/

                                Googling “rangeCheck timsort lawsuit” digs up some results.

                              1. 8

                                Reluctantly flagged off-topic as it’s about economics and marketing, not computing.

                                1. 19

                                  From a nerd’s perspective I liked this - it was written well, held the interest and was about an interesting topic that intersects math and psychology. I consider it on-topic for this site.

                                  1. 6

                                    I agree it’s good content. But it’s still off-topic. I’m just one voice. I’m not gonna go mad if others upvote it.

                                  2. 13

                                    I’ll note that there is a (finance) – Finance and economics tag that seems to have content somewhat similar to this. Given that that’s one of the predefined tags on this site, that suggests to me that this post is not wholy off-topic here and is simply mis-tagged. Personally, I found it well written and fairly interesting.

                                    Edit: It appears that events have overtaken me. In the time it took me to write this, the tag has been corrected from (hardware) to (finance).

                                    1. 5

                                      I didn’t realize there was a finance tag! I will remove my flag.

                                    2. 4

                                      I know the policies and culture of our site have evolved over time. The most upvoted thing I’ve ever posted anywhere (2017) wouldn’t be appropriate to post here today.

                                      How do we feel about this?

                                      “Reluctant” could describe my feelings. I enjoy this site being a source for on-topic content, and I am willing to protect it from becoming a cesspool.. I support efforts to remove off-topic content even if (and sometimes especially if) it is good or engaging.

                                      But like… I also love this post and I’m glad I read it.

                                      Should the lobste.rs community spawn an off-topic site or sub forum or something? (it’s just a question!)

                                      1. 9

                                        I never liked this obsession with The Topic™, I’d love to see more of this on the main site instead of some spin-off nobody would use.

                                        1. 8

                                          I’d agree. At this time this is one of the most upvoted stories on the front page. To me that says the community has decided that it is, in fact on topic. If it wasn’t, it’d be downvoted.

                                          1. 1

                                            It would be nice to have a series of integrated sites that were more focused and preselected than subreddits. E.g. having a business oriented site (like barnacles) that had tags for finance, auctions, economics, etc. would be pretty nice.

                                          2. 3

                                            That’s exactly the problem–I think it’s a totally interesting and neat article, and well-done, but my rough bucket is “analysis of the economics of a luxury good”. And it pains me, but like there’s a lot of interesting content out there that can clog up a site like this pretty quickly.

                                            I think an off-topic site for this, say the massive discussion on the orange site, would be a fine place for this.

                                            1. 3

                                              I think an off-topic site for this, say the massive discussion on the orange site, would be a fine place for this.

                                              I think an off-topic sister site based on the Lobsters codebase would be pretty good, too. It’s so much easier to use this site than to try to follow (or participate in) what’s going on in orange site discussions.

                                          3. 3

                                            Dammit.

                                            1. -3

                                              Agreed

                                            1. 2

                                              What about programming-puzzle games, like TIS-100 or Human Resource Machine?

                                              1. 2

                                                SHENZHEN I/O also had a cute architecture

                                                1. 1

                                                  Baba is You is basically logic programming.

                                                1. 4

                                                  There’s i.e. PICO-8 “fantasy console”, but I’m not sure this fits your criteria (http://www.lexaloffle.com/pico-8.php).

                                                  1. 6

                                                    If it does, there’s also clones/homages like the TIC-80

                                                    1. 3

                                                      In that vein, there’s also LIKO-12, quadplay+, and pixel vision 8.

                                                      There are ports of PICO-8, too (at least PicoLove, PX8, and JSGS), though I don’t know if they’re relevant (they don’t define a new VM, just reimpliment an existing one).

                                                      There’s also a number of abandoned (or seemingly abandoned) retro-consoles, including NEKO-8, Unicorn Console, and Load81.

                                                      1. 1

                                                        Is the PICO-8 open source? The site makes it look like it’s proprietary, but it seems weird to make your game on someone’s software platform. (I can’t tell why that feels stranger than flash games.)

                                                        1. 2

                                                          It is not open source, which (I suspect) is one of the reasons that people created TIC-80, LIKO-12, etc.

                                                      1. 2

                                                        There’s nothing stopping us from making an ABC for “iterables that aren’t strings”…

                                                        Oh my god, the bane of my existence.

                                                        1. 7

                                                          It’s really nice to have relatively boring rustc releases.

                                                          1. 3

                                                            It’s the calm before the storm. :D

                                                            1. 2

                                                              What’s the storm looking like?

                                                              1. 6

                                                                async/await is landing in next release and that’s going to cause a storm in the ecosystem for sure.

                                                                1. 4

                                                                  Which also means it is now in the beta chanel & Rust’s beta builds are incredibly stable in my experience.

                                                                  1. 2

                                                                    Ooh I should try it out. I usually use beta by default, just to ensure I’m not writing anything that will produce surprises on the next stable release. Hasn’t happened in a long time, but it can happen.

                                                          1. 4

                                                            Been reading Designing Data Intensive Applications for a bit. Slowed down in the chapter on replication, but overall I’m enjoying it quite a bit.

                                                            1. 3

                                                              This is on my bookshelf but I haven’t opened it yet. I’m moving it up in the queue.

                                                              1. 3

                                                                Yeah, I’ve got a lot of those. Looking through the table of contents got me pretty jazzed though. I’d recommend having a look, it might give you the motivational boost to crack it open.

                                                            1. 5

                                                              Warning, rant ahead. I’m very excited about Gleam and I think it’s a fantastic idea. I think there are scenarios where having static types could be a boon for people using BEAM. Below is me throwing a fit about syntax so if that’s not your thing just ignore it :).

                                                              I don’t really understand why people use ML style programming, with ML style constructs, with C style syntax. You aren’t making it easier for people who know C, the hard part is learning the paradigms not the syntax. You are making it harder for me to port over code I’ve written in other languages that are actually similar in paradigm. If I actually end up using this I’ll probably just write like a syntax translator from ML style to this. It’s very frustrating to have people consistently reinventing the wheel when the original syntax is fine. Small tweaks are one thing but it’s like if I wrote a C# clone with lisp syntax. The syntax does nothing to serve the actual usage of the language.

                                                              In the end I’ll probably just use Alpaca instead, which doesn’t try to be clever.

                                                              https://github.com/alpaca-lang/alpaca

                                                              1. 7

                                                                Hi, I’m the author of Gleam. I’ve heard this a few times and I’d like to say that just like Alpaca Gleam is explicitly not trying to be an ML language. It is inspired by ML but it is also just as inspired by Rust, Erlang, and a variety of other languages.

                                                                Gleam has several differences compared to ML that I think make it unsuited to ML syntax, the most obvious one being that it does not have automatic currying or partial application.

                                                                Personally I’m less interested in syntax and am happy with both ML and C family style syntaxes (mildly preferring ML), but from looking at ReasonML and mentoring beginner programmers I do think that familiarity goes a long way to making a language approachable. Gleam aims to be friendly and welcoming to people of all experiences and backgrounds, and my working theory is that C style syntax is less of a barrier to entry.

                                                                1. 6

                                                                  OK I’ll bite… I think Reason was a good idea because OCaml’s syntax was a significant barrier to me using it (after using 10+ languages and knowing 5 quite well.)

                                                                  I wrote a fair bit of OCaml around 5 years ago, and I didn’t have problems with the syntax then, while it was fresh. Now I encounter it in research papers all the time and I can’t read it :-/ To be fair it’s a pretty big language and there are definitely parts of it I didn’t learn.

                                                                  I think they make some good critiques here:

                                                                  https://reasonml.github.io/docs/en/comparison-to-ocaml#various-improvements

                                                                  https://www.reddit.com/r/ocaml/comments/3xvr6n/ocaml_syntax/

                                                                  Syntax is obviously personal, but it obviously matters too :)

                                                                  1. 2

                                                                    They’re doing it because developers have an irrational love of and hatred toward various syntax. The industrial languages with the most adoption kept a C-like syntax for this reason. Probably wise for others to do the same if pulling in programmers using languages like that. If aiming for ML programmers, use ML-like syntax.

                                                                    Personally, I’ve argued for new languages to have multiple syntax with the same or similar semantics. Plus, converters for them. Then, people can just use the syntax they prefer. They pull in the source, the converters shift the syntax to their preference, they do their contributions, and submit with others’ converters doing same for them.

                                                                    1. 2

                                                                      I’ve thought about syntax converters when I’ve come across minor annoyances in syntax, but I can’t imagine that it would be well received in an industrial language. Look at gofmt’s standardization on basic formatting. Additionally, if the secondary syntax was third party created, I can imagine the temptation would be to avoid certain patterns or features in the base language thereby producing a semantically new language.

                                                                      Still it might be nice for minor changes. E.g., if you prefer english language keywords (begin, end, not, and, or, etc.) vs punctuation keywords ({, }, &&, ||, !, etc.), then simple manual transformation wouldn’t be too bad.

                                                                  1. 45

                                                                    RustTL;DR: It’s a very impressive language with a clear vision and priorities, but the user interface needs a lot of work. Also, the collection library is much better than Scala’s.

                                                                    • Generics with <>. It’s 2017 by now, we know it’s a bad idea. One of the reasons why the language suffers from abominations like the “turbofish” operator ::<>.

                                                                    • Strings don’t offer indexing, because it doesn’t make sense for UTF-8. Correct! But Strings offer slicing … WAT?

                                                                    • Misuse of [] for indexed access. Having both () and [] doing roughly the same thing, especially since [] can be used to do arbitrary things, doesn’t make sense. Pick one, use the other for generics.

                                                                    • Inconsistent naming. str and String, Path and PathBuf etc.

                                                                    • :: vs. . is kind of unnecessary.

                                                                    • Mandatory semicola, but with some exceptions in arbitrary places: struct Foo; vs. struct Foo {}

                                                                    • Arbitrary abbreviations all over the place. It’s 2017, your computer won’t run out of memory just because your compiler’s symbol table stores Buffer instead of Buf.

                                                                    • Can someone decide on a casing rule for types, please, instead of mixing lowercase and uppercase names? Some types being “primitive” is an incredibly poor excuse.

                                                                    • Also, having both CamelCase and methods_with_underscores?

                                                                    • Library stutter: std::option::Option, std::result::Result, std::default::Default

                                                                    • iter(), iter_mut(), into_iter() … decide prefix or postfix style and stick with it.

                                                                    • Coercions do too many things. For instance, they are the default way to convert i32 to i64, instead of just using methods.

                                                                    • Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                    • Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                    • Forward and backward annotations: #[foo] struct Foo {} vs struct Foo { #![foo] }. Also /// for normal documentation, //! for module level documentation. Documentation already uses Markdown, so maybe just let people drop a markdown file in the module dir? That would make documentation much more accessible when browsing through GitHub repositories.

                                                                    • Also, documentation can cause compiler errors … that’s especially fun if you just commented a piece of code for testing/prototyping.

                                                                    • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                    • Macros are not very good. They are over-used due to the fact that Rust lacks varargs and abused due to the fact that they require special syntax at call-site (some_macro!()).

                                                                    • Pattern matching in macros is also weird. x binds some match to a name in “normal” pattern matching, but matches on a literal “x” in “macro pattern matching”.

                                                                    • println! and format! are very disappointing given that they use macros.

                                                                    • Compiler errors … ugh. So many things. Pet peeve: “Compilation failed due to 2 errors” … 87 compiler errors printed before that.

                                                                    1. 7
                                                                      • Library stutter: std::option::Option, std::result::Result, std::default::Default
                                                                      • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                      How ya gonna square that circle?

                                                                      1. 2

                                                                        I think std::io::IoResult would be fine – it would solve the issue of having vastly different Results flying around, while not having single-use namespaces that are only used by one type.

                                                                        1. 1

                                                                          The general pattern is to import Io instead. When doing this, IoResult would be jarring.

                                                                          use std::io;
                                                                          
                                                                          fn my_fun() -> io::Result<T> {
                                                                          
                                                                          }
                                                                          
                                                                      2. 13

                                                                        It’s 2017,

                                                                        I have some news for you, @soc.

                                                                        1. 3

                                                                          Haha, good catch. Now you see how old this list is. :-)

                                                                          The only thing I got to delete since then was “get rid of extern crate”.

                                                                        2. 3

                                                                          What’s your preferred alternative to generics with <>?

                                                                          1. 6

                                                                            [], as it was in Rust before it was changed for “familiarity”.

                                                                            Unlike <>, [] has a track of not being horribly broken in every language that tried to use it.

                                                                            1. 5

                                                                              How is <> broken?

                                                                              1. 16

                                                                                It complicates parsing due to shift and comparison operators.

                                                                                1. 2

                                                                                  Ah, yeah, that makes sense.

                                                                                2. 19

                                                                                  Pretty much no language has ever managed to parse <> without making the language worse. The flaws are inherent in its design, as a compiler author you can only pick where you place the badness; either:

                                                                                  • Add additional syntax to disambiguate (like ::<> vs. <> in Rust).
                                                                                  • Have weird syntax to disambiguate (like instance.<Foo>method(arg1, arg2) in Java).
                                                                                  • Read a potentially unlimited amount of tokens during parsing, then go back and fix the parse tree (like in C#).
                                                                                  • etc.

                                                                                  In comparison, here are the issues with using [] for generics:

                                                                                  • None.

                                                                                  For newly created languages (unlike C++, which had to shoehorn templates/generics into the existing C syntax) it’s a completely unnecessary, self-inflicted wound to use <> for generics.

                                                                                  More words here: Why is [] better than <> for generic types?

                                                                                  1. 2

                                                                                    Those are good reasons to not use <>, but as a Haskeller I personally find either style somewhat noisy. I’d rather just write something like Option Int. Parentheses can be used for grouping if needed, just like with ordinary expressions.

                                                                                    1. 2

                                                                                      Haskell feels like it is in the same category as D, they both just kicked the can a tiny bit further down the road:

                                                                                      Both need (), except for a limited special-case.

                                                                                      1. -1

                                                                                        I don’t see how Haskell kicked the can down the road. The unit type is useful in any language. Rust has a unit type () just like Haskell. Scala has it too.

                                                                                        I’m not sure what “special case” you are referring to.

                                                                                        1. 2

                                                                                          The fact that you still need () for grouping types in generics as soon as you leave the realm of toy examples – just as it is in D.

                                                                                          (Not sure what’s the comment on the unit type is about…)

                                                                                          1. 4

                                                                                            Ah, I understand what you’re saying now. But that’s already true for expressions at the value level in most programming languages, so personally I find it cleaner to use the same grouping mechanism for types (which are also a form of expressions). This is especially applicable in dependently typed languages where terms and types are actually part of the same language and can be freely mixed.

                                                                                            However, I can also appreciate your argument for languages with a clear syntactic distinction between value expressions and type expressions.

                                                                              2. 1

                                                                                D’s use of !() works pretty well. It emphasizes that compile-time parameters aren’t all that crazy different than ordinary runtime parameters.

                                                                                1. 1

                                                                                  I prefer my type arguments to be cleanly separated from value arguments (languages that fuse them excepted).

                                                                                  I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                                  1. 1

                                                                                    I prefer my type arguments to be cleanly separated from value arguments

                                                                                    Well, in D they aren’t type vs value arguments, since you can pass values (and symbol aliases) as compile-time arguments as well. That’s part of why I like it using such similar syntax, since it isn’t as restricted as typical type generics.

                                                                                    I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                                    The one special case is you can exclude the parenthesis for a single-token CT argument list and actually I thought I’d hate it when it was first proposed and I voted against it… but now that it is there and I used it, I actually like it a lot.

                                                                                    Sure does lead to a lot first timer questions on the help forums though… it certainly isn’t like any other language I know of.

                                                                              3. 2

                                                                                Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                                Yeah, I kind of feel the same way. Even with try_from() dealing with number conversions is a pain in Rust.

                                                                                1. 1

                                                                                  You saved me a lot of typing. 100% agree.

                                                                                  1. 1

                                                                                    Thanks! I’d love to know the reason why someone else voted it down as “troll” – not because I’m salty, but because I’m genuinely interested.

                                                                                  2. 1

                                                                                    2 pains I have with Rust right now:

                                                                                    • I would like to be able to connect to a database (Teradata specifically)
                                                                                    • I want to launch a subprocess with other than the default 3 stdio descriptors (e.g. exec $CMD $FD<>$PIPE in sh)
                                                                                    1. 2

                                                                                      I know it’s technically unsafe and that might preclude it from your use, but does CommandExt::pre_exec not fit your bill?

                                                                                      1. 2

                                                                                        That could work. I’m still new to Rust so I haven’t fully explored the stdlib.

                                                                                    2. 1

                                                                                      Ahahaha, this is a great list. I’m curious about a couple things though, since you’ve obviously put a lot of thought into it…

                                                                                      Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                                      The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                      …They are over-used due to the fact that Rust lacks varargs…

                                                                                      What little experience I have with programming language design makes me feel like varargs are a hard problem to deal with in a type-safe language, at least if you want to allow different types for the args (instead of, say, forcing them all to be what Rust would call &dyn Display or something). Do you know of any language which does it Right?

                                                                                      1. 1

                                                                                        The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                        Rust could have disabled the trapping of signaling NaN’s on start up, but I think Rust fell into the same design mistake of C:

                                                                                        Scared of making the use-case of the 0.01% (people who want signaling NaN’s to trap) harder to achieve, they made life worse for the 99.99%.

                                                                                        varargs are a hard problem to deal …

                                                                                        Agreed, it’s safe to say that language designers hate them. :-)

                                                                                        … at least if you want to allow different types for the args

                                                                                        I think this is only partially the reason. You can still have only same-typed varargs at runtime, but allow recovering the individual types of the arguments in macro calls – which is exactly the case for format! and friends.

                                                                                        Do you know of any language which does it Right?

                                                                                        I think in the case of format strings, focusing on varargs is the wrong approach. If you imagine how you want an ideal API to look like, you probably want to interpolate things directly inside the string, never having to go through the indirection of some vararg method.

                                                                                        Instead of having the formatting parameters in one place, and the to-be-interpolated values in a different one, like in …

                                                                                        let carl = "Carl"
                                                                                        let num = 1.234567;
                                                                                        format!("{}'s number is {:.*}, rounded a bit", carl, 2, num)
                                                                                        // -> "Carl's num is 1.23, rounded a bit"
                                                                                        

                                                                                        … wouldn’t it be much nicer to write (this is Scala):

                                                                                        val carl = "Carl"
                                                                                        val num = 1.234567
                                                                                        f"$carl's num is $num%.2f, rounded a bit"
                                                                                        // -> "Carl's num is 1.23, rounded a bit"
                                                                                        
                                                                                        1. 1

                                                                                          Julia has nice string interpolation too. I honestly don’t understand why more programming languages don’t have it. Does everyone just forget how useful it is in bash when they come to design their language?

                                                                                    1. 2

                                                                                      I saw this thread coming from a mile away. ;) This is actually one of my favorite interview questions; IMO if you love a tool enough to actually use it regularly, you should have found pain points in it.

                                                                                      • Rust: Ownership is hard to grok (which is not helped by borrow checker limitations, so things you can easily determine are safe in your head may require significant modification to pass the borrow check). Ecosystem is very unstable. Severe language-level feature creep.
                                                                                      • Kotlin: Nullability is awkward and limited in more complex cases (e.g. there’s no way to have the equivalent of Option<Option<T>>). Ditto for smart casting (e.g. you can never smart cast a var field). It has sum types, technically, in the form of sealed classes, but they’re rarely used. On the JVM, inherits a bunch of JVM weaknesses (e.g. all those non-nullable fields are actually nullable, and are in fact null during initialization). Tooling is surprisingly rough, given that Jetbrains is a major sponsor.
                                                                                      • SQL: Syntax is mega-awkward. Composibility is nonexistent. APIs are surprisingly bad. SQL injection. It scares people enough that we now have to contend with ORMs. (All this is, IMO, a small price to pay for a very widely-supported, well-understood mostly-declarative query language.)
                                                                                      1. 3

                                                                                        SQL: Syntax is mega-awkward. Composibility is nonexistent. APIs are surprisingly bad. SQL injection. It scares people enough that we now have to contend with ORMs. (All this is, IMO, a small price to pay for a very widely-supported, well-understood mostly-declarative query language.)

                                                                                        I would love to see a modern take on SQL that emphasizes composability and reusability without resorting string concatentation/eval. I just find myself writing the same queries over and over again in different contexts and it would be nice if I had an environment that could be built up with tools to remove some of that repetition.

                                                                                        E.g., finding duplicates in a table:

                                                                                        SELECT Name, COUNT(*) FROM Person GROUP BY Name HAVING COUNT(*) > 1

                                                                                        SELECT Email, PhoneNo, COUNT(*) FROM Contacts GROUP BY Email, PhoneNo HAVING COUNT(*) > 1

                                                                                        It feels like 95% of the query is repetitive and I’m just filling in holes.

                                                                                      1. 2

                                                                                        I kind of love this idea. It makes me wonder what other languages could be improved in some capacity (e.g., performance) by removing from them.

                                                                                        1. 2

                                                                                          It’s incredible the amount of work that is put into making JavaScript fast. Makes you wonder what other work could have been done if the scripting language of the internet had been something else. (Both in terms of applications built on browsers and the browsers themselves.)

                                                                                          1. 2

                                                                                            Makes you wonder what other work could have been done if the scripting language of the internet had been something else

                                                                                            I think about this all the time at work; we deal with languages for blockchain execution, and very often the folks who wrote those languages & implementations aren’t well versed in the current technology. Subsequently, you often end up with these ad hoc & slow compilers that generate terrible code; for example, solc for the longest time generated an exponentiation opcode for what should have been a constant, which cost folks real money to execute.

                                                                                            sighs into tea cup

                                                                                          1. 2

                                                                                            I have read 184 books so far this year but gave only three of them 5 stars.

                                                                                            1. 2

                                                                                              How much time do you devote to reading? Is this a normal pace for you? What’s your recall like for books?

                                                                                              1. 2

                                                                                                I read for at least an hour and a half every weekday during my commute and dinner.
                                                                                                I probably spend at least another 3 to 5 hours a week reading.
                                                                                                It’s a normal pace for me.
                                                                                                I have a good recall of most of what I read.

                                                                                                1. 1

                                                                                                  You have very impressive throughput.