1. 2

    now implement it on a rotary phone

    1. 1

      Anything involving updates are good candidates for a Rust port. I know they’re doing incremental rewrites. Maybe suggest that to a decision-maker. Might prevent exploits.

      1. 6

        It’s tricky. Updates are one of the most sensitive feature in Firefox, because if we break that, we can no longer unbreak our users. Of the conservatives parts of the browsers, this is one of the most conservative, which says a lot.

        I think we will ultimately rewrite the updater in Rust, but for now the crypto is strong enough to protect the update mechanism, so there’s little incentive to rush a rewrite.

        1. 4

          That all makes sense. For anyone curious, here’s my scheme for doing such a transformation:

          1. Move it from C to unsafe, C-like Rust.

          2. Use automated, test generation and fuzzing on both comparing output. This is called equivalence testing. It can also find errors as nice, side effect.

          3. Modify a module to use safety features and/or be more idiomatic. Back to No 2 for equivalence check.

          4. Repeat No 3 until app is converted with no equivalence tests failing.

          There’s tools in development to generate C-like Rust from legacy C automatically. As they mature, they might be used for No 1. In some languages, one can also do formal, equivalence checks for No 2 or extra verification. They prove equivalence on all inputs using mathematical methods. Popular in hardware development.

      1. 22

        After writing Go for 5 years, I’d recommend Rust for C developers. It’s more complicated than Go for sure, but also has more to offer. The lack of garbage collection and support of generics are definitely a plus compared to Go.

        Go is a better language for junior devs, but I wouldn’t call C programmers junior. They should be able to digest Rust’s complexity.

        1. 9

          They should be able to digest Rust’s complexity.

          Non trivial amount of C programmers are still doing C to avoid additional complexity. Not everyone wants a kitchen & sink programming language.

          1. 6

            Rust can definitely get overly complex if the developers show no constraint (i.e. type golf), but the control afforded by manual memory management makes up for it, IMHO. Unless it’s a one-run project, performance will eventually matter, and fixing bad allocation practices after the fact is a lot harder than doing it right from the beginning.

            1. 1

              Couldn’t they just start with a C-like subset of Rust adding from there to their arsenal what extra features they like? It’s what I was going to recommend to those trying it for safety-critical use since they likely know C.

              1. 9

                I think it’s rather difficult to write rust in a C like manner. This contrasts with go, where you can basically write C code and move the type declarations around and end up with somewhat unidiomatic but working go.

                1. 3

                  I think C++ as a better C works because you still have libc besides the STL, etc. The Rust standard library uses generics, traits, etc. quite heavily and type parameters and lifetime parameters tend to percolate to downstream users.

                  Though I think a lot of value in Rust is in concepts that may initially add some complexity, such the borrow checker rules.

                  1. 3

                    The problem with C++ is its complexity at the language level. I have little hope of teams of people porting various tools for static analysis, verification, and refactoring to it that C and Java already have. Certifying compilers either. C itself is a rough language but smaller. The massive bandwagon behind it caused lots of tooling to be built, esp FOSS. So, I now push for low-level stuff either safer C or something that ties into C’s ecosystem.

                  2. 4

                    You could argue the same for C++ (start with C and add extra features). Complexity comes with the whole ecosystem from platform support (OS, arch), compiler complexity (and hence subtle difference in feature implementations) to the language itself (C++ templates, rust macros). It’s challenging to limit oneself to a very specific subset on a single person project, it’s exponentially harder for larger teams to agree on a subset and adhere to it. I guess I just want a safer C not a new C++ replacement which seems to be the target for newer languages (like D & Rust).

                    1. 4

                      It’s challenging to limit oneself to a very specific subset on a single person project, it’s exponentially harder for larger teams to agree on a subset and adhere to it.

                      I see your overall point. It could be tricky. It would probably stay niche. I will note that, in the C and Java worlds, there’s tools that check source code for compliance with coding standards. That could work for a Rust subset as well.

                      “I guess I just want a safer C not a new C++ replacement which seems to be the target for newer languages (like D & Rust).”

                      I can’t remember if I asked you what you thought about Cyclone. So, I’m curious about that plus what you or other C programmers would change about such a proposal.

                      I was thinking something like it with Rust’s affine types and/or reference counting when borrow-checking sucks too much with performance acceptable. Also, unsafe stuff if necessary with the module prefixed with that like Wirth would do. Some kind of module system or linking types to avoid linker errors, too. Seemless use of existing C libraries. Then, an interpreter or REPL for the productivity boost. Extracts to C to use its optimizing and certifying compilers. I’m unsure of what I’d default with on error handling and concurrency. First round at error handling might be error codes since I saw a design for statically checking their correct usage.

                      1. 3

                        I can’t remember if I asked you what you thought about Cyclone. So, I’m curious about that plus what you or other C programmers would change about such a proposal.

                        I looked at it in the past and it felt like a language built on top of C similar to what a checker tool with annotations would do. It felt geared too much towards research versus use and the site itself states:

                        Cyclone is no longer supported; the core research project has finished and the developers have moved on to other things. (Several of Cyclone’s ideas have made their way into Rust.) Cyclone’s code can be made to work with some effort, but it will not build out of the box on modern (64 bit) platforms).

                        However if I had to change Cyclone I would at least drop exceptions from it.

                        I am keeping an eye on zig and that’s closest to how I imagine a potentially successful C replacement - assuming it takes up enough community drive and gets some people developing interesting software with it.

                        That’s something Go had nailed down really well. The whole standard library (especially their crypto and http libs) being implemented from scratch in Go instead of being bindings were a strong value signal.

                        1. 2

                          re dropping exceptions. Dropping exceptions makes sense. Is there another way of error handling that’s safer or better than C’s that you think might be adoptable in a new, C-like language?

                          re Zig. It’s an interesting language. I’m watching it at a distance for ideas.

                          re standard library of X in X. Yeah, I agree. I’ve been noticing that pattern with Myrddin, too. They’ve been doing a lot within the language despite how new it is.

                          1. 4

                            Dropping exceptions makes sense. Is there another way of error handling that’s safer or better than C’s that you think might be adoptable in a new, C-like language?

                            Yes, I think Zig actually does that pretty well: https://andrewkelley.me/post/intro-to-zig.html#error-type

                            edit: snippet from the zig homepage:

                            A fresh take on error handling that resembles what well-written C error handling looks like, minus the boilerplate and verbosity.

                            1. 2

                              Thanks for the link and tips!

                2. 7

                  Short build/edit/run cycles are appreciated by junior and senior developers alike. Go currently has superior compilation times.

                  1. 10

                    Junior and senior developers also enjoy language features such as map, reduce, filter, and generics. Not to mention deterministic memory allocation, soft realtime, forced error checking, zero-cost abstractions, and (of course) memory safety.

                    1. 3

                      Junior and senior developers also enjoy language features such as map, reduce, filter, and generics.

                      Those are great!

                      deterministic memory allocation, soft realtime, forced error checking, zero-cost abstractions, and (of course) memory safety.

                      Where are you finding juniors who care about this stuff? (no, really - I would like to know what kind of education got them there).

                      1. 8

                        I cared about those things, as a junior. I am not sure why juniors wouldn’t care, although I suppose it depends on what kind of software they’re interested in writing. It’s hard to get away with not caring, for a lot of things. Regarding education, I am self-taught, FWIW.

                      2. 1

                        Map, reduce and filter are easily implemented in Go. Managing memory manually, while keeping the GC running, is fully possible. Turning off the GC is also possible. Soft realtime is achievable, depending on your definition of soft realtime.

                        1. 1

                          Map, reduce and filter are easily implemented in Go

                          How? Type safe versions of these, that is, without interface{} and hacky codegen solutions?

                          1. 1

                            Here are typesafe examples for Map, Filter etc: https://gobyexample.com/collection-functions

                            Implementing one Map function per type is often good enough. There is some duplication of code, but the required functionality is present. There are many theoretical needs that don’t always show up in practice.

                            Also, using go generate (which comes with the compiler), generic versions are achievable too. For example like this: https://github.com/kulshekhar/fungen

                            1. 9

                              When people say “type safe map/filter/reduce/fold” or “map, reduce, filter, and generics” they are generally referring to the ability to define those functions in a way that is polymorphic, type safe, transparently handled by the compiler and doesn’t sacrifice runtime overhead compared to their monomorphic analogs.

                              Whether you believe such facilities are useful or not is a completely different and orthogonal question. But no, they are certainly not achievable in Go and this is not a controversial claim. It is by design.

                              1. 1

                                Yes, I agree, Go does not have the combination of type safety and generics, unless you consider code generation.

                                The implementation of generics in C++ also works by generating the code per required type.

                                1. 5

                                  The implementation of generics in C++ also works by generating the code per required type.

                                  But they are not really comparable. In C++, when a library defines a generic type or function, it will work with any conforming data type. Since the Go compiler does not know about generics, with go generate one can only generate ‘monomorphized’ types for a set of predefined data types that are defined an upstream package. If you want different monomorphized types, you have to import the generic definitions and run go generate for your specific types.

                                  unless you consider code generation

                                  By that definition, any language is a generic language, there’s always Bourne shell/make/sed for code generation ;).

                                  1. 1

                                    That is true, and I agree that go does not have support for proper generics and that this can be a problem when creating libraries.

                                  2. 3

                                    That’s why I said “transparently handled by the compiler.” ;-)

                                    1. 0

                                      I see your point, but “go generate” is provided by the go compiler, by default. I guess it doesn’t qualify as transparent since you have to type “go generate” or place that command in a build file of some sort?

                                      1. 1

                                        Yes. And for the reasons mentioned by @iswrong.

                                        My larger point here really isn’t a technicality. My point is that communication is hard and not everyone spells out every point is precise detail, but it’s usually possible to infer the meaning based on context.

                                        1. -1

                                          I think the even larger point is that for a wide range of applications, “proper” and “transparent” generics might not even be needed in the first place. It would help, yes, but the Go community currently thrives without it, with no lack of results to show for.

                                          1. 1

                                            I mean, I’ve written Go code nearly daily since before it was 1.0. I don’t need to argue with you about whether generics are “needed,” which is a pretty slimy way to phrase this.

                                            Seems to me like you’re trying to pick a fight. I already said upthread that the description of generics is different from the desire for them.

                                            1. -2

                                              You were the first to change the subject to you and me instead of sticking to the topic at hand. Downvoting as troll.

                        2. 1

                          By superior, I guess you meant shorter?

                          1. 2

                            Compiling a very large go project with a cold cache might take a minute (sub-second once the cache is warm).

                            Compiling a fairly small rust app with a warm cache has taken me over a minute (I think it’s a little better than that now).

                            1. 1

                              Yes, and superior to Rust in that regard. Also the strict requirement to not have unused dependencies contributes to counteract dependency rot, for larger projects.

                        1. 7

                          … by not attending them, and spending that time on writing code instead.

                          1. 5

                            If you’re curious about writing high security services in Go, I’d suggest taking a look at the code of Boulder, Let’s Encrypt’s certificate authority. Code doesn’t get much more sensitive than that, unless you’re working on a nuclear plant or health devices.

                            1. 3

                              Working remotely and having flexible working hours seems like two completely different topics to me. I wouldn’t mix them up.

                              1. 2

                                Well, not completely different, if remote means anywhere in the world, setting company-wide fixed working hours would be impractical. So the issues aren’t entirely orthogonal.

                                1. 1

                                  I’d say it completely depends on the job and the team. I work remotely with people all around north america and europe (mostly), and I appreciate knowing when someone will be online to answer a question or handle a request. I see no reason why a remotee shouldn’t be asked to work 9-5 if it’s needed for communication/productivity/other reasons. That is, to me, a different topic from physical location.

                                2. 1

                                  You certainly can have flexible hours without working remotely, but how many office bound staff have accsss to that office outside of say 6am till 8pm?

                                1. 9

                                  I’m sure there is good content in this post, but I gave up looking for it after two minutes of scrolling through puns…

                                  1. 4

                                    It’s the style of the page that drives me away. I’d appreciate it a lot if it would just pick a colour scheme.

                                    And yeah, this is griping, but there’s some useful information buried in the showmanship here.

                                    1. 3

                                      Firefox Reader Mode is your friend.

                                    1. 1

                                      I have been using autojump for several years now, and it has definitely accelerated my directory movements, and reduced frustration of having to continuously CD up and down trees. Highly recommended!

                                      1. 1

                                        Shameless plug, but I explain how to setup a secure and fairly simple hosting in AWS in Securing DevOps. Basically: build application containers in CI, then host those containers in AWS ElasticBeanstalk. You can get to a fully automated pipeline in a day or two of work, and it’s mostly maintenance free and autoscales.

                                        1. 3

                                          Serverless functions still need to be deployed in a secure environment and monitored 24/7. The ops team isn’t going away any time soon.

                                          1. 5

                                            Finishing the signing of Android APKs in Go.

                                            1. 1

                                              To be clear, it’s the signing that happens in Go, and the APKs are just regular APKs, right?

                                              1. 1

                                                Yep