Gitlab split and rewrote some services in $faster_language. Based on the hires, Github seems to be doing that as well.

Gitlab's history with $faster_language has at least some background documentation, e.g. https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-....

They seemed to have liked it, as at least a couple of other services are written in $faster_language - gitlab-shell and gitaly (probably, several others).

There may be more static languages nowadays, but they're very young - I think in real world, there wasn't, pragmatically, a lot of choice, although today's young languages are... still young :)

I prefer Go to Ruby so I don't know what you're trying to argue. I just said it requires a lot of boilerplate and that makes it harder to be productive. Technology choice is about trade-offs.

It doesn't mean a project is doomed simply because it chose Go. That said, Heroku tried to do a major Go rewrite of their entire backend and the project failed miserably.

What's the story behind Heroku's rewrite?

IMO Go has far more boiler plate than Java. Go is going to have countless amounts more boiler plate for simple logic. Just like your comment below try writing one of these in go:

    var lst = users.stream()
        .filter(User::isAdmin)
        .map(u -> u.id() + “ : “ + u.name())
        .limit(10)
        .toList();


    static boolean isPrime(int n) {
        return switch (n) {
            case 0, 1 -> false,
            default -> !IntStream.range(2, n).anyMatch(i -> n % i == 0)
        }
    }

New Java is pretty damn good actually, I don't see a real need for Go over it other than compile time perhaps.

Java has a lot going for it but the JVM remains anathema to a lot of developers. Modern C++ has similar stigma on the language end – it's possible to write fantastically expressive and terse code in it nowadays, but it maintains a reputation.

2 years ago I spent 2 months learning C++ coming from almost entirely scripting languages throughout my career. (Though I have a CS degree so a decent academic background in memory management)

I came away liking C++ more than I thought I would. I didn't find it hard to learn but it was time consuming. Where learning Rust I never understood the basic concepts enough to be productive, I could be productive pretty quick with C++.

The trouble is there is a lot to learn because the language is just so old and has been through so many revisions. To some extent you can't just limit yourself to the modern stuff since in order to learn the modern stuff you need a basic understanding of what it was before to know why things are done the way they are now. You also run into code samples that use the old stuff or corner cases where they're needed.

I also think it really gets you to think about how computation and memory is happening at the metal level which is great for optimization but I think for most of the work I do it would be largely a distraction. I see this is a downside, not an upside.

That said, you're definitely right. You can have nice, expressive code in C++: I just think the learning curve is the biggest problem. I'd be happy to use C++ in my next project though.

Javac is still probably going to compile faster than go. Javac doesn't have to do ANY optimizations. I doubt you'll find a compiler faster.

You may be right. My knowledge of Java is from 1.4 in college and vastly out of date.

I should spend some time actually learning modern Java and less time avoiding it.

There's still some verbosity. I would kill for C# like properties for mutable data classes (JPA entities). I also really like Kotlin/Scala style apply functions for interfaces and Kotlin's delegates for making easy decorators, but none of these have ever convinced me to leave Java behind. The only languages that have come close are C# or D because of their lower level capabilities.

Second one in Go:

    func IsPrime(n int64) bool {
        return big.NewInt(n).ProbablyPrime(0)
    }

Each language has its own pros and cons. Go wants to be explicit and simple to be understood. Java is fully-featured.

This is just anectodal evidence anyways. And these are tools in the and, and no point for a "tool fight".

The point of that example wasn't to show if there was a standard library function for it. It was to show the verbosity of writing code that contains if conditions, loops, and generic programming. I obviously could have written:

    new BigInteger(n).isProbablyPrime(0);

My general point is that if you put Ruby up against a nonspecific compiled language it's hard to argue Ruby is better. When you analyze something like Go vs Ruby or Go vs Java then the warts of particular languages come out.

This is definitely true, and I wouldn't fault anyone for using Ruby or Python to write the initial version of their startup. However, there's a difference between initial productivity and ongoing productivity (maintenance). Statically typed languages like Go and C++ are much easier to rework and refactor, because the compiler is checking types (not to mention typos).

That's why my language of choice is TypeScript, but I think Sorbet looks promising (haven't used it though)

Same. Next whatever startup or what I will do will be done in TypeScript(/JS) for the back end and front end. The ecosystem is so massive. And most of the time people will do a library, tool, database, or whatever, and the next language they will support to interact with it is JS/TS.

make sure you give Deno a test run too. I think it could be great for some applications already.

(Specifically cases where you want the project easy to jump into with almost no toolchain setup.)

C# and F# have a good blend of performance and code style.

And in Visual Studio (full, not code) you have an amazing IDE that is an incredible help when writing the code.

why not just use Crystal https://crystal-lang.org, it is faster than go, with Ruby like sytnax.

