gitmoji VS swift

My commit messages are pretty good though. I put some effort/thought into them not just for the repo/git purposes, but it also helps me mentally keep track of what I have done / have to do just in the general carry-on coding. I even prefix messages with an emoji, similar to the guidelines on https://gitmoji.dev/

You may also turn on GitMoji convention if you prefer your messages baked with emojis 🤠

I use Gitmoji:

https://github.com/carloscuesta/gitmoji

OpenCommit leverages the conventional commits convention, ensuring your commit messages are both concise and informative. Want a little fun in your commits? Enable the GitMoji setting!

The library uses conventional commits convention which makes commits concise and comprehensive. You can also turn on GitMoji setting if you like.

At a previous job we used https://gitmoji.dev, which scrumoji is based on. At some point I started using the ladybug emoji for bugs because it's actually a bug while my colleagues kept using the caterpillar emoji because they preferred caterpillars. I thought it was a nice way to bring some individuality into our commit messages!

It's the first time I see someone combining gitmoji with conventional commits (I use the later now for all my project, to generate my changelogs automatically with with git-cliff.)

It still happens today: https://github.com/carloscuesta/gitmoji

You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md.

Codable (along with other derived conformances like Equatable, Hashable, and RawRepresentable) is indeed built in to the compiler[0], but unlike Serde, it operates during type-checking on a fully-constructed AST (with access to type information), manipulating the AST to insert code. Because it operates at a later stage of compilation and at a much higher level (with access to type information), the work necessary is significantly less.

With ongoing work for Swift macros, it may eventually be possible to rip this code out of the compiler and rewrite it as a macro, though it would need to be a semantic macro[1] rather a syntactic one, which isn't currently possible in Swift[2].

[0] https://github.com/apple/swift/blob/main/lib/Sema/DerivedCon...

`Int` is a regular struct with a single stored property of type `Builtin.Word` . But the latter is a magical compiler built-in. Source for integer types is generated from this template - https://github.com/apple/swift/blob/9da65ca0a15fdf341649c994b0a77ec3b71f2687/stdlib/public/core/IntegerTypes.swift.gyb

The following searches are performed on the entire Apple Swift source tree. The commit used is 3865b.

Like someone mentioned swift.org is a start.

Happily Swift has interop with C, and they're working on actual C++[1], which would be a lot of wasted effort.

The question is very simple: Swift is meant to be a safe language, how feasible is that if a large chunk of the core types and runtime are implemented in C, C++, and Objective-C/C++? Migrating to Swift is the obvious and sensible step, unless you propose re-implementing them in yet another language?

[1] https://github.com/apple/swift/blob/main/docs/CppInteroperab...

> There's not even anything technically interesting about the language

It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me.

> We have so much more than that and you just went with reference counting

Like what?

The options for memory safe shared ownership are refcounting or GC.

Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw pointers - obviously C++'s type system and approach to memory safety is not a Good Thing).

But it's important to realize rust did not create a new solution to object lifetime management for shared objects.

It's also important to realize that rust was designed in an environment where there was no existing code to interoperate with, whereas Swift was designed to work with the existing Darwin APIs and objective-c which are all refcounted. So even if no refcounting was the goal you'd end up with a new language, designed for a specific environment, and the default behaviour would not be correct.

Now that the language is more established, and it's less critical for every part of the language to have objc interop they are working on pure ownership semantics, for the same reason as rust: it saves copies without requiring a refcount[1]

[1] https://github.com/apple/swift/blob/main/docs/OwnershipManif...

His complaint about the bug being closed is weird to me. Swift went through a lot of changes in the early years. Everyone was aware of this. He also had plenty of time to find a work around, and what he was trying to do was trying to do was a bit weird and I would argue is fighting against how Swift works. It’s weird to have a protocol, a base class that conforms to the protocol but is not actually meant to be used, and then a subclass with the actual implementation. There is no need for the base class. He seems to be trying to use it as an abstract class or something as far as I can tell, but that is what protocols are for.

Finally, it seems that the behavior he was complaining about was largely changed 2 years before the blog was even written. https://github.com/apple/swift/issues/49631

I agree with him that JavaScript is a terrible language and I also take a utilitarian approach to programming languages.