https://news.ycombinator.com/item?id=40445536 (2 years ago, 63 points, 66 comments)

https://news.ycombinator.com/item?id=25554018 (5 years ago, 70 points, 102 comments)

https://news.ycombinator.com/item?id=13751244 (9 years ago, 29 points, 14 comments)

Looks like the page was moved from a GitHub gist to a github.io page in October of last year.

Comments URL: https://news.ycombinator.com/item?id=48470964

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48429761

Points: 3

# Comments: 0

[0]: https://www.slashdata.co/research/developer-population

[1]: https://www.slashdata.co/company/methodology

[2]: https://developernation.net/

Taking a second look I want to say you need to hoist the assignment for the loops to be semantically identical anyways.

The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.

> one that's optimized for such tight loops, and another that does thorough checking

I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?

[0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...

[1]: https://kobzol.github.io/assets/posts/compile-sections/binar...

[2]: https://kobzol.github.io/assets/posts/compile-sections/libra...

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p17...

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...

Not sure if I'm just out of the loop, but I'm having a hard time following this line of reasoning. Why is a public and/or stable contract needed to carry high-level semantics from HIR to MIR? Neither seems necessary to me; from what I understand HIR and MIR are rustc-internal so public contracts shouldn't matter, and the lack of stability means the Rust devs aren't precluded by backwards compatibility from modifying the IRs to add the ability to carry such invariants.

How did Clang handle differences between member declaration order and the order in which initializers appeared?

Unfortunately it's not that simple when it comes to UB. If the snippet in question does in fact exhibit UB then there's no guarantee whatever Godbolt shows will generalize to other programs/versions/compilers/environments/etc.

In this context "UB" means something different than how you're using it. The UB being mentioned here is the "nasal demons" form, i.e., programs which contain undefined behavior have no defined meaning according to the language semantics.

What you're talking about is probably better described in this context as "unspecified behavior", which is behavior that the language standard does not mandate but does not render programs meaningless. For example, IIRC in C++ the order in which g(), h(), and i() are evaluated in f(g(), h(), and i()) is unspecified - an implementation can pick any order, and the order doesn't have to be consistent, but no matter the order the program is valid (approximately speaking).

"When" is inaccurate. The original shareholder vote for Musk's 2018 compensation plan was on 2018-03-18. Tornetta was filed on 2018-06-05, well before the first tranche vested in 2020.

Comments URL: https://news.ycombinator.com/item?id=48120066

Points: 6

# Comments: 1

    import java.util.ArrayList;
    import java.util.List;
    
    class Day06 {
        public static void main(String args[]) {
            List fileTypeList = new ArrayList<>();
            for (int i = 0; i < 1000000; i++) {
                fileTypeList.add("fileType");
            }
    
            long beforeForLoop = System.currentTimeMillis();
            for (int i = 0; i < fileTypeList.size(); i++) {
                fileTypeList.get(i);
            }
            long afterForLoop = System.currentTimeMillis();
            System.out.println("Time took in millis for for " + (afterForLoop - beforeForLoop));
    
            long beforeForeachLoop = System.currentTimeMillis();
            for (String s : fileTypeList) {
            }
    
            long afterForeachLoop = System.currentTimeMillis();
            System.out.println("Time took in millis for foreach " + (afterForeachLoop - beforeForeachLoop));
        }
    }

If you want proper results you probably want to use the Java Microbenchmark Harness [0]. You'd probably want some actual data/work as well so the JIT doesn't overspecialize on the benchmark.

Edit: Halfheartedly tried to adapt the LinkedIn benchmark to JMH. Still not a great benchmark and I'm rusty so I wouldn't be surprised if I messed something up, but it's hopefully better the original:

    package org.sample;

    import org.openjdk.jmh.annotations.*;
    import org.openjdk.jmh.runner.Runner;
    import org.openjdk.jmh.runner.RunnerException;
    import org.openjdk.jmh.runner.options.Options;
    import org.openjdk.jmh.runner.options.OptionsBuilder;

    import java.util.ArrayList;
    import java.util.List;
    import java.util.concurrent.TimeUnit;

    @State(Scope.Thread)
    @BenchmarkMode(Mode.AverageTime)
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    public class MyBenchmark {

        List fileTypeList = new ArrayList<>() {{
            for (int i = 0; i < 1000000; i++) {
                this.add("fileType");
            }
        }};

        @Benchmark
        public void baseline() {
        }

        @Benchmark
        public int measureFor() {
            int result = 0;
            for (int i = 0; i < fileTypeList.size(); i++) {
                result += (int)fileTypeList.get(i).charAt(0);
            }
            return result;
        }

        @Benchmark
        public int measureForEach() {
            int result = 0;
            for (String s : fileTypeList) {
                result += (int)s.charAt(0);
            }
            return result;
        }

        public static void main(String[] args) throws RunnerException {
            Options opt = new OptionsBuilder()
                    .include(MyBenchmark.class.getSimpleName())
                    .build();

            new Runner(opt).run();
        }

    }

    # JMH version: 1.37
    # VM version: JDK 21.0.10, OpenJDK 64-Bit Server VM, 21.0.10+7-Ubuntu-124.04
    # VM invoker: /usr/lib/jvm/java-21-openjdk-amd64/bin/java
    # VM options: 
    # Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
    # Warmup: 5 iterations, 10 s each
    # Measurement: 5 iterations, 10 s each
    # Timeout: 10 min per iteration
    # Threads: 1 thread, will synchronize iterations
    # Benchmark mode: Average time, time/op

    Result "org.sample.MyBenchmark.baseline":
      0.254 ±(99.9%) 0.022 ns/op [Average]
      (min, avg, max) = (0.247, 0.254, 0.262), stdev = 0.006
      CI (99.9%): [0.232, 0.276] (assumes normal distribution)

    Result "org.sample.MyBenchmark.measureFor":
      693178.390 ±(99.9%) 60793.583 ns/op [Average]
      (min, avg, max) = (676266.480, 693178.390, 718114.554), stdev = 15787.901
      CI (99.9%): [632384.806, 753971.973] (assumes normal distribution)

    Result "org.sample.MyBenchmark.measureForEach":
      693756.240 ±(99.9%) 7549.769 ns/op [Average]
      (min, avg, max) = (691685.231, 693756.240, 696573.323), stdev = 1960.651
      CI (99.9%): [686206.470, 701306.009] (assumes normal distribution)

Comments URL: https://news.ycombinator.com/item?id=48029482

Points: 2

# Comments: 0

Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time between 1.0 and when async was added), but the ergonomics of the library-based keyword-less solutions was considered to be less than optimal compared to building in support to the language.

> This is why new languages should build in green threading from the start.

This, just like most other decisions one can make when designing a language, is a tradeoff. Green threads have their niceties for sure, but they also have drawbacks which made them a nonstarter for what the point in the design space the Rust devs were aiming for. In particular, the Rust devs wanted something that did not require overhead for FFI and also did not require foreign code to know that something async-related is involved. Green threads don't work here because they either have overhead when copying stuff between the green thread stack and the foreign stack or need foreign code to understand how to handle the green thread stack.