1. 2

    Love the “Press F2 to edit the current entry in the editor of your choice”. Tools working together :)

    1. 12

      The light-grey on light-grey is too hard for me to read, I had to stop :/

      1. 3

        I removed the opacity for u element in my web inspector. Note that a value of 0.5 (instead of 0.25) is fairly reasonable.

        I also have problems with this text disappearing sometimes: https://i.imgur.com/RPOQYdX.png – I added that red line myself to indicate missing text. Also note the &em; It seems to happen when I select/hover/click text? It’s pretty intermittent. Using Firefox.

        Arguably, such frequent use of asides is not a great writing style by the way.

        FYI @zge

        edit: I think you’re missing a “not” before “because” in this sentence here?

        But people have not tried to go “beyond” Unix, because they are evil or ignorant, but because the

        1. 1

          I’m sort of conflicted about raising the value to 0.5 (currently it’s at 0.3333, and 0.6666 when hovered over) since the <u> tags are unarticulated side notes, comments or background voices – I kind of abuse it too much, I admit that.

          All I can say about the disappearing text is that it works on my machine, even though I also just use Firefox… Maybe I should try opening it in chromium or some different engine.

          Also thanks for the hypo notice. Most of it was written just before midnight, so I didn’t get around to properly go over it again. I will be reformulating some of the sections, particularly those with many <u> tags, when I have the time, so hopefully I will also be able to make it a bit easier to read too.

          1. 3

            since the tags are unarticulated side notes, comments or background voices – I kind of abuse it too much, I admit that.

            In my personal opinion, side notes should rarely be used. It breaks the flow of the text, and much of the time it’s a “hack” for writing down a proper paragraph that flows well. In other cases, it’s just an aside which isn’t too relevant to the topic at hand, in which case it should probably just be omitted; more words does not equal a better article. I have similar feelings about text in parenthesis by the way, which some people over-use (including myself ☺), especially when it’s used as a hack to clarify a badly written sentence, instead of clarifying the sentence.

            At any rate, in your case because the asides are so often interspersed in regular paragraphs with a different colour, I find it breaks the regular “flow” of the paragraph, and everything comes across as “disjointed”.

            Just my 2¢. Writing is of course very subjective, so reasonable people could disagree.

            All I can say about the disappearing text is that it works on my machine, even though I also just use Firefox… Maybe I should try opening it in chromium or some different engine.

            I mucked about some more, and can reproduce it fairly reliable by selecting text with double/triple click, but only if there is a line break between [ and ] (in which case all text before the line break disappears). I tried looking at the JS, but it’s all minified.

        2. 2

          if you’re reading on Firefox then you can activate reader mode which makes the reading experience quite pleasant. It looks like this. You can activate it by clicking the little document icon that is present on the address bar after you load a page which has a recognizable content/article part

          1. 2

            Oh, I’m sorry about that. I tried increasing the opacity, since I didn’t realize that that was a problem.

          1. 3

            One of the benefits of an open struct is that you can assign to values many layers deep, which I don’t think this proposes to do. But still looks great!

            1. 2

              to be honest I’m mainly using those as read-only structures so I didn’t try the assigns too much but it works fine

              user = SimpleHash[name: "a"]
              user[:name] = { prefix: "a", suffix: "b" }
              user.name.prefix # => "a"
              

              I could have direct setters like name= but I prefer it without the setters for now

            1. 7

              The guy’s actual CSS is a lot more than 58 bytes though :(

              1. 4

                (author here) True. By looking great nearly everywhere, I mean the layout of the elements on most devices/viewports.

                1. 6

                  I was about to post this as a positive thing! It’s still tiny, understandable, and looks great.

                1. 7

                  There are web frameworks in OCaml, Oscigen being the most mature. But there are also other typed functional languages with web frameworks! Servant is a new one in Haskell, but there are others, same goes for F# and Scala.

                  I don’t think that types and functional programming are just missing a good web framework to win the day. Web frameworks are fundamentally building GUIs; they just so happen to be GUIs downloaded on the fly. And GUI programming has historically been the least typeful sort of programming. Why would I need a compiler to tell me that I’m write when I can see right here I am? There’s a lot to be said for confidence in refactoring and ease of checking, but it’s not quite as necessary as it is for systems programming, distributed systems, etc.

                  That said, there is a lot of cool new stuff going on in the Elm / Virtual Dom space — and OCaml’s certainly part of it.

                  1. 6

                    I wouldn’t call Servant a web framework. It’s more for building APIs - you don’t get templating or any other MVC niceties that you’d get with Rails. Instead, you get typed, declarative APIs that in some cases you can then use to generate client code or documentation.

                    1. 4

                      Why would you say GUI are any less “typeful”? How are you seeing that you are right? Maybe on perfectly static pages I could see that it might be easy to visually check the page but most pages are not strict static HTML pages. I’ve been using Giraffe + Fable-Elmish for my F# webdev, this lets me have types in my client and server. Having the same data representation on the client and server allows me to have very simple client side validation, while also potentially having the same validation on my server. I can use the same code for both client and server.

                      1. 3

                        Yeah I don’t think that GUI’s are inherently typeful or not: Just pointing out that historically most GUIs have been written in dynamically typed programming languages: Javascript, Tcl, Ruby on Rails. Even some statically typed frameworks like vala/gobject and objective c have like an “Any” type. My guess is that this tendency is because it’s a lot easier to manually test GUIs, even ones that aren’t static, than it is to manually test distributed systems, kernels, compilers, etc. I’m not saying though that types aren’t useful for writing GUIs too though: having statically checked data across your server and client is awesome — your F# stack sounds great!

                        1. 1

                          I see! you weren’t meaning that they are inherently typeful or non typeful, you were describing the languages that are used for front end. That makes a lot more sense. I think part of it is that for a long time front end dev was seen as needing to be accessible to designers. Types have had a reputation as being “hard” because they tell you when you’ve boned it up, and that sometimes comes across as harsh I think. However really a good type system is like bowling with bumpers.

                      2. 2

                        If servant is like Erlang’s Webmachine or Clojure’s Liberator than there is a pretty decent alternative: webmachine. I’ve used it and the biggest learning curve was the OCaml object system.

                      1. 2

                        The promise of effects that I’m excited about isn’t so much the ability to express commonly built-in language features in terms of effects with continuations, but instead the ability to analyze statically the effects a particular function performs: in other words having effects built into the type system. This isn’t seen in closure but is quite cool.

                          1. 1

                            is it a light theme 😆

                            1. 1

                              Haha well I use it with set backdround=light

                          1. 19

                            I really dislike it when people make posts telling developers they should do something. How about instead “Rust: Several reasons why you might like to learn in it 2019”.


                            Rust’s low overhead is a good fit for embedded programming

                            ≠ you should learn it

                            Rust can build powerful web apps

                            ≠ you should learn it

                            Rust is good for building distributed online services

                            ≠ you should learn it

                            Rust is suited to creating powerful, cross-platform command-line tools

                            ≠ you should learn it

                            Rust now has new developer tools and better IDE support

                            ≠ you should learn it

                            That said, I’ve really enjoyed learning Rust, it’s a great language.

                            P.S. Autoplay on videos WITH sound? So annoying.

                            1. 14

                              I rarely just post to confirm, but I’d like to press that this is also very much the official project stance. It’s condescending, and we don’t think that helps.

                              We sve problems and prefer speaking to people that actually have these problems. Also, there’s alternatives and we believe people should check themselves.

                            1. 5

                              Common Lisp is probably quite unique in the fact that it’s both typically compiled to machine code and yet maintains enough runtime information to be considered “dynamic”. An implementation that is easy to study is valuable.

                              1. 1

                                There are several languages that have static type systems and keep type information around at runtime: go, java, typescript. So I think type erasure is a quality of the implementation, not the language per se. It’s still definitely cool that common lisp goes to machine code! Using the same tactic you could imagine compiling any dynamically typed language down to machine code too, although most things would probably still be quite slow

                                1. 1

                                  I would imagine in many dynamic languages type inference will do a decent job. Especially if as in Common Lisp you can aid by sparsely declaring types here and there. Though I could see how many optimizations in e.g. Ruby could be problematic.

                              1. 5

                                I actually worked at Uber 3 years ago – on those very endpoints! I might have even done the “max 50 results per page” but can’t be certain. Fun to see it used in the wild :)

                                1. 4

                                  I can definitely recommend inventing your own programming language and then solve Advent of Code problems with it.

                                  ❤️

                                  1. 7

                                    Pierce’s Types and Programming Languages has accompanying source code and covers adts

                                    1. 1

                                      Thanks! I have the book. It’s a great book by the way!

                                    1. 22

                                      Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes.

                                      None of those things are simple :/

                                      1. 8

                                        algebraic datatypes are an extremely simple and beautiful thing; they’re just unfamiliar. one of the things i’m excited about pyret potentially doing is making them a standard part of an introduction to programming course.

                                        1. 6

                                          Algebraic datatypes are awesome! Pyret’s also super cool. Yeah I don’t think they’re particularly complicated to explain, but their actual implementation isn’t that simple when it comes to type inference, pattern matching, and recursive datatypes.

                                          1. 2

                                            ah, my mistake, sorry. i didn’t realise you meant in terms of implementation; i thought you were picking on haskellers for calling unfamiliar language features “simple”.

                                      1. 12

                                        I spent an embarrassing amount of time on that, thanks!

                                        1. 26

                                          I love it.

                                          Low-level programming is so often filled with arrogance: Stuff like “I work on hard low level things, only above-average programmers like me can do it”. Don’t believe me? This is literally one of the first pages you read on the Os dev wiki: https://wiki.osdev.org/Required_Knowledge

                                          In fact, writing an OS is usually considered the most difficult programming task. You will need above-average programming skills before even considering a project like this. Failure to comply will make you look silly.

                                          ugh. “Failure to comply will make you look silly” Did a 7 year old write this? We don’t want to be taunting beginners or making them feel stupid, we want to be empowering them.

                                          And that’s the position Rust is taking: Rust helps anyone be a systems programmer. Maybe systems programing isn’t particularly well defined, but many people reading this will think “scary part of programming” and then “oh wait, Rust let’s me do that”. That’s awesome: A clear path forward to doing something scary.

                                          Lastly, I really do like the design. That’s obviously personal preference though, what I really like is that there is design at all. Again low level programming is littered with bad design or lack thereof: having put work into their design is another way of being more inclusive.

                                          1. 12

                                            Low-level programming is so often filled with arrogance: Stuff like “I work on hard low level things, only above-average programmers like me can do it”.

                                            At a previous workplace, there was a cohort of strong systems programmers who would emphasize the difficulty and attainability of systems programming skills. It was out in the open - this is hard, you can do it, with practice, let’s work on it together.

                                            This was accompanied with a culture of regular talks, sharing of projects, ideas, workshops to get all devs interested in systems ideas - building a shell, using flamegraphs, writing data structures, cache locality. Frontend, SRE, sysadmins, everybody was welcome. That was real great stuff, the opposite of the more common “hey, Joe Frontend, get out of here and go bang some legos together.”

                                            Anyway, not sure where I’m going with this - I guess my point is:

                                            “Systems programming is hard - if you’re willing, you can do it. Here’s some resources” is a more welcome attitude vs. “Let’s scare off these morons”.

                                            Who knows, one of those morons might get motivated, do some learning, and become a good systems programmer some day.

                                            1. -9

                                              Writing an operating system is an enormously difficult task. Scaring off people that are not ready to even begin, that so lack the fundamentally required skills that they can’t even follow basic tutorials? That’s a service to the community.

                                              It’s simply not the case that everyone can be a systems programmer. Rust is an extremely complicated language, and if someone can’t do systems programming in C they certainly won’t be able to do it in the much more complex language Rust.

                                              Systems programming is complicated and scary and difficult and it should be. People should be scared to release low level software, because of the massive implications of them getting that software wrong.

                                              Certainly we do not want to be ‘empowering’ people.

                                              1. 22

                                                Writing an operating system is an enormously difficult task.

                                                Writing an operating system is an enormously large task. It’s not obvious the problems posed by OSs are substantially harder than those posed by distributed systems, compilers, machine learning, UI design, game development, sys ops, etc. Certainly there is much worse tooling for os development! (Rust is one foray into making this better!) Part of the reason, I think, the tooling is bad is because there’s this notion that writing an operating system should be hard: it’s a self-fulfilling prophecy.

                                                Scaring off people that are not ready to even begin, that so lack the fundamentally required skills that they can’t even follow basic tutorials? That’s a service to the community.

                                                I am all for giving people basic tutorials! Scaring people, on the other hand, seems like the community is trying to weed out the weak and let only the best programmers in. That’s certainly a possible goal for a community, just not a community I want to be a part of.

                                                Rust is an extremely complicated language, and if someone can’t do systems programming in C they certainly won’t be able to do it in the much more complex language Rust.

                                                I guess we’ll see about that! Rust is making the claim that it’s easier to do systems programming in Rust than it is in C.

                                                Certainly we do not want to be ‘empowering’ people.

                                                I do :)

                                                1. 18

                                                  Multiple universities offer a “write an operating system” class in the CS1XX level.

                                                  1. 4

                                                    I couldn’t disagree more, and one of my favorite things about the rust community is how we reject gatekeeping like this. Portraying it as a binary choice a la “either we deter people or they will write bad systems code” is intellectually dishonest at best. As @sevagh noted, it’s possible to both acknowledge the difficulty of writing good low-level code AND encourage people to learn how to do it. Providing good tools, good documentation, good learning resources, and good mentorship is, in my opinion, the best way to accomplish this, and that’s what I see the rust community pursuing

                                                1. 4

                                                  I hope they change the tag line: “Rust: The programming language that empowers everyone to become a systems programmer.”

                                                  In my experience, “systems programmer” is used to mean “I write programs that are hard, so I can look down on people who do mere ‘scripting’ programming”

                                                  1. 9

                                                    I think Wikipedia sums it well:

                                                    […] application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both […]

                                                    Source: https://en.wikipedia.org/wiki/System_programming

                                                    1. 3

                                                      I’ve just now realized that to me, “systems programming” is basically equivalent to “not having to care about unicode”.

                                                      I really like this.

                                                      1. 1

                                                        So an alternative to find would not have to deal with filenames or directory names that contain Unicode?

                                                        Or if you’re writing a database engine, you don’t have to support Unicode?

                                                        I’m being a tiny bit sarcastic, but it’s also interesting to investigate the boundary between “user” and “systems” programming.

                                                        Edit wording

                                                        1. 1

                                                          It’s certainly a matter of perspective to a large degree (one developer’s platform is another developer’s application), but from where I sit, yes, find, databases and such are definitely more in the “applications” direction.

                                                          The “systems programming” I deal with consists of things like filesystems (please please please don’t shove unicode in there), block storage layers, thread scheduling, memory allocators, etc.

                                                          1. 2

                                                            The “systems programming” I deal with consists of things like filesystems (please please please don’t shove unicode in there)

                                                            Hah, doesn’t one of the new macOS file systems do this? IIRC, they require valid UTF-8 and I think even do normalization. With that said, I am not knowledgeable about file systems, so I don’t actually know at which level of abstraction these rules are implemented.

                                                            Anyway, I love Unicode. A significant fraction of the work I’ve done in Rust land has involved Unicode in one form or another. But my area of interest is text search, so that makes sense. Whether that’s “systems” or not, I dunno. ¯\_(ツ)_/¯

                                                            1. 3

                                                              Hah, doesn’t one of the new macOS file systems do this?

                                                              I haven’t really been paying too much attention to Apple recently, though it certainly seems believable – their filesystems have been case-insensitive since time immemorial, so madness of that sort was already well-established there…

                                                    2. 6

                                                      I thought this was a really great description of both the ambiguity of the term and its origin.

                                                      http://willcrichton.net/notes/systems-programming/

                                                      1. 4

                                                        Thanks for sharing. This article does a good job of exploring why this is such an ill-defined term. In particular I find the early pre-Osterhout definitions to make much more sense than the modern usage. His dichotomy really seems to have set the discourse back significantly.

                                                        1. 1

                                                          Huh, I thought the definitive treatise on the nature of systems programming was this.

                                                        2. 6

                                                          We’re not fully happy with the tag line currently and happily take suggestions. “systems programming” being a fuzzy term is one of the problems. The spirit is definitely what we want, but if someone were to find a better way to phrase it, I’d be very happy.

                                                          1. 6

                                                            My translation of “systems programmer” is “we don’t do GUIs”. ;)

                                                            1. 3

                                                              Yet many GUIs outside of the web context are written in systems programming languages :)

                                                              1. 1

                                                                Sounds like rust alright.

                                                              2. 4

                                                                I like the spirit of the tagline. Systems programming is a real thing, it’s genuinely difficult to do correctly - and Rust is helping make that situation better, so that more people can write less buggy systems code.

                                                                1. 1

                                                                  This is cynical, although sometimes true.

                                                                  1. -6

                                                                    Systems programming is genuinely difficult in a way that, frankly, GUI programming just isn’t.

                                                                    1. 10

                                                                      If you just switch “GUI programming” and “Systems Programming”, this statement checks out, too. Modern GUI programming with backends and networks is a complexity beast. Add translation and such on top and it becomes incredibly hard.

                                                                  1. 8

                                                                    I’ve found this problem annoying each time writing an ast, thanks for writing it down!

                                                                    I’ve started to use three types of asts: the untyped parsetree, the fully typed tree, and then the typed tree that I use for type inference that has extra type information that’s not useful after type inference. (polytypes rather than monotypes). It becomes a larger cost to make an additional IR for each of these: the Two-level type solution works well here.

                                                                    1. 7

                                                                      Hey all! This is what I’ve been working on in my spare time for a while now; happy to answer any questions!

                                                                      1. 2

                                                                        <3 Looks awesome! My three personal main gripes with OCaml were no multithreading support, poor macro support and syntax, and no possibility to write source code in “top to bottom” order. The first seems now to be solvable with lwt IIUC; now I learn that you seem to have solved the second one! <3 So, on a rather tangential note to the original announcement, do you, or someone else, by any chance know of some plugin/ppx that would allow writing OCaml/Reason “main-first”, aka top-to-bottom?

                                                                        On a more on-topic angle: does Relit also work with pure (i.e. non-Reason) OCaml? It’s not fully clear to me, sorry :/

                                                                        Also does it work with the Dependent Types in OCaml (or whatever the variant of the feature is named in OCaml, I don’t recall now)? E.g. if I write a “checked size array” type, can I write a reasonable constructor for it in Relit? Now I’m starting to think that the explicit splicing syntax may still make it somewhat convoluted (?), maybe probably: $myvec.`([[elem1, elem2, elem3]])`?

                                                                        1. 3

                                                                          :D Glad to help! That bottom-to-top problem annoys me to no end. :/ Relit doesn’t work with OCaml at the moment, but I’m hoping to port it at some point in the not-so-near future. There’s nothing Reason-specific other than the changes to the reason parser and the use of the Reason parser in splices.

                                                                          1. 2

                                                                            I even wondered once if it could be possible to do some rewriter, that would reorder statements in OCaml source to get top-to-bottom — maybe even only in the “top scope”; but I don’t know the language well enough to understand if that’s feasible in any way.

                                                                            I’m sometimes tempted to learn Haskell, as it allows top-to-bottom, even though the abundance of custom operators makes it super hard to grok for me. But then I remember that it’s lazy by default, and thus hard to analyze its performance, and the temptation disappears. I do however totally love Elm on this front.

                                                                            edit: Ah, and after being corrected by Leonidas: do you know if Relit would allow writing constructors for GADTs? E.g. could one write something like the %mat and %vec in https://github.com/akabe/slap readme with Relit, and if yes, then how would the eventual `( ... )` expression for it look?

                                                                            1. 2

                                                                              That’s cool! Yeah you probably could do that in a PPX to reorder them but it wouldn’t be quite as nice as Haskell alas, which does a topological sort of everything in the same module.

                                                                              Relit at the moment lets you expand to any type, but there isn’t support at the moment for parametric types. (They can be faked with a functor, but it’d be nice to make a List notation and not have to specify what kind of list when you use it.) I don’t think this is a problem with most GADT’s (the canonical example of an AST and an eval function for example would work just fine) but since Slap seems to use parametric types, the Relit notation would be very clunky to use. (Basically Relit’s best suited to expand to types that can be stated without any parametric types: User.data, Url.t, etc, things like (’a, ‘b) Map.t are harder but again possible with functors.) We’ve put some thought into how to get it to infer the proper parametric expansion types automatically, but that’s not going to be around soon.

                                                                          2. 2

                                                                            OCaml has dependent types? That’d be new to me. OCaml has GADTs, but as far as I know no dependent types.

                                                                            Also: Lwt and Async have existed for a long time, so concurrency hasn’t been a problem in OCaml for a long time now.

                                                                            1. 2

                                                                              Right, I meant GADTs, thanks and sorry for the confusion. I’m not well versed in compsci/plt theory, so they kinda merge/blur together in my simple understanding, as features which kinda enable some vaguely similar stuff. Though I understand dependent types are something more advanced/general than GADTs and allow more, but I’m not good enough in this area to grasp the differences.

                                                                              As to Lwt, I only recently learnt about it, so it’s probably just my lack of awareness.

                                                                              1. 2

                                                                                So, not that I understand this in the least, but apparently OCaml’s first class modules can be used to prove some things and are technically dependent types? https://github.com/lpw25/girards-paradox/blob/master/girard.ml

                                                                                1. 2

                                                                                  Wow, this looks like the densest module code I have ever seen. It is sort of impressive in a way.

                                                                                  Though I think this is roughly as practically useful as the observation that ML modules can be translated to type classes and vice versa.

                                                                                  1. 2

                                                                                    Haha yeah it’s totally ridiculous

                                                                            2. 1

                                                                              I first put it away due to how much it emphasizes Reason, but it looks well-thought-out from my initial look. Do you have examples of it being used in OCaml? Maybe adding these to the README would be nice, for all use OCamlers that don’t know how Reason syntax maps to OCaml.

                                                                              1. 3

                                                                                Yeah it doesn’t support OCaml at the moment, although we’re hoping to eventually. I’ll add that to the readme!

                                                                            1. 3

                                                                              Functional programming isn’t hard… That’s the point right? Oo is hard, and fp really is just different