1. 24

    I didn’t submit the link but I did write the blog post, so AMA.

    1. 3

      Thank you for stepping in! Your involvement with community, presentations and just general hard work are worthy of envy.

      Three questions:

      In one of the recent talks, where Andrei and Walter was asked what are the ‘3 top thing’, Andrei mentioned full, unambiguous language specification. Where does it stand now, and where do you see it fit on the overeall scale of things.

      Second, the mobile platform. Is there community/sponsorship interest in having D being first-class language for Android, IOS (and may be the librem)

      Third, is in terms industry domain focus, are there specific domains/industries you would like to see more interest/sponsorship from?

      Overall, I am glad to see that memory safety (including compile time) and multi-language interoperability are high on your list/vision. Given D’s maturity, previous investments, current capabilities and market positions – those are right things, to focus on.

      1. 4

        Second, the mobile platform. Is there community/sponsorship interest in having D being first-class language for Android, IOS

        It depends on what exactly you mean by first-class, but there is sponsorship on it. I’ve been working on android last weekend and D with the NDK already works, just it is a little clunky. But the end result will be D works just as well as C++… which isn’t really first class there - only Java and Kotlin have that and tbh I don’t expect that to change given the android VM.

        I also toyed with ios, but am not officially sponsored on that yet. Actually, I think D has better chances there of working just the same as objc and swift.. but xcode doesn’t appear to be expandable so even compiling to the same code with the same access to the runtime might not count as first class.

        1. 2

          Xcode is not very customizable, but at least supports external build commands. It’s relatively easy to generate an Xcode project file with all the tweaks needed to make Build/Run “just work”, even for submission to the Mac AppStore. I’ve done that for Rust/Cargo: https://gitlab.com/kornelski/cargo-xcode

          1. 1

            Indeed, I’ll have to look at that, thanks! What I did for proof of concept on ios was just manually add the D static library. Worked very well in the simulator - the dmd compiler speaks objective-c abi and runtime, so even defining the child class just worked. But it only does x86 codegen… the arm compilers don’t speak obj-c. Yet, I am sure I can port it over in another weekend or two.

          2. 2

            D with the NDK already works, just it is a little clunky.

            Thank you Adam.

            Yes, I should not have used ‘first class’ moniker, as, clearly, for Android platform at least, first class can only be a JVM language.

            In the larger context, what I meant more was ‘easier’ business logic sharing among Android, iOS and backend. This is a challenge that seems to fit well with D’s multi-language interoperability vision. And it is a challenge that yearning to be solved. [1], [2].

            For many small-budget teams, developing Android + iOS (with a common backend), is quite difficult.

            So I was asking more around this angle, of integrating D into IDE/toolchains of the dominant and upcoming mobile platforms, to provide for this multi-mobile-platform+backend code sharing.

            JS/Typescript seems to be the choice, for the common engine run-time for code sharing across mobile (but, in my view, JS has costs in terms of: compile-time error detection, interlanguage data passing, memory and battery utilization, plus it is not a prevalent language for backends). There is also .NET Xamarin (that makes different tradeoffs than common JS approaches)

            [1] https://medium.com/ubique-innovation/sharing-code-between-ios-and-android-using-c-d5f6e361aa98 [2] https://news.ycombinator.com/item?id=20695806

            1. 6

              There’s a number of annoying problems to solve here (like Apple accepting LLVM bitcode instead of native code, which means you have to generate exactly the bitcode that the current Apple toolchain emits, and the the bitcode isn’t stable). Still, native languages are good choice there and having a multitude of native languages would be great.

              1. 2

                generate exactly the bitcode

                whoa, how strict are the checks? (i have never done mobile development before, so I am not a great choice to be doing these projects… just it seemed i was the only one with compiler hacking experience with some free time so it kinda fell on me by default)

                I read the website and go the impression that they basically did end-user acceptance tests… so I thought if it ran the same way you’d prolly be OK… do they actually scan the code for such strict patterns too? I wouldn’t put it above Apple - I hate them - but it seems a bit crazy.

                1. 3

                  They will actually compile the code and ship it to your clients. https://www.infoq.com/articles/ios-9-bitcode/

                  So, when I’m saying “exactly”, I mean it must be legal bitcode for the compiler toolchain you are using. This is a major nuisance, as the LLVM Apple ships with XCode is some internal branch. So, basically the only option is building custom compiler against XCode.

                  For an effort in Rust to do this, check here. https://github.com/getditto/rust-bitcode

                  I’m not well-versed in D, I assume the compiler is not based on LLVM?

                  1. 2

                    D has 3 backends

                    gcc, its own, and LLVM (experimental) [1]

                    I actually think D fits well into this problem domain of ‘sharing business logic (non-UI)’ code across multiple languages and toolchains of the mobile dev world.

                    Because D’s team invested big effort into multi-backend architectures, and into C++ abi compatibility across non-standard ABI of the C++ compilers

                    [1] https://dlang.org/download.html

                    1. 3

                      I wouldn’t call the llvm one experimental, it is in excellent condition and has been for a long time now. But yeah the llvm one is what would surely do the prod builds for ios… I guess it just needs to be built against the xcode version then hopefully it will work.

                      1. 1

                        ok, thank you. I had an old understanding of D’s llvm backend. sorry about that.

                    2. 2

                      FWIW, bitcode submission is optional and doesn’t seem to have compelling benefits. I’m a full-time iOS developer and have disabled bitcode in all of my recent projects.

                      1. 2

                        Yes, but forcing individual decisions of that kind is not a good habit if you want adoption.

            2. 3

              Thanks for the kind words!

              unambiguous language specification. Where does it stand now

              I think we’re inching towards it.

              are there specific domains/industries you would like to see more interest/sponsorship from?

              All of them? :P

            3. 3

              I’m watching Zig’s progress, and it seems like it’s more minimalistic and modern (as in: type declarations, expression-based rather than statement based, quasi sum types with tagged unions) than D while competing in the “crazy compile time magic” department. Do you have an opinion on whether D could learn from Zig as well?

              1. 1

                I don’t have an opinion on that because I know next to nothing about Zig other than they don’t like operator overloading. Which dismisses it as a language I’d like to actually use.

                1. 2

                  that’s how I feel about the lack of proper sum types + pattern matching :)

              2. 2

                I don’t understand the first point. Are we finally gonna have a good answer for all of the “but the GC…” protestors? Or are you just saying that the GC isn’t enough to ensure memory safety?

                1. 4

                  The GC is enough for memory safety for heap allocated memory, but not for the stack.

                  As for “but the GC…” protestors, it’s a hard issue since it involves changing the current psychological frame that believes the GC is magically slow.

                  1. 3

                    Random pre-coffee thoughts on this sort of stuff… In my experience it also involves changing the current psychological frame of GC implementors (and users) that believes speed is the problem. I write video games and robotics stuff, both of which are soft-real-time applications. Making them faster can just be a matter of throwing better algorithms or beefier hardware at them, but even a 10ms pause at some random time for some reason I can’t control is not acceptable.

                    I would love to use a GC’ed language for these tasks but what I need is control. So if I’m learning a new language for it I need a more powerful API for talking to the GC than “do major collection” and “do minor collection” which seems sufficient for most GC writers. (Rust has made me stop much paying attention to GC’ed languages, so more powerful API’s seem to be a bit more common than last time I checked a few years ago though.) I also need documentation on how to write critical code that will not call the GC. Actually, now that I look at D’s GC API it looks a lot better than most for this task; you can globally enable/disable the darn thing, and API docs both describe the algorithm and how it’s triggered. So, writing something like a fast-paced video game in D without erratic framerates due to GC stalls seems like it shouldn’t actually be too hard.

                    So, changing the current psychological frame of the “but the GC…” people might be started by demonstrating how you write effective code that uses the GC only where convenient. That way the people who actually need to solve a problem have an easy roadmap, and the people who complain on philosophical ground look silly when someone with more experience then them says “oh I did what you say is infeasible, it was pretty easy and works well”.

                    I dunno, changing people’s minds is hard.

                    1. 2

                      I would love to use a GC’ed language for these tasks but what I need is control.

                      As you wrote later, there are API calls to control when to collect. And there’s always the option to not allocate on the GC heap at all and to use custom allocators.

                      I dunno, changing people’s minds is hard.

                      Yep. “GC is slow” is so ingrained I don’t know what to do about it. It’s similar to how a lot of people believe that code written in C is magically faster despite that defying logic, history, or benchmarks.

                2. 1

                  One can write the production code in D and have libraries automagically make that code callable from other languages.

                  I think it can be big for Python. Given that Python is used in stats, are there any libraries in D that to stats?

                  1. 4

                    I think the mir libraries cover that to a certain degree.

                    1. 2

                      just as Atila mentioned, here are referneces

                      https://github.com/libmir

                      https://code.dlang.org/search?q=linear

                  1. 9

                    It’s come a long way, especially wrt build system (dune) and packaging (opam), but OCaml is sadly still pretty niche and has a few rough edges…

                    1. 3

                      Do you mind elaborating what the rough edges are?
                      Just the unusual let-in syntax or something more serious?

                      1. 1

                        I wrote a post about trying to get OCaml set up coming from other environments, and the places I stubbed my toe. tl;dr:

                        • Dune’s got a lot of rules around what is allowed of an executable vs. a library, and I had to break my program into libraries with a wrapper executable to get what I needed.
                        • It took me longer than I would have liked to see how dune’s dune files were required in almost every directory and how they composed without explicitly linking them together from the various files.
                        • Opam does 2-3 different jobs, and does them a bit differently than other tools. Pulling dependencies (and nothing else) is still something I’m not sure I’m doing right, since sometimes it’ll behave differently if I have uncommitted changes?
                        • A lot of the libraries I wanted to use (like the command line parser, or the test framework) use pretty advanced macro features that took me some head-scratching to debug when they didn’t work on the first try.

                        I really want to love OCaml and will continue playing with it, but it was a project 😅

                        1. 1

                          Thx. I just use ocamlbuild instead of dune.

                        2. 1
                          • syntax: if, match, try should really really have a terminating end keyword, and they don’t. That makes nesting tricky if you’re not careful.
                          • tooling: opam is complicated to use and, while it has a great constraint solver, it’d be much nicer to have an efficient lockfile based workflow (with one instance of opam per project, basically). It’s doable right now but takes quite a lot of storage and is not as easy as it could.
                      1. 4

                        I have to admit, clicking around and skim reading, Nim looks like the first language in a long time that has actually piqued my interest enough to try to learn it and write something with it. Nothing has done that since I found Ruby in the early 2000s.

                        1. 3

                          I can highly recommend that hunch and make an effort to learn the language deep. That’s what lead me to Rust from Ruby.

                          1. 2

                            take a look at crystal, it’s in a similar niche but is ruby inspired.

                            1. 2

                              Yeah, I wasn’t really sold on Crystal. Not enough delta, I guess?

                          1. 37

                            Although I’m glad this article explicitly distinguishes uses of Go and Rust, I still don’t understand why people keep trying to compare these two languages. They clearly have different approaches to different goals.

                            From the panel Systems Programming Languages in 2014 and Beyond:

                            When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as.
                            —Rob Pike (Go creator)

                            Writing client-side applications. The polar opposite of what Go is designed for. In these applications, you have high latency needs, high security requirements, a lot of requirements that don’t come up on the server side.
                            —Niko Matsakis (Rust dev)

                            1. 26

                              I still don’t understand why people keep trying to compare these two languages.

                              I think this is very simple. For a long time people dreaded writing C++ and were looking for a(n imperative) language that compiles to native binaries. Then there were (some time apart) Go and Rust [1]. Both languages filled the ‘a more modern language that compiles to native code’-niche. People start to compare them, besides being very different languages.

                              Besides that, they have overlapping niches where they excel, such as command-line tools.

                              [1] Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.

                              1. 4

                                I’m looking at Crystal currently, as a possible contender in this field (GC, native, fast, and expressive). Looks very promising.

                                1. 2

                                  Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.

                                  What qualifies as critical mass? The languages you cite are all self-sustaining, even if their ecosystems don’t grow at the same speed.

                                  1. 10

                                    What qualifies as critical mass?

                                    Obviously, there is no fixed definition. But it’s clear that a language must have an library ecosystem of a certain size, IDE support, documentation, availability of programmers, etc. before any random given company will seriously consider it for their next project.

                                    Whether these are well-justified reasons is another question. Whatsapp used Erlang and was a fraction employee-wise from many social network competitors and created a crazy amount of value (for the owners and shareholders).

                                    1. 8

                                      Critical mass such that people need to write blog posts clarifying “why go and not x”?

                                  2. 12

                                    Go is faster than Python.

                                    Rust is safer than C, and, once you get the ownership concept down, safer and easier to understand than C++.

                                    (This post is unapologetically in the style of Paul Graham’s ha-ha-only-serious essay “What Languages Fix” which is still a pretty good read.)

                                    1. 10

                                      Go is faster and easier to build large scale systems in than Python or Ruby.

                                      1. 9

                                        and easier to build large scale systems in

                                        That’s pretty subjective. Can we stick to quantitatively verified facts instead of playing “my X can beat up your X,” please?

                                        1. 9

                                          How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”? If anything, I’d argue that while both are subjective claims, the former is less subjective, just because static typing is widely considered an advantage when it comes to large scale systems.

                                          1. 1

                                            How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”?

                                            It’s not. I should have also replied to the other post, too.

                                          2. 5

                                            To your meta comment, I am aping the “What Languages Fix” style of language property identification, which is necessarily subjective.

                                            To the point itself, I think the notion that a language designed from first principles to support the practice of software engineering in large organizations is better at doing so than dynamically-typed, interpreted, prototyping languages like Python and Ruby is about as noncontroversial as subjective claims can be. And, for the record, reliably borne out by the vast majority of experience reports.

                                            1. 4

                                              And, for the record, reliably borne out by the vast majority of experience reports.

                                              I’ve also seen experience reports suggesting that Ruby and/or Python are the most productive. Unless you can point to a broad study, from an unbiased researcher (spoiler: does not exist), it’s an opinion.

                                              BTW, static vs dynamic typing is the most hilarious “it just is, duh” response ever. That’s the pinnacle of flame war arguments on this topic.

                                      2. 10

                                        A long time ago, Rust was actually much more similar to Go. Then the Rust developers decided that they didn’t need green threads and didn’t need a garbage collector because “a memory-safe programming language with no runtime!!!111*” is way cooler than “yet another Ocaml rehash, with this one weird type system trick!!!111”.

                                        That and they’re both released by web companies, so web developers have inevitably heard of both.

                                        * no additional runtime beyond what C requires, actually

                                        1. 12

                                          They were completely right, a memory-safe programming language with no runtime is in fact way cooler than yet another Ocaml rehash. In the specific sense that such a language genuinely didn’t exist and huge amounts of systems software were written in memory-unsafe C and C++ for lack of a better alternative.

                                      1. 6

                                        Can you explain a bit more about your motivation/goals/vision for building this? It sounds really interesting, but after reading the homepage I got a lot of the what and how, but not a lot of the why.

                                        I think it would also be interesting to compare and contrast with existing terminal mail apps, so people can have a frame for understanding it.

                                        1. 15

                                          I used to use mutt, and after that neomutt. I was following the project when they started some internal redesigns, and I found the process really painful. mutt came out on 1995! It evolved along with modern e-mail workflow. I believe that now that we know the pains of e-mail better we can make it easier for ourselves.

                                          I can only compare other clients to the project’s goals, since as I mention in the post while the foundations are pretty much built, extensibility, scriptability and co. aren’t ready yet.

                                          Some stuff I can come up with now:

                                          • mutt has an archaic configuration system, and also almost no one uses it without tweaking it. Sensible defaults are important.
                                          • mutt is written in C, and good error management along with Rust’s memory safety can be a huge UX upgrade
                                          • mutt does not support plugins at a level comparable to eg (neo)vim.
                                          • mutt doesn’t cater to different e-mail workflows, some people might want to use it like a gmail account, some people want full customisation (power users), some deal with mailing lists and development through e-mail.
                                          • emacs clients require emacs that not everyone uses. That’s the only drawback I can think of without trying them

                                          As far as meli goes, it is not feature rich or even have beta/stable status like the other clients. Personally I feel like I shouldn’t have published it yet, but I have put it off for 2 years and I might never do it if not now.

                                          1. 1

                                            Another problem with mutt (which I love and use daily): it’s entirely synchronous, so if you reload mails on a weak connection or open an attachment the client is unusable until the task is done. A modern client (especially given rust’s safe concurrency abilities) would hopefully do such tasks in a background thread!

                                            1. 2

                                              That’s how it’s done in meli. Threading is still done synchronously because threads span across account folders and I haven’t put an account’s thread structure under a mutex yet.

                                            2. 0

                                              Another mutt user here.

                                              • mutt has an archaic configuration system, and also almost no one uses it without tweaking it. Sensible defaults are important. An archaic plain text file is the best configuration system I can currently think of.
                                              • mutt is written in C, and good error management along with Rust’s memory safety can be a huge UX upgrade -d was good enough for me.
                                              • mutt does not support plugins at a level comparable to eg (neo)vim. There are hooks you can attach your commands to.
                                              • mutt doesn’t cater to different e-mail workflows, some people might want to use it like a gmail account, some people want full customisation (power users), some deal with mailing lists and development through e-mail. In my case mutt works well to hande multiple maildirs and mailing lists.

                                              As far as meli goes, it is not feature rich or even have beta/stable status like the other clients. Personally I feel like I shouldn’t have published it yet, but I have put it off for 2 years and I might never do it if not now. Thanks for doing this!

                                              1. 2

                                                An archaic plain text file is the best configuration system I can currently think of.

                                                Indeed! meli uses a plain text file with keys and values. The archaic epithet was directed to its format; I currently use toml instead of cooking up my own to keep the configuration less alien for some users. toml has support for a few types like tables (hashmaps), arrays, inline tables and doesn’t require extra effort from meli’s side to maintain other than parsing.

                                                There are hooks you can attach your commands to.

                                                I plan on putting hooks too. What I had in mind is an API that lets plugins manipulate the UI, eg an NNTP plugin that creates its own tab for viewing newsgroups.

                                                In my case mutt works well to hande multiple maildirs and mailing lists.

                                                It does, but it doesn’t provide workflows. For example, I plan on integrating mailing lists to accounts, with list archive search, patch handling, auto-archiving of old e-mails. I want to make catching up on high volume lists easier with smart filtering and tagging, if supported.

                                                Thanks for doing this!

                                                Thank you too for your kind comment. It’s only a hobby project but I really want to make it worthy.

                                          1. 1

                                            Language-wise, why would one use Zig over C? From this page, it doesn’t seem like Zig is different from C outside of minor syntactic sugar.

                                            Toolchain-wise, it makes the case for why the zig command is useful, which makes sense to me, since this is an area where C is deficient.

                                            1. 15

                                              Huh? That’s that the whole page is about. C doesn’t have: generic data structures and functions, compile-time reflection and code execution, order independent top-level declarations, non-nullable pointer types, allocator types, etc.

                                              None of those things are “minor syntactic sugar”.

                                              If you don’t understand what those things mean, then it would be better to frame your comment as an honest question. Otherwise, what you are asking is explained very well by the article.

                                              1. -5

                                                Outside of compile-time reflection, I consider those other features minor syntactic sugar. Sugar aside, for what it’s worth, I’ve never felt that the C language was lacking for not providing those features. As an experienced C programmer, pet features aren’t enough of an incentive for me to migrate to Zig, and I don’t think Zig can compete with C on the basis of pet features.

                                                1. 14

                                                  Generics and non-nullable pointers are certainly not minor syntactic sugar, and to me they make Zig potentially more expressive and safer than C. Doesn’t hurt code re-usability either to have generic data structures.

                                                  1. -4

                                                    Would you stop writing C and exclusively use Zig in all previous situations where you would have used C just because it has generics and non-nullable pointers?

                                                    1. 4

                                                      When it reaches 1.0, yes, sure, anything to avoid C’s army of footguns.

                                                      1. 1

                                                        What features in 1.0 are you anticipating?

                                                        1. 3

                                                          the same features it already has, mostly, but with a self hosted compiler and better stdlib and tooling (like editor plugins). I’m not the person to ask. The biggest 1.0 feature is language stability, which is required for adoption.

                                                          1. 1

                                                            What makes you think Zig is not stable enough today? For what have you used it?

                                                  2. 10

                                                    Did you read this section? https://ziglang.org/#Performance-and-Safety-Choose-Two

                                                    Based on the fact that you’re saying “pet features” I think you either didn’t see this, or didn’t grasp the implications of this.

                                                    1. -3

                                                      Putting the reading comprehension abilities of your target audience into question when they aren’t convinced by your arguments is probably not the best way of increasing the user-base of your project.

                                                      As far as detecting integer overflows at runtime goes, clang and gcc have that ability with UBSAN. https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

                                                      1. 3

                                                        Have you ever tried to turn on multiple of the sanitizers at once?

                                                        1. -4

                                                          No, what is your point? I only need UBSAN to replicate the behavior of Zig.

                                                          1. 6

                                                            Incorrect. UBSAN does not catch:

                                                            • invalid union field access
                                                            • unsigned integer overflow

                                                            More capabilities are planned. Clang does not support more than one sanitizer at once; if you want UBSAN and ASAN you’re out of luck. incorrect, see below

                                                            It also does not allow you to selectively disable checks in the bottlenecks of your code. also incorrect

                                                            1. 1

                                                              UBSAN provides -fsanitize=unsigned-integer-overflow, which does catch unsigned integer overflow. I’m not sure what you exactly mean by invalid union field access, but UBSAN also provides -fsanitize=alignment which catches misaligned structure deferencing.

                                                              ASAN only catches memory errors, I don’t think it catches what you are referring to as invalid union field access, so still not sure what your point is about running ASAN and UBSAN simultaneous. As I said before, UBSAN is enough to replicate Zig’s features and much more.

                                                              Clang does not support more than one sanitizer at once; if you want UBSAN and ASAN you’re out of luck.

                                                              This claim is simply false, this works fine:

                                                              clang -fsanitize=address -fsanitize=undefined foo.c
                                                              

                                                              It also does not allow you to selectively disable checks in the bottlenecks of your code.

                                                              That’s also false, see __attribute__((no_sanitize("undefined"))) https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#id10

                                                              1. 4

                                                                I stand corrected. I have corrected the misinformation in my posts, but you have not corrected the misinformation in yours.

                                                                UBSAN provides -fsanitize=unsigned-integer-overflow, which does catch unsigned integer overflow.

                                                                This is inherently flawed since unsigned integer arithmetic in C is defined to be twos complement wraparound. There will be false positives.

                                                                I don’t need to win this argument. I was misinformed on a couple points which make my position less of an open and shut case, fine. There are plenty of other talking points. See you in the thread for 0.5.0 release notes, I look forward to reading your comments then.

                                                                1. 0

                                                                  I stand corrected. I have corrected the misinformation in my posts, but you have not corrected the misinformation in yours.

                                                                  What misinformation have I put forth?

                                                                  This is inherently flawed since unsigned integer arithmetic in C is defined to be twos complement wraparound. There will be false positives.

                                                                  Just because it’s defined doesn’t mean it’s intentional. In 80% of cases (read: pareto majority) unsigned integer overflow is not intended in C.

                                                                  See you in the thread for 0.5.0 release notes, I look forward to reading your comments then.

                                                                  Believe it or not, it’s not my mission in life to trash your language. I believe I gave fair feedback. Many of the people here may pretend to support you, but it doesn’t seem like many of them will actually use the language when asked directly. If you want to eventually appeal to the majority of real C programmers, and not a minority of hobbyist enthusiasts, it would be wise to not take negative feedback defensively.

                                                                  1. 5

                                                                    I believe I gave fair feedback.

                                                                    To me it seems more like, for whatever reason/motivation, that you just came to this thread to do some trolling and to generally be combative with folks.

                                                                    1. 2

                                                                      He just said in his opinion the features are not worth making the switch. That is just an opinion - an honest one at that. I don’t know if I would call it trolling…

                                                                      1. 1

                                                                        Hmm trolling is defined as feigning a position in bad faith. I’m not feigning any position, I genuinely believe the feedback I am providing, and I’m providing this feedback in good faith. That’s actually the opposite of trolling. What statement specifically made it seem to you like I was trolling?

                                                                        1. 4
                                                                          1. -3

                                                                            Ugh an accusation of sealioning requires an assumption of bad faith, which is an act of bad faith itself. You have no rational basis to assume bad faith on my part, and criticism itself isn’t an indication of bad faith.

                                                      2. 6

                                                        I somewhat agree that if you look from a big picture perspective, many of the features are just syntactic sugar. There are not significantly more things you can do with zig that you can’t do with C. I also think that the sum is greater than the parts, and all the ergonomic features will make a large difference in how pleasant it is to write code.

                                                        Things like defer statements and automatic error code types may be enough to push bug counts down for example.

                                                        Generics and a compelling dependency manager probably would be a fundamental shift in how people use the language vs C too.

                                                        1. 4

                                                          Just try to imagine what kind of changes would be required for C compilers to implement this minor syntactic sugar. On top of all the things that were already mentioned, there’s some support for error handling and it seems to have some sort of type-interference.

                                                          It’s perfectly fine you don’t necessarily consider these features important enough to use Zig in favor of C but technically speaking, these differences are quite major.

                                                          From Wikipedia:

                                                          Language processors, including compilers and static analyzers, often expand sugared constructs into more fundamental constructs before processing, a process sometimes called “desugaring”. […] This is, in fact, the usual mathematical practice of building up from primitives.

                                                          Transcompilation from Zig to C would be far beyond a simple expansion (assuming you don’t consider C to be a syntactic sugar for assembly in which case yes, it would).

                                                          1. 3

                                                            C++ competed with C on the basis of having extra features like that. There’s a chance for Zig to as well, esp if maintaining simplicity.

                                                            Far as syntactic sugar, I think anything that increases productivity and maintainability is a net benefit. You might continue writing and rewriting more code in C for nothing to perform the same tasks. At same time, there might be other people who don’t want to work with 1970’s limitations if a language is available without them in 2019. They’ll gladly take a chance to reduce code required, make less breaking changes, and catch more errors at compile time.

                                                            1. -1

                                                              My argument isn’t that language features aren’t good. If you want an advanced language, use Rust or C++. But if you want something simple like C, is using Zig really worth it?

                                                              Be honest here, is Zig’s language feature set compelling enough to you such that you will abandon C, and exclusively use Zig in all places you would have previously used C?

                                                              1. 9

                                                                But if you want something simple like C

                                                                The C standard isn’t simple. A subset of Rust might even be simpler than analyzing all that and the compiler behaviors. We’re talking a complicated language that looks simple vs another language that might be as or less complicated. Could be an advantage.

                                                                “and exclusively use Zig in all places you would have previously used C?”

                                                                You keep saying that but it’s nonsense. I always watch out for people saying a proposal should “always” or “never” be (property here). They’re often setting something up to fail rather than trying to understand real-world pro’s and con’s. The reason is that there’s a large variety of contexts that a solution might apply to… or not. There might be uses for C that a C replacement isn’t as appropriate for. Especially while the replacement is less mature without decades of ecosystem investment. More like there will be “some places” or “most places” to use Zig with others using C. Over time, some people might hit the “all places” point. Not a good starting point for evaluation, though.

                                                                1. -5

                                                                  There might be uses for C that a C replacement isn’t as appropriate for.

                                                                  Interesting logic. The fact that you have avoided answering whether or not Zig replaces C for you, when that is the explicit intended purpose of Zig, shows that your defense of Zig is sort of phony so really not worth acknowledging.

                                                                  1. 6

                                                                    Zig is an alpha language in development. C took some time to get where it is. You’re fine with that but Zig has to, in version 0.4, immediately replace a language with decades of development in all situations. You should ditch C, too, on that basis since people with high-level languages and efficient assembly were saying similar things about it early on. Alternatively, allow Zig a chance to develop and attempt to prove itself incrementally like C did.

                                                                    1. -3

                                                                      You’re arguing against a point I never made. I’m criticizing Zig on the features it’s offering today, not what it may provide tomorrow. Could Zig be a viable replacement for C in the future? Sure, we agree there. Am I saying that development of Zig should halt? No.

                                                                      Now be honest here, is Zig’s current language feature set compelling enough to reasonably consider it a replacement for C today? Doesn’t have to be in all cases, let’s say most cases.

                                                                      1. 5

                                                                        Now be honest here, is Zig’s current language feature set compelling enough to reasonably consider it a replacement for C today?

                                                                        Depends on the use case and compiler quality. I think one should assume answer is no by default until proven otherwise. It’s currently at a stage where hobbyists with an interest might apply it to various problems C is used for. That will produce the field data needed to evaluate what it can do now and how it might be improved.

                                                                        You moved the conversation pretty far, though. You originally accused it of just being syntactic sugar vs C. That’s like saying C is just syntactic sugar for assembly knowing there’d be a lot of work making a compiler for that “syntactic sugar” to work vs doing all the same things as easily in assembly. Zig is doing a mix of syntax, semantics, and analysis to attempt to bring benefits over what C and its compilers do. The compile-time programming alone looks like a huge improvement over C’s preprocessor.

                                                                        1. 1

                                                                          Depends on the use case and compiler quality. I think one should assume answer is no by default until proven otherwise.

                                                                          Thanks for agreeing with me. By default I wouldn’t use Zig over C either. It might be useful if you let the creators know what it would take for you to generally default to using Zig over C.

                                                                          That’s like saying C is just syntactic sugar for assembly

                                                                          Nope, there is a specific definition of syntactic sugar, and C is most definitely not syntactic sugar for assembly. I would consider Zig’s small set of language features syntactic sugar for C.

                                                                          1. 3

                                                                            If it is syntactic sugar, you should be able to throw it together in an afternoon or so integrating it with C. Nothing semantic or deep that poses challenges. Whereas, he’s been working on this full time for a language that already does things C cant without going far from the language.

                                                                            1. -2

                                                                              If it is syntactic sugar, you should be able to throw it together in an afternoon or so integrating it with C.

                                                                              Yes, with the exception of compile-time reflection, I can implement all of Zig’s language features in C using a combination of macros and a small support library.

                                                                              1. 3

                                                                                with the exception of compile-time reflection, I can implement all of Zig’s language features in C using a combination of macros and a small support library

                                                                                I don’t care about Zig one way or the other, but this is a gross misrepresentation. In Zig, quote, “A generic data structure is simply a function that returns a type”. You cannot implement that with a combination of macros. You could implement a set of predefined parameterised types (lists, sets, so on), but that is not the same thing as supporting declaration of generic types directly in the language, particularly with the flexibility that Zig does provide.

                                                      1. 3

                                                        moved to Austin, TX recently, so new routine!

                                                        7:30: wake up

                                                        7:30-8:00: read HN and twitter (yes, what a waste of time -_-)

                                                        8:00-9:00: shower, breakfast, etc.

                                                        9:10: crazy biking to downtown

                                                        9:30: scrum meeting

                                                        9:40-{17:00,19:00}: write code, discuss with boss-slash-officemate

                                                        bike home, eat pasta, think of the futility of life

                                                        Twice a week: 20:15-{22:00,24:00}: dancing!! ^_^

                                                        1. 2

                                                          I don’t really understand the point of re-making one’s own (probably subpar) implementation of an ASP solver. Other package managers (e.g. opam, for OCaml) rely on state of the art solvers, and the author is clearly aware of the existence of such solvers as she correctly references existing literature. I suppose it’s for avoiding external dependencies…

                                                          1. 4

                                                            Chollet’s arguments read like pop sci handwaving while Yudkowsky’s rebuttal is pleasantly rigorous.

                                                            On a related note, I often observe two huge cognitive failures around big issues like climate change or AI.

                                                            One is in assessing possibilities and risks. AI explosion may not be probable but the risk is that it’s possible, and the potential negative consequences are huge, so caution is definitely warranted. Yet many people hasten to deny the possibility altogether by using weak or totally irrational justifications.

                                                            The other is a failure to grasp non-linear effects or insistence on linear behaviour contrary to evidence (eg Chollet seems to be asserting that progress can only ever be linear, without really substantiating).

                                                            1. 6

                                                              climate change is a much bigger threat, because it’s super risky and super likely (certain, even).

                                                              Apart from that, I’m not very convinced by the rebuttal. I still don’t believe in exponential curves in nature (the GDP? recent notion, moving target, not even clear what it measures). Progress in science becomes slower whenever a field matures; good luck making breakthroughs in areas of maths that are 2 centuries old. It should be the same for an hypothetical self-improving AI: it’s smarter, but making something even smarter is also much more difficult, so in the end it’s all about diminishing returns.

                                                              1. 2

                                                                Totally agree about climate change. What I was trying to say is: even if one takes the position that the worst effects of climate change have very low probability (contrary to established science), the consequences are so grave that action has to be taken regardless. But this obvious conclusion is lost on many people for some bizarre reason.

                                                                It’s a similar story with AI. As soon as we establish that there is a possibility of superintelligent self-improving AI, we have to understand that there are huge risks associated with that, and have to proceed with caution rather than burying heads in sand.

                                                                To your points:

                                                                • I think the important thing is not to be convinced by the proponents of intelligence explosion, but rather to recognise that nobody has proof that it’s impossible.
                                                                • We don’t need to find exponential processes in nature, because we’re not talking about a naturally occurring process (and it wouldn’t prove anything one way or another, anyway).
                                                                • Progress in science, I believe, is pretty much impossible to measure, and I’m not sure that it has much relation to self-improving intelligence.

                                                                Somewhat tangential to this discussion: for the purposes of assessing the risk of AI, it’s useful to take a broader perspective and realise that AI, in fact, doesn’t need to exceed human intelligence or be an autonomous agent to cause a lot of problems. In this context, arguments about the possibility of intelligence explosion are a distraction.

                                                                1. 1

                                                                  As soon as we establish that there is a possibility of superintelligent self-improving AI, we have to understand that there are huge risks associated with that, and have to proceed with caution rather than burying heads in sand.

                                                                  That’s like calling for planetary defences against an alien invasion because the discovery of unicellular life on Mars is imminent.

                                                                  We don’t have strong AI. The pattern matching we call “AI” right now is nowhere near that, yet we are supposed to believe that the qualitative jump is imminent. I’ll go with the voice of reason on this one.

                                                                  1. 2

                                                                    This piece on when technological developments are worth worrying about was a nice read on the issue. Not sure I’m convinced, but it’s at least taking seriously the question of whether anyone should care yet.

                                                                    1. 1

                                                                      But how do you determine what the voice of reason is? There are many reasonable people advising caution it seems. Are you sure you’re not going with comforting beliefs rather than reason?

                                                                      1. 1

                                                                        But how do you determine what the voice of reason is?

                                                                        By the amount of changes of past mechanisms needed to fulfil the prophesied future and my own knowledge of medicine and software engineering.

                                                                        1. 1

                                                                          It’s not quite clear to me why expertise in medicine or software engineering is relevant to forming a reasoned position on intelligence explosion. (Let me know?)

                                                                          I guess you might instead be referring to expertise in machine learning, AI, and neuroscience, in which case I’d love to learn your reasoning for why it’s impossible for intelligence explosion to occur (as long as it’s more substantial than reasoning by analogy, historical or otherwise).

                                                                2. 2

                                                                  Got a link to the rebuttal?

                                                                1. 1

                                                                  Ha!

                                                                  ’tis true: C++ can encode calling up monsters from the vasty deep.

                                                                  1. 3

                                                                    And then, destructors are not that virtual, are they?

                                                                    1. 3

                                                                      Why, so can I, or so can any man;

                                                                      But will they come when you do call for them?

                                                                    1. 3

                                                                      Meh. The advantages some programming languages bring to the table are sometimes very significant. They don’t just make the problem “slightly easier”. It’s likely that Go is popular because it makes concurrent networking programs significantly easier to write, compared to most mainstream languages; similarly, using OCaml (or something similar) to write a compiler or symbolic program is a huge improvement over doing it in C.

                                                                      1. 3

                                                                        It’s not about the language per se and more about how many primitives the language integrates, and how well chosen those primitives are.

                                                                        C has no automatic memory management nor concurrency primitives, and Go has both.

                                                                        Among languages that use async/await-style concurrency, their concurrency expressiveness is largely similar.

                                                                        All the “P languages” form a family based on the set of primitives they’re built on, in which they’re very close to each other, and so programs written in them tend to be structured broadly similarly, despite significant differences in some of the design choices of the languages. Sometimes those differences have practical impact too, but rarely from a zoomed-out perspective on the code structure.

                                                                        So the answer to “which language should I learn?” is fairly irrelevant if it’s to be taken as “which P language should I learn?” but is rather more meaningful if it implies “should I use Go, Haskell or Prolog?”. (Although even then it’s just one topic among the many you need an understanding of, as the article says.)

                                                                        1. 1

                                                                          On the other hand, none of these languages have improved the ways people use their databases, write their queries, set their indices, deploy their servers, configure their networks, ….

                                                                          Programming languages bring a lot to the table, but they are not the core of dealing with computers anymore. It’s a huge chunk, but not as central as people make them to be.

                                                                          1. 2

                                                                            Though not Go or OCaml, all the tasks you describe benefit from declarative languages, like SQL and Prolog. (Or Greenspunned versions thereof)

                                                                            1. 2

                                                                              Sure, if you span the net wide enough, you could also call Elasticsearch query syntax (which is bascially the AST of a simple Lucene search program) a programming language. This isn’t practical though and not what people mean by “I’ll learn another programming language”.

                                                                              SQL is a perfect example of that: it is rather worthless to know without at least having a hunch on how your specific database executes it. Plus, each of the product comes with extensions.

                                                                              1. 2

                                                                                it is rather worthless to know without at least having a hunch on how your specific database executes it

                                                                                I feel this is deeply true of any programming language — it is mostly useless divorced from an implementation. I feel that knowing how to program in C is inseparable from knowing compiler extensions and intrinsics. And with the exception of (seemingly increasingly rare) languages defined by standards, one may not have any choice.

                                                                                One difference between logic languages and imperative languages, here, is that most programmers have already deeply internalized a mental model of how imperative languages are executed (which still often fails to match the actual implementation… note the way one still finds people making performance assumptions that held perfectly well on the ZX Spectrum and not in the modern era).

                                                                                Maybe we actually agree on something here: I think something the OP is successfully pointing out is that most people’s definition of “I’ll learn another programming language” is so shallow that it yields little compared to the effort they could put into learning other things. But, for example, I think learning something like Prolog (well enough to write production software: i.e., understanding at least one implementation well enough to reason accurately about performance and so on) is an exercise that yields knowledge transferable to plenty of other areas of programming; I suspect one can make this argument for any language and implementation that differs significantly from what one already knows.

                                                                              2. 2

                                                                                Like SQL and Prolog = Datalog. Seems like a good example where a new language can help with database queries.

                                                                                https://en.wikipedia.org/wiki/Datalog

                                                                          1. 3

                                                                            Writing a SMT solver… in OCaml. Taking this as an opportunity both to see how far I can push performance in OCaml for such CPU-intensive programs, and to get a better understanding of MCSat (an new-ish approach to SMT).

                                                                            1. 1

                                                                              I tried OCaml for a bit but the weirdness got to me after awhile. There was a ton of magic around project setup and compilation that I didn’t understand and couldn’t find properly explained, and the fact there is more than one “standard” library bugged the heck out of me. I’m hoping that once the Linux story solidifies a bit more around .NET I’ll be able to reasonably give F# a shot.

                                                                              1. 3

                                                                                I’ve been using F# on Linux for a few years now using Mono. It’s a bit more manual than .NET Core, but it’s stable.

                                                                                1. 3

                                                                                  If you’re interested in trying again, I created a build system (yes, yet another one) specifically designed for getting going fast in most cases. I have a blog post here:

                                                                                  http://blog.appliedcompscilab.com/2016-Q4/index.html

                                                                                  Short version: all you need is a pds.conf which is in TOML so fairly straight forward, a specific directory structure (src/<project>) and GNU Make. Then you run pds && make -f pds.mk and you’re done. Supports tests as well as debug builds.

                                                                                  1. 5

                                                                                    I’m not sure it is worth pushing yet another build system that seemingly nobody uses (at least I haven’t yet run across a package which uses it) when jbuilder seems to be gaining so much momentum in the OCaml world lately.

                                                                                    1. 3

                                                                                      Maybe, but pds is pretty easy to port away from for most builds and it’s so trivial to get started and much less confusing than jbuilder’s config, IMO. My personal view is that jbuilder is a mistake but I’ll wait to switch over to it once it’s gained enough momentum. At that point, I can just switch pds over to producing jbuilder configs instead. But I’m a symptom of the problem rather than the solution unfortunately. I also use @c-cube’s containers, so yet another stdlib replacement/extension :)

                                                                                      1. 4

                                                                                        My personal view is that jbuilder is a mistake

                                                                                        Could you elaborate on why? IMO jbuilder is not perfect either but if we get a modern, documented build system which is hopefully easy to setup, it would be a massive win over all the other solutions we currently use.

                                                                                  2. 1

                                                                                    I agree, the different choices in tooling is sort of disorienting and it can lead to analysis-paralysis. For a toy compiler project I started working on, I tried to find the most basic tooling that would work: whatever ocaml compiler came with my distro, ocamlbuild, make, and then eventually, extlib, ocpindent, and then after some more time, opam, ocamlfind, utop. It may make sense to use the tooling outlined in this article if future maintainability is a big concern, but to get started and to learn ocaml, I don’t find it necessary (and definitely not appealing). Having done this, I don’t pine so much for standardization (;

                                                                                    1. 1

                                                                                      There’s more than one standard library in a lot of languages, though. Why does that bother you?

                                                                                      1. 4

                                                                                        It bothers me because it makes the language more difficult to learn. It also wasn’t always clear to me that an alternative was in use because, IIRC, they’re not (always) clearly namespaced. I have run into this in Haskell as well, FWIW.

                                                                                        1. 2

                                                                                          Typically it’s visible when you use an alternative stdlib because you start your files with open Batteries or open Core or open Containers. I agree it’s annoying that the stdlib is not richer, and it’s a bit slow to accept contributions, but in a way the existence of alternative stdlibs/extensions shows how easy it is to roll your own :-)

                                                                                        2. 4

                                                                                          You can’t have two standards, that’s a double standard!

                                                                                          1. 1

                                                                                            Which languages?

                                                                                            1. 1

                                                                                              Haskell, C, and D come to mind. You could also argue that Python has multiple standard libraries because it has different implementations that effectively can’t use some aspects of the normal stdlib (PyPy). Then there’s Java: SE, EE, and ME are the same language with different sets of functionality in the standard libraries.

                                                                                          2. 1

                                                                                            Out of curiosity, have you tried OP’s project setup?

                                                                                            Also, there is only one OCaml standard library–the one that comes bundled with OCaml. The other ‘standard libraries’, Batteries Jane Street’s Core, are optional add-ons made for specific purposes.

                                                                                            1. 2

                                                                                              I haven’t tried OP’s setup, but honestly it seems even worse than what I had. I pretty much followed this: https://ocaml.org/learn/tutorials/get_up_and_running.html. I ended up using Oasis, which was just awful, every time I added a file or dependency I had to fiddle with the config until everything would build again, but at least there wasn’t an entirely separate language.

                                                                                              From OP:

                                                                                              (jbuild_version 1)
                                                                                              
                                                                                              (executable
                                                                                                ((name main)                 ; The name of your entry file, minus the .ml
                                                                                                 (public_name OcamlTestProj) ; Whatever you like, as far as I can tell
                                                                                                 (libraries (lib))))         ; Express a dependency on the "lib" module
                                                                                              

                                                                                              Note the comment, “as far as I can tell”. To me, that’s a terrible sign. A person who has gone to a reasonable amount of effort to explain how to set up a project can’t even figure out the tooling completely.

                                                                                              1. 2

                                                                                                Jbuilder is quite nicely documented (see http://jbuilder.readthedocs.io/en/latest/). The public_name defines the name of the produced executable in the install context. It does not take much effort to read it from there

                                                                                                1. 2

                                                                                                  Of course you still have to find out that Jbuilder exists, which the official site doesn’t seem to mention… I am lazy, I don’t like choices, I just want one, blessed tool that works more or less out-of-the-box if you follow a set of relatively simple rules (I’m even OK with wrapping the tool in a simple, handwritten Makefile, which is what I do in Go). I’m not arrogant enough to think that the way I prefer is the “right” way, in fact in some cases it would be dead wrong (like for extremely complex, multi-language software projects), but that explains why I dropped OCaml for hobby stuff.

                                                                                                  1. 1

                                                                                                    OK, but your criticism is that you have to find out that JBuilder exists, commenting on a post that tells you about JBuilder.

                                                                                                    1. 1

                                                                                                      To be fair, jbuilder is very young (not even 1.0 yet actually) but it might become the “standard” build tool the OCaml community has been waiting for for years (decades?). Then clearly there will be more doc and pointers towards it.

                                                                                                      1. 1

                                                                                                        Well obviously I know about it now, but it still isn’t terribly discoverable for someone new to the language. My actual point, and I probably didn’t make this as clear as I should have, sorry, is that in my experience OCaml isn’t very friendly to beginners, in part because its tooling story is kind of weak and fragmented.

                                                                                                        1. 2

                                                                                                          Yeah. This is true. Especially on Windows. People are working on it but it’s slow and it’s taking time to consolidate all the disparate efforts. I myself am not getting terribly excited about OCaml native but funnily enough I am about BuckleScript (OCaml->JS compiler) because of its easy setup (npm i -g bs-platform) and incredible interop story.

                                                                                                          Others are getting equally into ReasonML ( https://reasonml.github.io/ )because it’s coming from a single source (Facebook) is starting to build a compelling tooling/documentation story.

                                                                                                          1. 2

                                                                                                            I didn’t know about either of these, thanks!

                                                                                                  2. 1

                                                                                                    OP here: I didn’t really make any effort to pursue documentation re: the public_name field, and I have really almost no production experience with OCaml whatsoever. I certainly have complaints about OCaml’s tooling, but I can assure you that any argument against it appealing to my authority is certainly flawed.

                                                                                                    1. 1

                                                                                                      I wasn’t really appealing to your authority, in fact kind of the opposite. I don’t like using systems that converge to copy-paste magic, and that seems to be what you did, and is likely what I would do. I don’t want to use a weird programming language to configure my project, I want something simple, with happy defaults, that can be understood easily.

                                                                                                      I guess I generally prefer convention over configuration in this case, and that doesn’t seem to be what the OCaml community values, which is why I gave up on it. I’m not saying anyone is right or wrong, it’s just not a good fit for me, particularly for hobby projects.

                                                                                              1. 2

                                                                                                The reddit thread shows how much people are divided on the issue. I wonder if it’s along the lines of library writer (pro-generics) and app writer (no need for generics)?

                                                                                                1. 2

                                                                                                  Outside of google, for frontend dev, I don’t see any point in using Dart over TypeScript. Pretty likely that even the type system will be better in TS.

                                                                                                  1. 5

                                                                                                    I can totally relate to that. I’ve been writing research-oriented software, very productively, but now I’m trying to help fellow researchers modify and adopt the code and it’s not always easy to realize how much I internalized the code. It’s 2 projects of > 30kloc OCaml and of course it must be a bit maze-like for them.

                                                                                                    1. 5

                                                                                                      It looks like D could be a really good language for most applications, in particular on linux. People seem to either keep C (unsafe, no abstraction) or python (slow and untyped)… At least D can be reasonably high level (like python) but still very performant. I’m just a bit pessimistic on the chances that languages that have been around for a while suddenly become popular.

                                                                                                      1. 6

                                                                                                        I’m just a bit pessimistic on the chances that languages that have been around for a while suddenly become popular.

                                                                                                        ironic for an ocaml person to say that :)

                                                                                                        1. 2

                                                                                                          s/ironic/realistic/ ;-) I love OCaml, but I doubt it will ever become popular. Maybe the reason syntax (which is more C-like, something that can help a lot) will change that though, but I will not hold my breath.

                                                                                                          1. 3

                                                                                                            oh :) i was thinking of the way ocaml has suddenly seen a spike in popularity over the last few years - it will never be C-level popular, but it definitely feels like it has a lot of momentum and community activity it didn’t have for a long time.

                                                                                                            1. 1

                                                                                                              Indeed, some factors made this possible (better tooling with merlin, the opam package manager, …). The community is active, and more people have joined it, but it still is small.

                                                                                                        2. 3

                                                                                                          in particular on linux.

                                                                                                          I would love to see D as a viable alternative for Windows development as well, but since both dmd and ldc have a hard dependency on MSVC, I don’t see this to come soon; it makes crosscompilation from Linux quite difficult up to impossible. GDC might be able to fill this hole, but it still is a one-man show and will only very slowly evolve (not to mention what happens if the maintainer loses interest). Also, I have been told GDC produces giant executables for small programs, but that might improve more quickly.

                                                                                                          For Linux, I think there are enough easily installable, modern alternatives to C/C++ that I don’t think that that’s a place where D could shine.

                                                                                                          1. 1

                                                                                                            I’m just a bit pessimistic on the chances that languages that have been around for a while suddenly become popular.

                                                                                                            If you model language usage as a logistic curve then this scenario is perfectly realiseable.

                                                                                                          1. 9

                                                                                                            Idris looks really well designed, and I think these improvements are actually quite significant. Strictness by default is a game-changer for me; apparently the records and monads are more convenient to use (and there are effects, too? Not sure how experimental they are). If Idris was self-hosted, produced good static binaries with performance comparable to OCaml, and had a package manager I would definitely give it a serious try.

                                                                                                            1. 6

                                                                                                              Idris also has a quite buggy implementation at the moment, but like everything else you mentioned, it is a solvable problem. I think it’s a contender for a widely used industrial language in the future. Though at the moment it’s mainly used by people with pretty sophisticated FP knowledge, I think its dependent types and effect system may ultimately become something that’s easier for newcomers to understand than a lot of Haskell is.

                                                                                                              1. 7

                                                                                                                They are pretty unapologetic about 1.0 not being industry-grade, and it is not quite the goal of the language:

                                                                                                                Will version 1.0 be “Production Ready”?

                                                                                                                Idris remains primarily a research tool, with the goals of exploring the possibilities of software development with dependent types, and particularly aiming to make theorem proving and verification techniques accessible to software developers in general. We’re not an Apple or a Google or [insert large software company here] so we can’t commit to supporting the language in the long term, or make any guarantees about the quality of the implementation. There’s certainly still plenty of things we’d like to do to make it better.

                                                                                                                All that said, if you’re willing to get your hands dirty, or have any resources which you think can help us, please do get in touch!

                                                                                                                They do give guarantees for 1.0:

                                                                                                                Mostly, what we mean by calling a release “1.0” is that there are large parts of the language and libraries that we now consider stable, and we promise not to change them without also changing the version number appropriately. In particular, if you have a program which compiles with Idris 1.0 and its Prelude and Base libraries, you should also expect it to compile with any version 1.x. (Assuming you aren’t relying on the behaviour of a bug, at least :))

                                                                                                                Don’t get me wrong, I believe Idris is a great language precisely because of that: they want to be primarily a research language, but provide a solid base for research happening on top of their core. They have a small team and use those resources well for one aspect of the language usage. I would highly recommend having a look at it and working with it, this is just something to be aware of.

                                                                                                                from https://www.idris-lang.org/towards-version-1-0/

                                                                                                                1. 5

                                                                                                                  Haskell is great because it’s where a lot of these ideas were tested and figured out. But it also has the cruft of legacy mistakes. Haskell can’t get rid of them now, but other languages can certainly learn from them.

                                                                                                              1. 2

                                                                                                                I’m a bit confused about the future of mono, now that .NET Core exists. Are both projects going to continue separately? I heard the .NET runtime was better than mono…

                                                                                                                1. 2

                                                                                                                  Okay, so basically everything is a mess from a naming perspective (which I’ll explain in a second), but the quick version is we still care about Mono.

                                                                                                                  Mono used to be two things: a VM and an implementation of the .NET Standard. .NET Core is also a VM and an implementation of .NET Standard.

                                                                                                                  Recently, Mono has begun ditching their libraries and instead using Microsoft’s directly. This actually began before .NET Core/.NET Standard was a thing, as Microsoft began open-sourcing more and more central .NET libraries, and it’s nowhere near done (Mono still has many of its own libraries that don’t exist for Microsoft VMs/has its own implementations of some libraries), but it seems clear that Mono is skating towards using Microsoft’s assemblies wherever possible.

                                                                                                                  Despite that work, Mono still has its own (very different) VM, and shows no sign of merging with .NET Core’s. This specifically means Mono can do three things that .NET Core cannot (yet): it can do ahead-of-time compilation so no JIT is required; it can target ARM; and, largely as a result of those two facts, it can run on Android and iOS. This means that, at least for now, Mono is still super-relevant due to its VM, if nothing else–and especially since having a concurrent GC is incredibly helpful to making a consumer application feel responsive, and because Mono is heavily used on mobile, I think this improvement will be incredibly welcome.

                                                                                                                  Long-term, I don’t see a huge future for Mono. .NET Core is playing with statically compiled executables (called .NET Native), and while it’s absolutely not ready for real use yet, I expect it to get there eventually. It’s only a matter of time before it works, they add ARM support, and they turn on the ability to target iOS and Android. But I still suspect Mono will be the go-to CLR on mobile for awhile.

                                                                                                                  1. 1

                                                                                                                    This made even more confusing by the fact that the mono team adopted several libraries that were open sourced by MS. The line between MS’s and mono are pretty blurry these days.

                                                                                                                  1. 2

                                                                                                                    somehow I was expecting a Doom-based programming game ^^