Hacker News new | ask | show | jobs
by devsquid 3444 days ago
There are some web frameworks that are indevelopment. That does not mean Swift has gained any traction. Also having toyed around with one, the experience was not great.

When writing a server, I would take Go over Swift anyday. It out preforms it, uses less memory, its simpiler, oh and it uses a "tradiontal" GC.

1 comments

>uses less memory

That is very much _not_ the case according to the testing I have done recently.

Swift uses a lot less memory than Go unless the program uses only trivial amounts of memory in the first place. Using interfaces in Go data structures makes the difference even more pronounced.

On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully written to avoid memory allocation.

That said, Swift has a few very weak spots when it comes to memory. Most notably the String type, which is terrible on all counts, but that is a whole different story.

> On top of that, all runtimes that use a tracing GC require tons of spare memory at all times unless programs are very carefully written to avoid memory allocation.

Only if the said language doesn't allow for stack or static globals.

Quite a few languages do allow it.

Doesn't that effectively amount to manual memory management? What particular languages are you referring to?
> Doesn't that effectively amount to manual memory management?

Not really, example in Active Oberon:

    TYPE
      point = RECORD x, y : INTEGER; END;

    VAR
      staticPoint : point; (* On the stack or global *)
      gcPoint     : POINTER TO point; (* GC pointer *)
      noGCPoint   : POINTER(UNTRACED) TO point; (* pointer not traced by the GC *)
> What particular languages are you referring to?

Mesa/Cedar, Oberon, Oberon-2, Active Oberon, Component Pascal, Modula-2+, Modula-3, D, Oberon-07, Eiffel, BETA.

There are probably a few other ones.

>noGCPoint : POINTER(UNTRACED) TO point;

That's fine for one point. How about N points where N varies at runtime?

If I allocate memory dynamically outside the GC's remit, I'm going to have to release that memory somehow.

Depends on the specifics of the language.

On Active Oberon's case, those pointers are still safe. They can only point to valid memory regions, think of them as weak pointers that can also point to data on the stack or global memory.

This in safe code.

If the package imports SYSTEM, it becomes an unsafe package, and then just like e.g. Rust's unsafe, the rules are bended a bit and usage with SYSTEM.NEW() SYSTEM.DISPOSE() is allowed.

Just like any safe systems programming language, it is up to the programmer to ensure this pointer doesn't escape the unsafe package.

It will be great if you have any benchmark to share. From what s available on internet Swift does seem to use more memory than Go.
What sources have you found on the internet?

My own code is unfortunately a bit messy and entangled with unrelated stuff. If I find the time I'm going to clean it up.