One major selling point of Ruby is the robust ecosystem of high quality, open source libraries which are relevant to the things SaaS companies need to get done. There's a ton of code you just don't have to write if you stick to Ruby.

The fact that "Ruby developers already basically know the Crystal syntax" is a selling point for Crystal, but if people are already evaluating a switch to another programming language, that's just one of many factors that must be considered.

> with Ruby like sytnax

People use Ruby because they like the way it works, not because of the syntax.

Crystal's standard library is also a close match for Ruby's. I do Ruby every day and was able to familiarise myself with Crystal in a few hours.

It's definitely lacking in the web ecosystem department but the language is a joy to use and incredibly fast.

It can be a 99.99% close-match, but if it doesn't include key methods like a runtime method_missing, then it's hard to see how we'd reimplement Rails and our code base on top of it.

I think people focus on the superficial similarity of Crystal, without thinking what semantics need to be the same for it to use usefully similar. And those semantics aren't there, so it doesn't matter if it sorts of looks the same and includes most methods.

I feel like if it was tractable to run Rails on Crystal then someone would have done that.

I'm waiting until I hear some success people are having with it. I suspect the ecosystem is young and library support is minimal too.

Last I heard (which was years ago) it was pretty much a solo project.

That said, the demo is really something and I like what they're doing. I hope one day it becomes my language of choice.

What about C#? That being said, I might just be accustomed to all the boilerplate.

Biggest downside is you're likely committing yourself to the Microsoft stack and a single vendor for most of your technology.

I don't think it's necessarily the wrong decision but you have to decide if it's right for your project.

Dotnet core runs fine in Docker/on Linux?

Most C# apps I've worked on in the last 5 years are deployed to Kubernetes.

fair enough, perhaps I should give it another look

100% inaccurate/outdated (by 5 years) info. I've run .NET Core applications on Linux/Docker/K8s + Postgres. The only Microsoft 'stack' there is .NET itself.

.NET Core is still absolutely designed to nudge you into the MS stack.

- EFCore is MSSQL first, even if other options are provided

- Many libraries ship with two implementations: an over-engineered Windowsy version that barely works (with a big scary warning that it should never be used in production), and a thin wrapper around some Azure service

- Important tooling like the debugger (which wouldn't be so necessary if .NET had halfway decent support for printf debugging, but here we are...) is locked to be compatible with VS and (MS' build of) VSCode, despite both of them using supposedly open (and Microsoft-pushed!) standards like DAP

- The community is really culty, the response to "X is broken when using the non-MS-Stack alternative" always seems to be "well use the standard MS solution then"

- It's practically open source in name only, because the build engineering is so convoluted that it's nearly impossible to find the canonical source code of core features like the standard libraries

- EF Core is not MSSQL first. EF Core is an abstraction layer and is in no way tied to Sql Server. In fact, Microsoft's own getting started tutorial uses Sqlite (1). I've personally used the Postgres drivers in production and they are as good/production-ready as Microsoft's SQL library for EF Core.

- "Many libraries ship with two implementations..." I've yet to come across these "many" libraries in the 5 years since I've been building services with .NET Core.

"The community is really culty" - I'm not sure where this is coming from. It's hard to refute such vague criticisms.

- "It's practically open source in name only" - Here is the base class library source: https://github.com/dotnet/runtime/tree/main/src/libraries or https://github.com/dotnet/corefx/releases (depending on what version you're looking for)

1. https://docs.microsoft.com/en-us/ef/core/get-started/overvie...

If you want to build .NET Core yourself, Microsoft provides you with the steps necessary to do so here: https://github.com/dotnet/source-build

Maybe our definitions of open source are different, or maybe you're just shitting on Microsoft for your own reasons. Regardless of whatever your experiences have been with .NET in the past, they don't mirror the majority of the folks that use it everyday.

.Net Core is universal platform. Our API servers run .Net Core exe’s on Ubuntu behind NGINX. Full AWS stack, some Google Cloud and Mongo Cloud services internally. I don’t think we even have an Azure account.

Still a lot of Windows baggage with C#. It's changing, but I think most c# devs are still learning fundamental unix and docker stuff. So you'll get an overhead with C# too, just not in technical performance.

Source? As a .NET developer I can tell you that there are plenty of us with Linux/Docker experience. There is zero Windows baggage with C# in .NET (Core). Your information is out of date.

Projects making use of Sitecore, Dynamics, SharePoint, SQL Server CLR,... GUI frameworks out of Redmond

Graphical tooling to deal with process dumps, etw data, and profiler information only available on VS.

> Projects making use of Sitecore, Dynamics, SharePoint, SQL Server CLR,

What projects? None of those are forced on you or have any references to them built into .NET Core. I've been building .NET apps since 1.0 reached beta (in 2001?) I can count on one hand how many times in total that I've worked with those systems. This argument is a hell of a reach.

