1. 2

    The first 2 minutes are interesting even if you’re not interested in OCaml at all.

    1. 1

      That’s exactly what I thought, I never had given much thought on the subtle distinction between types and memory layout.

    1. 2

      Arch + sway + kitty + fish

      neovim, firefox-nightly

        1. 5

          Not to be confused with RISC-V: https://en.wikipedia.org/wiki/RISC5

          1. 1

            I’ll admit, I was confused so thanks for clarifying!

          1. -1

            This post could use some upvotes on hackernews: https://news.ycombinator.com/item?id=19936838

            1. 5

              Since it doesn’t work on original 16-bit DOS files, why not keep the same spirit, but redefine it slightly to make it easier to work? So instead of starting at address 100, start at address 1000 maybe, mmap the file directly, don’t have to change the sysctl setting, and run with it. That’d be kinda fun.

              1. 2

                I agree, this is a bit too obfuscated to be practical. I do love the idea of small binaries though. Maybe something like this is more suitable for it: https://github.com/gynvael/asmloader

                See also the discussion on proggit: https://www.reddit.com/r/programming/comments/bpnwa0/linux_loader_for_flat_binary_dos_like_com_files/

              1. 5

                I honestly tried several times to get into it but I don’t know, it just didn’t click yet.

                I find golang much nicer to work with if I need to do what rust promises to be best at.

                I won’t give up on it yet but that’s just my feeling today.

                1. 12

                  I’ll likely take some heat for this but my mental model has been:

                  • Go is the Python of 2019
                  • Rust is the C++ of 2019

                  Go has found its niche in small-to-medium web services and CLI tools where “server-side scripting languages” were the previous favorite. Rust has found its niche in large (or performance-sensitive) interactive applications where using GC is untenable. These aren’t strict boundaries, of course, but that’s my impression of where things have ended up.

                  1. 9

                    I agree with the mental model, although I usually think of Go as the Java for (current year).

                    1. 5

                      The tooling is light years behind though

                      1. 3

                        “go fmt” offers a standard way to format code, which removes noise from diffs and makes code other people have written more readable.

                        “go build” compiles code faster than javac.

                        The editor support is excellent.

                        In which way is the Java tooling better than Go, especially for development or deployment?

                        1. 8

                          How is the debugger these days?

                          When I was doing go a few years ago, the answer was “it doesn’t work”, whereas java had time-travel debugging.

                          1. 1

                            Delve is a pretty great debugger. VSCode, Atom etc all have good debugging support for Go, through the use of Delve. Delve does not have time-travel, but it works.

                            Packaging Java applications for Arch Linux is often a nightmare (with ant downloading dependencies in the build process), while with Go, packaging does not feel like an afterthought (but it does require setting the right environment variables, especially when using the module system that was introduced in Go 1.11).

                            Go has some flaws, for example it’s a horrible language to write something like the equivalent of a 3D Vector class in Java or C++, due to the lack of operator overloading and multiple dispatch.

                            If there are two things I would point out as one of the big advantages of Go, compared to other languages, it’s the tooling (go fmt, godoc, go vet, go build -race (built-in race detector), go test etc.) and the fast compilation times.

                            In my opinion, the tooling of Go is not “light years behind” Java, but ahead (with the exception of time-travel when debugging).

                          2. 2

                            My three favourite features when developing Java:

                            • The refactoring support and IDE experience for plain Java is outstanding. Method extraction (with duplicate detection), code inlining, and rearranging classes (extract classes, move methods, extract/collapse hierarchies) makes it very easy to re-structure code.
                            • Java Flight Recorder is an outstandingly good tool for insight into performance and behaviour, at virtually no overhead.
                            • Being able to change code live, drop frames, and restart the system in the debugger is a life-saver when debugging hard-to-reach issues. that the process being debugged can be essentially anywhere is a wonderful bonus.

                            Sure, it would be nice if there was a single Java style, but pick one and use that, and IDE’s generally reformat well. Also, the compile times can be somewhat long, but for plain Java thay are usually ok.

                            Note that I have never had to work in a Spring/Hibernate/… project with lots of XML-configurations, dependency injections, and annotation processing. The experience then might be very different.

                            1. 1

                              Just the other day I connected the debugger in my IDE to a process running in a datacenter across the ocean and I could step through everything, interactively explore variables etc. etc. There is nothing like it for golang.

                        2. 5

                          “I’ll likely take some heat for this but my mental model has been:”

                          All kinds of people say that. Especially on HN. So, not likely. :)

                          “These aren’t strict boundaries, of course, but that’s my impression of where things have ended up.”

                          Yup. I would like to see more exploration of the middle in Rust. As in, the people who couldn’t get past the borrow checker just try to use reference counting or something. They get other benefits of Rust with performance characteristics of a low-latency GC. They still borrow-checker benefits in other people’s code which borrow checks. They can even study it to learn how it’s organized. Things click gradually over time while they still reap some benefits of the language.

                          This might not only be for new folks. Others know know Rust might occasionally do this for non-performance-sensitive code that’s not borrow-checking for some reason. They just skip it because the performance-critical part is an imported library that does borrow-check. They decide to fight with the borrow-checker later if it’s not worth their time within their constraints. Most people say they get used to avoiding problems, though, so I don’t know if this scenario can play out in regular use of the language.

                          1. 6

                            I agree, for 99% of people, the level of strictness in Rust is the wrong default. We need an ownership system where you can get by with a lot less errors for non-performance sensitive code.

                            The approach I am pursuing in my current language is to essentially default to “compile time reference counting”, i.e. it does implement a borrow checker, but where Rust would error out, it inserts a refcount increase. This is able to check pretty much all code which previously used runtime reference counting (but with 10x or so less runtime overhead), so it doesn’t need any lifetime annotations to work.

                            Then, you can optionally annotate types or variables as “unique”, which will then selectively get you something more like Rust, with errors you have to work around. Doing this ensures that a) you don’t need space for a refcount in those objects, and b) you will not get unwanted refcount increase ops in your hot loop.

                            1. 2

                              Ha ha, just by reading this comment I was thinking ‘this guy sounds a bit like Wouter van Oortmerssen’, funny that it turns out to be true :-) Welcome to lobste.rs!

                              Interesting comment, I assume you are exploring this idea in the Lobster programming language? I would love to hear more about it.

                              1. 2

                                Wow, I’m that predictable eh? :P

                                Yup this is in Lobster (how appropriate on this site :)

                                I am actually implementing this as we speak. Finished the analysis phase, now working on the runtime part. The core algorithm is pretty simple, the hard part is getting all the details right (each language feature, and each builtin function, has to correctly declare to its children and its parent wether it is borrowing or owning the values involved, and then keep those promises at runtime). But I’m getting there, should have something to show for in not too long. I should definite do a write-up on the algorithm when I finish.

                                If it all works, the value should be that you can get most of the benefit of Rust while programmers mostly don’t need to understand the details.

                                Meanwhile, happy to answer any more specific questions :)

                          2. 4

                            I don’t understand, and have never understood, the comparisons between Go and Python. Ditto for former Pythonistas who are now Gophers. There is no equivalent of itertools in Go, and there can’t be due to the lack of generics. Are all these ex-Python programmers writing for loops for everything? If so, why???

                            1. 1

                              Not Go but Julia is more likely the Python of 2019.

                          1. 3

                            I never understood why Prolog needs to be its own language, if it worked similar to something like sqlite instead I think it would have been used a lot more (i.e. a datastore that you can query with prolog syntax and a prelude for customized setup).

                            1. 1

                              Logic programming can be a separate language and it also can be a library - here is an example temperance in Common Lisp and core.logic in Clojure (I’m sure there are examples in other languages).

                              1. 1

                                I don’t see how multiple language dependent (and mutually incompatible?) libraries helps Prolog adoption?

                                1. 1

                                  Me too, but it looks like miniKanren is already implemented everywhere so I doubt there is real need for one common external implementation.

                                  1. 1

                                    Thanks! I’ll have a look.

                              2. 1

                                Hence the success of Datalog and Datomic. :)

                              1. 1

                                Funny, I wrote about how I crafted one for this year in my blog (which is not common, I don’t usually plan it). tl;dr:

                                • The Pragmatic Programmer.
                                • Clean Code.
                                • Domain-Driven Design.
                                • Growing Object-Oriented Software, Guided by Tests.
                                • Functional Programming: Practice and Theory.
                                • Continuous Delivery.
                                • An Introduction to Statistical Learning.
                                1. 2

                                  I never managed to make much of a dent in Evans’s DDD book. I don’t remember why exactly. I later ran across Patterns, Principles, and Practices of Domain-Driven Design which managed to keep my attention a little longer.

                                  1. 1

                                    I would recommend: https://pragprog.com/book/swdddf/domain-modeling-made-functional

                                    It made the whole DDD concept click for me, especially the implementation details.

                                1. 5

                                  I think there is a lot of room still between TUIs & GUIs. TUIs shouldn’t have to be restricted to characters only IMO (although that would admittedly imply losing compatibility with terminals), also TUIs shouldn’t need to mimick GUIs, going as far as rendering drop down menus, window borders etc. Ideally there should be a generic canvas app that renders UIs for professional/experienced users that are not restricted to character display, and be mostly key driven (i.e. such apps would require some time investement upfront to gain more productivity benefits later [although context sensitive help for possible key combinations would be ideal]). These apps should should be composable and easy to customize/extend (think of an ‘edit source’ option instead of merely ‘view source’).

                                  1. 11

                                    One example of such UIs is GUI version of Emacs. It’s mostly text-based, but without downsides of terminals and with ability to draw pictures and set multiple fonts.

                                    Each time I tried keyboard-oriented UIs, but made of native widgets (for example Total Commander, IDEs), I had lots of problems and had to use mouse anyway. Focus changed wildly, there was bad indication where focus is, there were hundreds of tab stops.

                                    I think it would be cool to have GUI toolkit like Electron, but with terminal-like drawing (but with multiple fonts and images) instead of web browser.

                                    1. 1

                                      Exactly, a very lightweight and fast Electron like toolkit that is optimized for UIs for professionals that isn’t restricted to text-only. It could be cell-based for example (more like a spreadsheet instead of arbitrary x, y positions) but still allow for bitmap images and 3D renderings within a cell range. And it wouldn’t need a ‘toolkit’ with buttons, dropdowns, navbars and the like, because everything is keyboard-driven (with context sensitive help for keybindings in a specific UI state).

                                      Good point about (GUI) Emacs though.

                                      1. 10

                                        Exactly, a very lightweight and fast Electron like toolkit that is optimized for UIs for professionals that isn’t restricted to text-only


                                    2. 2

                                      One of the older ones were NLP-like schemes that let you just say what you wanted to do in a restricted subset of English. They were often used in databases but sometimes outside. So, you didn’t need menus, hierarchies, etc. Just a keypress to activate a text field followed by the command.

                                      Just throwing it in there as an example of an alternative. Such NLP schemes aren’t always appropriate.

                                      1. 1

                                        Interesting, do you have examples of or links to such alternatives? I am curious to learn more about it.

                                        1. 1

                                          They’re not in my bookmarks. I studied them a long time ago as part of AI research. A quick Google gives this project as an example of the kind of steps involved. Obviously, you wouldn’t use Java for the terminal version. :)

                                    1. 4

                                      I am in week 3 of the OCaml MOOC: https://bit.ly/2y2V989 Very interesting course, I currently find OCaml interesting because it influenced F# & Rust. I tried F# but find the CLR slow and the language tools are not a good fit when you are in a Unix-like system and and prefer a plain editor rather than IDEs. I still find Rust very interesting, but less so for business type software. Also with OCaml you can easily apply the patterns described in https://pragprog.com/book/swdddf/domain-modeling-made-functional

                                      1. 1

                                        Hello @eterps -

                                        very intersting statement: * “I still find Rust very interesting, but less so for business type software.”* I am curious why this is the case? Is it the state of the library ecosystem, or the fact that it is too much overkill to use Rust’s version of memory management for business software?

                                        1. 2

                                          The second one, for most business type software I doubt that memory management is the foremost concern. I do like Rust’s library ecosystem, its package management and its modern tooling in general. Rust’s type system is also flexible enough to describe business problems in a similar way as: https://fsharpforfunandprofit.com/posts/no-uml-diagrams/ , if there was something like Rust with garbage collection I would be very interested. For low-level programming Rust is perfect as it is. Maybe something like http://gluon-lang.org can fulfill that role in the future, however currently its type marshalling is a productivity killer.

                                          1. 1

                                            Thank you for clarifying your comment. Pity that these is not equivalent to garbage collected Rust that has all the bells and whistles you would like to have, and not the baggage of the JVM/Mono juggernaut.

                                      1. 3

                                        Still a cool language because of its simplicity and compilation speed (it influenced Go but is much simpler), its syntax is heavily dated though. I sometimes rewrite a code fragment from another language in Oberon (using OBNC) for educational purposes, if I am able to express it in Oberon and get the compiler to accept it, I feel that I truly understand it.

                                        1. 3

                                          I always thought a good project for students was to make an Oberon with C-like syntax. Keep safety in by default with “unsafe” keyword to turn it off in modules or blocks. Compile to assembly for full experience, to LLVM to learn that, or to vanilla C for use of many compilers. Also, give it macros. Every system language needs macros since they can solve so many problems. Gotta use them sparingly and carefully for code readability but some times they’re best solution.

                                          1. 2

                                            Also, give it macros. Every system language needs macros since they can solve so many problems. Gotta use them sparingly and carefully for code readability but some times they’re best solution.

                                            Definitely a good exercise for learning to code and navigate the code of a real world compiler.

                                            But, while I use C macro whenever a call seems as an unjustified waste of resources and I am not a macro detractor at all, I think that the whole point of Wirth’s work with Oberon design would be completely lost in the translation to a language with macros.

                                            Lisps apart, macros (and metaprogramming in general) are a form of code generation that could be moved outside the language. Apparently they are embedded in the language for convenience, to reduce the complexity of the build process, but this let a whole branch of code generation techniques unexplored.

                                            1. 2

                                              “Apparently they are embedded in the language for convenience, to reduce the complexity of the build process, but this let a whole branch of code generation techniques unexplored”

                                              People explored all kinds of methods. DSL’s for many languages were external. LISP’s were among few to internalize them. They maintained an advantage of consistency over the rest.

                                              1. 1

                                                Well I was not thinking about DSLs that serve specific purposes.

                                                By metaprogramming I was referring to those tools, such as macros, C++/Haskell templates, C# generics and so on, that basically generate code that is later compiled (either on binary generation or by a JIT compiler in the VM).

                                                Such preprocessing is usually integrated in the compiler suite (even in Lisp, where expansion occurs on read, if I remember correctly), and consequently integrated in the language.

                                                I’ve never seen people writing code in X to generate code in X.
                                                My insight is that this would be the Oberon approach to metaprogramming… but I have no proof this is what Wirth intended.

                                                Also this might be a selection bias or plain ignorance on my part.

                                                Do you have any example to share?

                                                1. 3

                                                  I had some stashed links on metaprogramming and reflection in Oberon. I think I just skimmed them cuz I don’t recall the specifics. Maybe posted them somewhere. Anyway, I had saved Metaprogramming in Oberon from 1994 and had a bookmark on Reflection in Oberon a few years later. Maybe you’ll find them interesting.

                                                  1. 1

                                                    Maybe you’ll find them interesting.

                                                    As always… ;-)

                                          2. 2

                                            its syntax is heavily dated though.

                                            At a first glance, uppercase keywords gave me the same impression.

                                            But actually they serve the same purpose of syntax highlighting without… syntax highlighting.

                                            Is there anything else that make it seem dated to you?

                                            Or, in other terms, what do you mean by “heavily dated syntax”?

                                            1. 3

                                              With “heavily dated syntax” I mean that the syntax is reminiscent of the Pascal/ADA/Eiffel era, nothing wrong with that but most developers will probably think it’s ugly, archaic and verbose. Adopting a syntax looking more like Nim will be more forgiving to developers who are new to Oberon IMO.

                                              1. 3

                                                In addition Oberon could be a lot more expressive with just adding a pipeline operator (as sugar for nested procedure calls):

                                                cart := emptyCart |> AddItem(42) |> MakePayment(73.95)

                                                1. 1

                                                  My first impression as well, but then, Wirth consistently designs for easy-to-parse grammars, and I would argue that this is definitely a benefit, both for compiler builders and for programmers.

                                                  also it is nice to see some cleanups of the pascal syntax, much less writing of begin, i.e. optimizing for block usage in loops and if-statements, etc.

                                                  I am still undecided on all-caps keywords. First impression is MEH and the impression that it looks very old-school. Second look: I can get used to that. Third look: not quite sure whether it is worth it, but it definitely helps without syntax highlighting.

                                                  1. 1

                                                    …Wirth consistently designs for easy-to-parse grammars, and I would argue that this is definitely a benefit,…

                                                    Just replacing symbols in the scanner with ones that are easier to type and more familiar to read by most developers doesn’t make it any less easier to parse.

                                                    I do agree that all-caps keywords definitely help without syntax highlighting.

                                            1. 3

                                              This was quite and interesting reading!

                                              It would be interesting to see also an example that deals with more complex ocaml structures, like records containing strings, bytes, and (why not) arrays or lists. Or maybe a GADT. Although I think it would just make the plumbing More complex but be not much more than what you do writing the usual C bindings

                                              1. 5

                                                I would love to see a language like OCaml (or another ML like dialect) to be able to make use of Rust’s emerging ecosystem, but I’m afraid we’re still a long way from seeing that happen. Also check out Gluon http://gluon-lang.org/ for an ML like language embedded in Rust (personally I’d prefer a standalone language that works with Rust though).

                                                1. 2

                                                  I’m a little confused. Outside of being developed in Rust what makes gluon “embedded in Rust” vs a “standalone language”? It appears that while gluon is heavily influenced by Rust it can, and does, function as a standalone language as well if you wanted it to. Which, as they point out, is similar to lua.

                                                  I feel like embedded in the context of gluon only applies to their goal of being easy to embed as opposed to being embedded itself.

                                                  1. 2

                                                    I agree that it ‘can’ function as a standalone language as well. But I am not sure if I agree it currently does, AFAIK you can’t create a gluon ‘script’ that runs with #!/usr/bin/env gluon and neither can you compile a gluon source to a binary without embedding it first in a Rust application. I am also unsure whether you can write a gluon module using rust and then import it from your ‘standalone’ gluon program.

                                                    So I disagree that embedded in the context of gluon only applies to their goal of being easy to embed as opposed to being embedded itself.

                                                    But I do realize my criticism might be easily solved (although I have some doubts about the ‘write a gluon module using rust and then import it from your standalone gluon program’ part).

                                                    Please correct me where I am wrong, I’m fairly new to both Rust and Gluon.

                                                    1. 1

                                                      I’m fairly new to both Rust and Gluon.

                                                      Ditto. Thanks for clarification.

                                              1. 1

                                                Can someone with cognitive science back me up on my gut feeling? Everyone has a hard time learning new skills and everyone uses search engines occasionally, but going to these lengths to cheat actually impair learning.

                                                Unless you count learning how to use the cheat sheet as a valuable skill.

                                                1. 7

                                                  I never thought of cheatsheets as literally cheating, more like terse examples of tried and true patterns (in other words not cheating but preventing inventing the wheel over and over again).

                                                  1. 3

                                                    Absolutely right! And I was feeling guilty while creating cheat.sh. That is why we have developed some countermeasures. If we manage to implement this, cheat.sh will have the most important feature of any real cheat sheet: it will help not really to cheat, but to learn too.

                                                    Thank you for this your comment. That is actually the comment that made me register here. This is a very very deep and important thought. Thank you

                                                    1. 2

                                                      There is difference between learning skills and memorizing small details (which are irrelevant in bigger picture). Cheatsheets help with latter.

                                                      1. 2

                                                        The stuff usually found on cheat sheets is “How do I reverse a list in Python?” and not some insanely advanced skill.

                                                        Usually the answer is something inefficient and misleading, when it should be “Mu! You do not.” - and even then it’s not a hard thing to learn.

                                                        Learning how to deal with your language’s and framework’s etc reference manuals, now that’s a worthwhile skill. A gift that keeps on giving.

                                                        1. 1

                                                          But it could potentially also grow the cargo-cult culture of programming: those who don’t understand the language and don’t care, but copy and paste snippets together and bash on it until they reach some definition of success. The snippets are helpful reminders for those familiar with the deep details, but could be uninformative and relatively context-free crutches that only hobble newer programmers from understanding why that particular snippet needed to be different to be the right answer to their actual problem, in the context of the code they’re actually working on.

                                                          1. 2

                                                            The snippets are helpful reminders for those familiar with the deep details


                                                            Sometimes I use snippets for complex operations that I don’t really care about.

                                                            I think this is a great example. https://stackoverflow.com/questions/39799999/parsing-a-soap-message-using-xpath-in-java

                                                            Let it suffice to say that I need that for some reason, and it’s not performance critical, and I fully understand that I’m going to get really deep call stacks and great gooey gobs of complex objects in memory during runtime. I can picture some approximation of it in my mind. (I use rectangular prisms, nested like Russian dolls, in primary colors, megabytes upon megabytes of them, and the tiny little strings that are actually useful data are glowing, everything else is dusty-translucent.)

                                                            I’m also going to literally println a CSV file on the other end, throw it in a Scheduled Task (no, I didn’t say cronjob), and move on to a more important project.

                                                            Using the snippet is the right choice for this part of this project. All I need are those little (glowing) strings.

                                                        1. 3

                                                          Certainly does! Started playing with relm (https://github.com/antoyo/relm) for small experiments, but this seems more suited to Processing like stuff while providing a nice structured UI API. Thanks for sharing!

                                                          1. 1

                                                            Hey Jurriaan! Thanks for the link, I’ll certainly have a look at Relm.

                                                        1. 9

                                                          I use the compiler explorer quite regularly and it is really a brilliant tool. Although for deeper diving I use cargo-asm (or just profile and look at the assembly) for short explorations to answer the question ‘what would rustc/gcc/clang/… compile this to?’, the compiler explorer is really awesome.

                                                          1. 2

                                                            Thanks! cargo-asm looks really useful.