> GUI frameworks out of Redmond The upcoming Microsoft MAUI is cross-platform (no, Microsoft isn't building support for Linux, but there are open source efforts working on it.)

You can use https://avaloniaui.net or https://platform.uno

> Graphical tooling to deal with process dumps, etw data, and profiler information only available on VS.

https://www.hanselman.com/blog/dotnettrace-for-net-core-trac...

There's also https://github.com/SachiraChin/dotnet-monitor-ui

You can use JetBrains rider to profile in Linux/MacOS as well: https://www.jetbrains.com/help/rider/Profiling_Applications....

If you don't want to use .NET, you obviously don't have to.

I work for a C# shop. However maybe the signal is ex-Microsoft rather than C# itself, when I think about it more. We have lots of ex-MSFT.

Switched from a career of a windows/.net/c# to a max/ruby/js shop. Docker skills transferred. Had to learn Unix commands but it didn’t feel much different from cmd/powershell

You could make most scripting languages much faster by adding immutable structs and keeping everything else more or less the same. There was a game middleware company selling more or less this for Lua.

Prove Productivity scientifically.

We gonna double-blind developers or something? I know Go and Ruby very well. I know what it takes to write in one vs the other.

Ruby is faster to write and more concise by a long shot—certainly if we're talking back-end web services. I prefer Go to Ruby generally but it's weird that Go developers tend not to even see how much yak shaving is involved with it. Or really any downside with it.

Try writing this in Go:

    records = User.limit(10)
    records.select { |user| user.is_admin? }.map{|user| "#{user.id} : #{user.name}"}

Thanks to generics, assuming there is some stream/sequence like type

    records := Stream.Limit(User, 10)
    records.Select(func(user User) bool {return user.IsAdmin()}).Map{func(user User) string { return fmt.Sprintf("%d %s", user.id, user.name) }

Yes a bit more verbose, that is the price to pay for static typing without full type inference as in the ML language family.

It blows my mind why Go didn’t have generics at launch. I suppose they just didn’t want people to be able to have abstractions like this at all?

> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.

https://go.googlesource.com/proposal/+/master/design/go2draf...

oh wow thanks for this. I haven't been actively using Go since around the time this was written so I've missed it

Stream.limit and Stream.select(…).limit are not the same thing :)

records.collect({case u if u.isAdmin => s”${u.id} ${u.name}”}).take(10) guess the language

Well you can argue semantics, it doesn't change the fact that it is possible to implement the same concepts in Go with generics.

That line of code could be Scala, or something else.

In any case, the point is that there are compiled languages that offer similar productivity like Ruby, with AOT/JIT compilers out of the box, and great IDE experiences.

It is Scala. I meant to demo type inference and pattern matching. I know pattern matching(something I cant live without) does not exist in Go and Ts, not sure how well type inference works in Go

I may be wrong, but aren't you doing two loops by doing it that way? One for the select, and another for the map? Or does ruby compile out the select loop with smarts.

In Go, the intuitive way would be one loop with an if inside it. So it would be easy to spot this performance issue if you did it the ruby way with two loops.

https://go.dev/play/p/ixDKuosxPNp

I bet I wrote my for loop as quickly as you wrote your map. The character count isn't that much higher.

The amount of times in my career where the performance would be even measurable between these 2 styles is vanishingly few. If I cared I could just use #filter_map or a classic for-each loop. If we're assuming the project is written in Ruby in the first place, clearly we're not valuing performance that highly.

The more important thing is the ruby version is chainable and more readable—and that matters far more often.

You had me until

> more readable

Without having more context, User in your code is possibly an ActiveRecord class, so to read the #select, you have to consider that it could be radically different and heavier than Enumerable#select (eg. it may execute a DB query as a side effect). So I like your example still, because it’s representative, and certainly expressive, but not readable per se. IMO this sin here is simply that ActiveRecord shouldn’t have overloaded select.

That’s more of an argument against ORMs which I realize my example used. I was mostly trying to convey using map/filter against POROs though.

Using an ORM was a poor choice on my part. I agree the magic there does harm readability since it makes it a lot harder to understand what it really is doing.

Ruby has had lazy iteration[1] for quite a while but as n here is only 10 there's really not much to loose in not using it.

In fact given that only a subset of users will be admin users for the second loop n is going to < 10 anyway.

I believe it was Rob Pike that actually said something along the lines of not bothering to optimise until you know that n is large[2].

1. https://ruby-doc.org/core-2.5.0/Enumerator/Lazy.html

2. https://users.ece.utexas.edu/~adnan/pike.html

Not sure about Ruby, but Java’s streams would do one loop only here, as they are lazy. Also, both solutions are O(n), so unless this is the hot loop of your program, or it iterates over some insane amount of entities, it is a completely meaningless microoptimization.

Why?

Because it underpins the argument above.

If Ruby is "so productive", that's a quantifiable measurement, no?